Налаштуйте домен брендованого інструмента перенесення номерів і автентифіковане надсилання електронної пошти для домену, яким ви володієте, використовуючи імена хостів і значення DNS, які MultiTEL підтверджує для вашої служби. Ці налаштування є окремими від перенесення телефонного номера.
Для чого призначене це налаштування
Інструмент перенесення номерів під вашим брендом (white-label) дає змогу представляти запити на перенесення номерів під вашим власним брендом і, якщо його налаштовано, надсилати електронні листи із запитами від імені вашого власного поштового домену. Зміни DNS у цьому посібнику стосуються цього брендованого вебсайту та поштової ідентичності. Вони не є вимогою для звичайного перенесення телефонного номера і не змінюють голосову маршрутизацію телефонного номера.
Ви повинні володіти доменом, DNS якого змінюватимете, і керувати ним. Ви не можете налаштувати ці записи для адреси на сторонньому безкоштовному поштовому домені, яким ви не володієте.
Підтвердьте брендовану службу перед зміною DNS
Відкрийте Перенесення номерів. Скористайтеся полями брендування там, щоб задати назву бренду та логотип, які використовуються для запитів на цьому екрані. Для сайту під вашим брендом (white-label) з власним доменом попросіть службу підтримки MultiTEL підтвердити, які налаштування бренду застосовуються, ім'я хоста, значення DNS для публікації, домен відправника та налаштування сертифіката HTTPS для вашого облікового запису, перш ніж публікувати будь-які записи DNS.
Не переспрямовуйте наявний робочий вебсайт і не змінюйте наявну доставку пошти лише для того, щоб брендувати запит на перенесення номера. Зафіксуйте попередні значення 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. Показаний тут include SPF MultiTEL — це include:_spf.multitel.net. Додавайте його лише після того, як служба підтримки підтвердить, що він застосовується до служби надсилання для вашого облікового запису.
Якщо домен уже має TXT-запис SPF, об'єднайте авторизований include із цією наявною політикою. Збережіть інших легітимних відправників і передбачену кінцеву політику; не публікуйте другий запис SPF. Перевірте всю політику, включно з вкладеними include і redirect, щодо обмежень DNS-пошуків SPF. Оцінювання 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 відкритого ключа, підтверджені для вашого домену підписування. Ім'я DNS DKIM поєднує селектор, _domainkey і домен підписування. Наприклад, селектор mail для example.com дає повне ім'я запису mail._domainkey.example.com; mail._domainkey — це відносне ім'я запису, а не селектор. Отримайте поточні значення від служби підтримки MultiTEL; не припускайте, що селектор або відкритий ключ, скопійований зі старої статті, іншого облікового запису чи власного DNS MultiTEL, є значенням, яке використовується для вашого облікового запису. Відкритий ключ DKIM публікується в DNS; приватний ключ підписування ніколи не можна ні запитувати, ні публікувати.
Перевірте, чи консоль DNS автоматично дописує ім'я зони, і уникайте дублювання домену або _domainkey в імені запису. Збережіть повне значення відкритого ключа, коли консоль DNS розбиває довгий TXT-запис на фрагменти в лапках.
Перевірте повний результат
Зробіть запит до авторитативних серверів імен і зовнішнього резолвера для кожного зміненого запису. Дайте налаштованому TTL і кешам DNS час спливти; результату з одного кешованого локального резолвера недостатньо. Порівняйте повністю кваліфіковане ім'я запису, тип, точну ціль або значення, лапки та будь-яку кінцеву крапку з підтвердженими інструкціями та форматом введення вашого постачальника DNS. Усуньте конфліктні записи, неправильні імена, відсутні значення та недійсні сертифікати, перш ніж поширювати URL-адресу або покладатися на брендовану електронну пошту.
Відкрийте підтверджену брендовану URL-адресу запиту і підтвердьте, що сторінки завантажуються з дійсним сертифікатом і очікуваним брендом. Перш ніж надсилати будь-який тест, запитайте службу підтримки MultiTEL, який тестовий процес доступний і чи ініціювало б надсилання реальне перенесення номера. Після того як служба підтримки підтвердить, що брендована електронна пошта ввімкнена для вашого облікового запису, тестуйте її лише через підтверджений тестовий процес і зі зразковими даними або за тестовою процедурою, які надає служба підтримки, щоб не ініціювати реальне перенесення номера. Перегляньте результати автентифікації отриманого повідомлення щодо SPF і DKIM. Перевірте, що відповіді та посилання запитів надходять до передбаченого місця призначення. Зберігайте попередню службу та записи доступними, доки заміну не буде перевірено, і видаляйте лише ті записи, які MultiTEL підтверджує як замінені.