მოაწყვეთ ბრენდირებული პორტაბელობის ინსტრუმენტის დომენი და ავთენტიფიცირებული ელფოსტის გაგზავნა თქვენს მფლობელობაში არსებული დომენისთვის, იმ ჰოსტის სახელებისა და DNS მნიშვნელობების გამოყენებით, რომლებსაც MultiTEL ადასტურებს თქვენი სერვისისთვის. ეს პარამეტრები ცალკეა ტელეფონის ნომრის გადატანისგან.
რისთვისაა ეს კონფიგურაცია
საკუთარი ბრენდით მოქმედი ნომრის პორტაბელობის ინსტრუმენტი (white-label) საშუალებას გაძლევთ წარმოადგინოთ ნომრის გადატანის მოთხოვნები საკუთარი ბრენდის ქვეშ და, როცა კონფიგურირებულია, გააგზავნოთ მოთხოვნის ელფოსტები საკუთარი ელფოსტის დომენის სახელით. ამ სახელმძღვანელოში DNS ცვლილებები ეხება ამ ბრენდირებულ ვებსაიტს და ელფოსტის იდენტობას. ისინი არ არის მოთხოვნა ჩვეულებრივი ტელეფონის ნომრის გადატანისთვის და არ ცვლის ტელეფონის ნომრის ხმოვან მარშრუტიზაციას.
თქვენ უნდა ფლობდეთ და აკონტროლებდეთ იმ დომენს, რომლის DNS-საც შეცვლით. ამ ჩანაწერების კონფიგურაცია არ შეგიძლიათ მესამე მხარის უფასო ფოსტის დომენზე არსებული მისამართისთვის, რომელიც თქვენ არ გეკუთვნით.
დაადასტურეთ ბრენდირებული სერვისი DNS-ის შეცვლამდე
გახსენით ნომრის პორტაბელობა. გამოიყენეთ იქ არსებული ბრენდირების ველები იმ ბრენდის სახელისა და ლოგოს დასაყენებლად, რომლებიც გამოიყენება მოთხოვნებისთვის ამ ეკრანზე. მორგებული დომენის საკუთარი ბრენდით მოქმედი საიტისთვის (white-label), სთხოვეთ MultiTEL-ის მხარდაჭერას დაადასტუროს, რომელი ბრენდის პარამეტრები ვრცელდება, ჰოსტის სახელი, გამოსაქვეყნებელი DNS მნიშვნელობები, გამგზავნის დომენი და HTTPS სერტიფიკატის კონფიგურაცია თქვენი ანგარიშისთვის, ნებისმიერი DNS ჩანაწერის გამოქვეყნებამდე.
არ გადაამისამართოთ ძირითად სამუშაო გარემოში არსებული ვებსაიტი (production) და არ შეცვალოთ არსებული ელფოსტის მიწოდება მხოლოდ პორტაბელობის მოთხოვნის ბრენდირების მიზნით. ჩაიწერეთ წინა DNS მნიშვნელობები, რათა საჭიროების შემთხვევაში შეძლოთ მათი აღდგენა. თუ მოგვიანებითი ცვლილების ან უკან დაბრუნების უფრო სწრაფი გავრცელებაა საჭირო, წინასწარ შეამცირეთ შესაცვლელი ჩანაწერების TTL და დაელოდეთ წინა TTL-ის ამოწურვას ცვლილების შეტანამდე. TTL-ის შემცირება არსებული ქეშირებული პასუხების ვადის გასვლას დაუყოვნებლივ არ იწვევს.
ვებსაიტის CNAME
მას შემდეგ, რაც MultiTEL დაადასტურებს თქვენი სერვისისთვის მორგებულ ჰოსტის სახელს და CNAME სამიზნეს, შექმენით მოთხოვნილი CNAME თქვენს DNS პროვაიდერთან. შეამოწმეთ, ამატებს თუ არა DNS კონსოლი ზონის სახელს ავტომატურად; შეიყვანეთ ჰოსტის ლეიბლი ან სრული სახელი ამ კონსოლის ინსტრუქციების მიხედვით, დომენის დუბლირების გარეშე. დადასტურებულ CNAME ჰოსტის სახელს ასევე არ უნდა ჰქონდეს A, AAAA, MX ან TXT ჩანაწერები. თუ იქ უკვე არსებობს სხვა ჩანაწერები, ცვლილებების შეტანამდე შეამოწმეთ, რომელი სერვისები იყენებს მათ. გამოიყენეთ სხვა MultiTEL-ის მიერ დამტკიცებული ჰოსტის სახელი, თუ ეს სახელი კვლავ ემსახურება სხვა სერვისს; არსებული ჩანაწერები წაშალეთ მხოლოდ მას შემდეგ, რაც დაადასტურებთ, რომ ისინი აღარ არის საჭირო.
შემდეგი მხოლოდ მაგალითია: ის მოქმედებს, თუ თქვენ ფლობთ test123.com-ს და MultiTEL ადასტურებს როგორც porting.test123.com-ს თქვენს ჰოსტის სახელად, ისე porting.multitel.net-ს თქვენი სერვისის CNAME სამიზნედ. არ გამოიყენოთ ეს სამიზნე, თუ მხარდაჭერა არ დაადასტურებს მას თქვენი სერვისისთვის:
porting.test123.com. IN CNAME porting.multitel.net.გამოიყენეთ ზუსტად ის სამიზნე, რომელიც დადასტურებულია თქვენი სერვისისთვის. მხოლოდ CNAME არ ააქტიურებს მორგებულ დომენს და არც ვალიდური HTTPS სერტიფიკატის გარანტიას იძლევა. ახალი URL-ის გაზიარებამდე დაადასტურეთ საიტის სერტიფიკატი და ბრენდირებული მოთხოვნის ნაკადი.
SPF მოთხოვნის ელფოსტებისთვის
თუ MultiTEL დაადასტურებს, რომ მოთხოვნის ელფოსტები გაიგზავნება თქვენი დომენის სახელით, სთხოვეთ მხარდაჭერას დაასახელოს SPF-ისთვის გამოყენებული გამგზავნის დომენი და DKIM-ისთვის გამოყენებული ხელმოწერის დომენი. არ არის აუცილებელი, რომ ისინი ბრენდირებული ვებსაიტის ჰოსტის სახელი იყოს. გამოაქვეყნეთ SPF დადასტურებულ SPF დომენზე და DKIM საჯარო გასაღები ქვემოთ აღწერილ სელექტორის სპეციფიკურ სახელზე; არ დაამატოთ ფოსტის ავთენტიფიკაციის TXT ჩანაწერები ვებსაიტის CNAME ჰოსტის სახელზე. ავტორიზება მიანიჭეთ დადასტურებულ გამგზავნის სერვისს SPF დომენის პოლიტიკაში. აქ ნაჩვენები MultiTEL SPF include არის include:_spf.multitel.net. დაამატეთ იგი მხოლოდ მას შემდეგ, რაც მხარდაჭერა დაადასტურებს, რომ ის ვრცელდება თქვენი ანგარიშის გამგზავნის სერვისზე.
თუ დომენს უკვე აქვს SPF TXT ჩანაწერი, გააერთიანეთ ავტორიზებული include იმ არსებულ პოლიტიკაში. შეინარჩუნეთ სხვა ლეგიტიმური გამგზავნები და განზრახული საბოლოო პოლიტიკა; არ გამოაქვეყნოთ მეორე SPF ჩანაწერი. შეადარეთ მთელი პოლიტიკა, მათ შორის ჩადგმული include-ები და redirect-ები, SPF-ის DNS ძიების ლიმიტებს. SPF-ის შეფასება უშვებს მაქსიმუმ 10 DNS-ძიების გამომწვევ ტერმინს, როგორიცაა include, a, mx, ptr, exists და redirect; ამ ლიმიტის გადაჭარბება იწვევს permerror-ს. გაუმართავმა SPF პოლიტიკამ შეიძლება ხელი შეუშალოს ლეგიტიმურ ფოსტას SPF ავთენტიფიკაციის გავლაში. თუ არსებული პოლიტიკა არ არსებობს და MultiTEL ადასტურებს, რომ ეს არის ერთადერთი ავტორიზებული გამგზავნი, მაგალითია:
@ IN TXT "v=spf1 include:_spf.multitel.net ~all"DKIM მოთხოვნის ელფოსტებისთვის
გამოაქვეყნეთ ზუსტი DKIM სელექტორი, DNS ჩანაწერის სახელი და საჯარო გასაღების TXT მნიშვნელობა, რომლებიც დადასტურებულია თქვენი ხელმოწერის დომენისთვის. DKIM DNS სახელი აერთიანებს სელექტორს, _domainkey-ს და ხელმოწერის დომენს. მაგალითად, სელექტორი mail დომენისთვის example.com იძლევა სრულ ჩანაწერის სახელს mail._domainkey.example.com; mail._domainkey არის ფარდობითი ჩანაწერის სახელი და არა სელექტორი. მიიღეთ მიმდინარე მნიშვნელობები MultiTEL-ის მხარდაჭერისგან; ნუ ივარაუდებთ, რომ ძველი სტატიიდან, სხვა ანგარიშიდან ან MultiTEL-ის საკუთარი DNS-დან კოპირებული სელექტორი ან საჯარო გასაღები არის თქვენი ანგარიშისთვის გამოყენებული მნიშვნელობა. DKIM საჯარო გასაღები ქვეყნდება DNS-ში; ხელმოწერის საიდუმლო გასაღები არასოდეს უნდა იქნას მოთხოვნილი ან გამოქვეყნებული.
შეამოწმეთ, ამატებს თუ არა თქვენი DNS კონსოლი ზონის სახელს ავტომატურად, და თავიდან აიცილეთ დომენის ან _domainkey-ის დუბლირება ჩანაწერის სახელში. შეინარჩუნეთ საჯარო გასაღების სრული მნიშვნელობა, როცა DNS კონსოლი გრძელ TXT ჩანაწერს ბრჭყალებში ჩასმულ ნაწილებად ყოფს.
სრული შედეგის გადამოწმება
გამოაკითხეთ სახელების ის სერვერები, რომლებიც მოცემული ზონის DNS მონაცემების უშუალო წყაროა (authoritative nameservers), და გარე რეზოლვერი თითოეული შეცვლილი ჩანაწერისთვის. მიეცით კონფიგურირებულ TTL-ს და DNS ქეშებს ამოწურვის დრო; ერთი ქეშირებული ლოკალური რეზოლვერის შედეგი არასაკმარისია. შეადარეთ დომენის ყველა ნაწილის შემცველი ჩანაწერის სრული სახელი (FQDN), ტიპი, ზუსტი სამიზნე ან მნიშვნელობა, ბრჭყალების გამოყენება და ნებისმიერი ბოლო წერტილი დადასტურებულ ინსტრუქციებსა და თქვენი DNS პროვაიდერის შეყვანის ფორმატს. მოაგვარეთ კონფლიქტური ჩანაწერები, არასწორი სახელები, გამოტოვებული მნიშვნელობები და არავალიდური სერტიფიკატები URL-ის გაზიარებამდე ან ბრენდირებულ ელფოსტაზე დაყრდნობამდე.
გახსენით დადასტურებული ბრენდირებული მოთხოვნის URL და დაადასტურეთ, რომ გვერდები იტვირთება ვალიდური სერტიფიკატით და მოსალოდნელი ბრენდით. ნებისმიერი ტესტის წარდგენამდე, ჰკითხეთ MultiTEL-ის მხარდაჭერას, რომელი სატესტო ნაკადი არის ხელმისაწვდომი და დაიწყებს თუ არა წარდგენა ნომრის რეალურ გადატანას. მას შემდეგ, რაც მხარდაჭერა დაადასტურებს, რომ ბრენდირებული ელფოსტა ჩართულია თქვენი ანგარიშისთვის, გამოსცადეთ იგი მხოლოდ დადასტურებული სატესტო ნაკადით და იმ ნიმუშის მონაცემებით ან სატესტო პროცედურით, რომელსაც მხარდაჭერა გაწვდით, რათა არ დაიწყოთ ნომრის რეალური გადატანა. გადახედეთ მიღებული შეტყობინების ავთენტიფიკაციის შედეგებს SPF-ისა და DKIM-ისთვის. შეამოწმეთ, რომ პასუხები და მოთხოვნის ბმულები აღწევს განზრახულ დანიშნულებას. შეინარჩუნეთ წინა სერვისი და ჩანაწერები ხელმისაწვდომი, სანამ ჩანაცვლება არ იქნება გადამოწმებული, და წაშალეთ მხოლოდ ის ჩანაწერები, რომლებიც MultiTEL ადასტურებს, რომ ჩანაცვლებულია.