Cname record — how it works, alternatives & advanced use cases

Как работает DNS

Доменное имя содержит, как минимум, две части (обычно называются метками), разделённые точкой. Самая правая метка является доменом верхнего уровня (например, для адреса ru.wikipedia.org домен верхнего уровня — org). Каждая следующая метка справа налево является поддоменом (например, wikipedia.org — поддомен домена org, а ru.wikipedia.org — домена wikipedia.org). Теоретически такое деление может достигать глубины 127 уровней, а каждая метка может содержать до 63 символов, пока общая длина вместе с точками не достигнет 254 символов. Но на практике регистраторы доменных имён используют более строгие ограничения.
Система DNS содержит иерархию серверов DNS. Каждый домен или поддомен поддерживается как минимум одним авторизированным сервером DNS, на котором расположена информация о домене. Иерархия серверов DNS совпадает с иерархией доменов.

Рассмотрим на примере работу всей системы.
Предположим, мы набрали в браузере адрес ru.wikipedia.org. Браузер знает только IP-адрес сервера DNS, обычно это один из серверов интернет-провайдера. Он спрашивает у сервера DNS: «какой IP-адрес у ru.wikipedia.org?». Сервер DNS обращается к корневому серверу — например, 198.41.0.4. Этот сервер сообщает — «У меня нет информации о данном адресе, но я знаю, что 204.74.112.1 поддерживает доменную зону org.» Браузер направляет свой запрос к 204.74.112.1, но тот отвечает «У меня нет информации о данном сервере, но я знаю, что 207.142.131.234 поддерживает доменную зону wikipedia.org.» Наконец, браузер отправляет свой запрос к третьему DNS-серверу (который является авторизированным сервером для домена wikipedia.org), и получает ответ — IP-адрес. Этот процесс называется рекурсивным поиском.

Имя хоста и IP-адрес не тождественны — хост с одним IP может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо — одному имени может быть сопоставлено множество хостов: это позволяет создавать балансировку нагрузки.
Запрос на определение имени обычно не идёт дальше кэша DNS, который помнит (ограниченное время) ответы на запросы, проходившие через него ранее. Организации или провайдеры могут по своему усмотрению организовывать кэш DNS. Обычно вместе с ответом приходит информация о том, сколько времени следует хранить эту запись в кэше.
Для повышения устойчивости системы используется множество серверов, содержащих идентичную информацию. Существует 13 корневых серверов, расположенных по всему миру и привязанных к своему региону, их адреса никогда не меняются, а информация о них есть в любой операционной системе.
Протокол DNS использует для работы TCP- или UDP-порт 53 для ответов на запросы. Традиционно запросы и ответы отправляются в виде одной UDP датаграммы. TCP используется в случае, если ответ больше 512 байт, или в случае AXFR-запроса.

Прочие механизмы

Здесь мы рассмотрим оставшиеся механизмы, которые используются в настройках значительно реже.

ptr

PTR-запись IP-адреса отправителя проверяется на соответствие указанному домену. Данный механизм требует большого количества DNS-запросов при проверке, поэтому без острой необходимости использовать его в SPF не рекомендуется. 

v=spf1 ptr:other-domain.com -all

— принимать почту со всех адресов, PTR-запись которых направлена на домен other-domain.com 

exists

Запрашивается А-запись указанного домена; если она существует, проверка считается пройденной. Другими словами, проверяется, резолвится ли домен на какой-либо (любой) IP-адрес.

v=spf1 exists:mydomain.com -all

— принимать почту, если существует A-запись домена mydomain.com. 

exp

Параметр «exp» применяется для отправки сообщения об ошибке отправителю письма. С помощью «exp» в SPF прописывается определенный поддомен, в TXT-записи которого указан текст сообщения об ошибке. Имя поддомена и текст ошибки может быть любым.

Параметр «exp» всегда указывается в конце записи (после all). 

Например: 

v=spf1 mx -all exp=error-spf.mydomain.com

При этом TXT-запись домена error-spf.mydomain.com содержит: «Not authorized to send mail for this domain».

Restrictions on CNAME Records

• A CNAME cannot be placed at the root domain level, because the root domain is the DNS Start of Authority (SOA) which must point to an IP address.
• CNAME records must point to another domain name, never to an IP address.
• A hostname defined in a CNAME record must have no other resource records of other types (MX, A, etc.), except for DNSSEC records like RRSIG and NSEC.
• CNAME records can point to other CNAME records, but this is not considered a good practice as it is inefficient.
• MX and NS records must never point to a CNAME alias.
• Domains that are used for e-mail may not have a CNAME record — this can have undesirable results with different mail servers.

PTR-запись

Запись PTR (pointer), или запись указателя, связывает IP хоста с его каноническим именем. Запрос в домене in-addr.arpa на IP хоста в reverse-форме вернет имя (FQDN) данного хоста.

Чтобы уменьшить объем нежелательной корреспонденции (спама), многие серверы-получатели электронной почты могут проверять наличие PTR-записи для хоста, с которого происходит отправка. В этом случае PTR-запись для IP-адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе -сессии.

Данная запись применяется при создании обратной DNS-зоны.

При создании записи можно указать следующие параметры:

• PTR — IP-адрес хоста в зоне in-addr-arpa;
• имя хоста — имя хоста, расположенного на данном IP-адресе.

Нажмите «Добавить» — созданная запись появится в списке.

Ресурсные записи для домена

То же относится к настройке электронной почты и других веб-сервисов. Провайдер вносит данные в автоматическом режиме или вручную в панели управления хостингом. Второе чаще востребовано в случае аренды платных DNS-серверов. Например, если у компании одновременно работает сразу несколько сайтов (существуют тарифы до 150 доменов и 12 000 записей).

Базовые типы записей:

1. NS – основной тип, позволяет определять адреса, закрепленные за доменом.
2. A – привязывает имя сайта к одному IP по протоколу IPv4. Возможно внесение нескольких записей с разными IP-адресами.
3. AAAA – аналог предыдущей записи, но имеет отношение к IPv6.
4. CNAME – помечает домен как привязанный к другому в качестве псевдонима (алиаса).
5. MX – указывает имя сервера, ответственного за прием почты для домена. На одном сайте возможно внесение нескольких MX-записей с различным приоритетом.
6. TXT – позволяет сохранить произвольную информацию; используется в пользовательских целях, в частности для подтверждения подключения сервисов аналитики.
7. SOA – содержит служебные данные вроде последней даты обновления доменной зоны или адреса администратора.

Рекурсивное разрешение имен

Рекурсивное разрешение имен — это процесс, с помощью которого DNS-сервер использует иерархию зон и делегирований для реагирования на запросы, для которых он не является полномочным.

В некоторых конфигурациях DNS-серверы включают корневые ссылки (то есть список имен и IP-адресов), которые позволяют им запрашивать корневые серверы DNS. В других конфигурациях серверы пересылают все запросы, которые они не могут ответить на другой сервер. Пересылка и корневые указания являются методами, которые DNS-серверы могут использовать для разрешения запросов, для которых они не являются полномочными.

Разрешение имен с помощью корневых ссылок

Корневые ссылки позволяют любому DNS-серверу размещать корневые серверы DNS. После того как DNS-сервер обнаружит корневой сервер DNS, он может разрешить любой запрос для этого пространства имен. На следующем рисунке показано, как DNS разрешает имя с помощью корневых ссылок.

В этом примере происходят следующие события:

1. Клиент отправляет рекурсивный запрос на DNS-сервер для запроса IP-адреса, соответствующего имени ftp.contoso.com. Рекурсивный запрос указывает, что клиент хочет получить окончательный ответ на запрос. Ответ на рекурсивный запрос должен быть допустимым адресом или сообщением, указывающим, что адрес не найден.
2. Так как DNS-сервер не является полномочным для имени и не имеет ответа в своем кэше, DNS-сервер использует корневые ссылки для поиска IP-адреса корневого сервера DNS.
3. DNS-сервер использует итеративный запрос, чтобы запросить у корневого сервера DNS разрешение имени ftp.contoso.com. Итеративный запрос указывает, что сервер будет принимать ссылку на другой сервер вместо определенного ответа на запрос. Так как имя ftp.contoso.com заканчивается на метку com, корневой сервер DNS возвращает ссылку на COM-сервер, на котором размещена зона com.
4. DNS-сервер использует итеративный запрос, чтобы запросить у COM-сервера разрешение имени ftp.contoso.com. Так как имя ftp.contoso.com заканчивается именем contoso.com, com-сервер возвращает ссылку на сервер Contoso, на котором размещена зона contoso.com.
5. DNS-сервер использует итеративный запрос, чтобы попросить сервера Contoso разрешить имя ftp.contoso.com. Сервер Contoso находит ответ в данных зоны, а затем возвращает ответ на сервер.
6. Затем сервер возвращает результат клиенту.

Разрешение имен с помощью пересылки

Пересылка позволяет маршрутизировать разрешение имен через определенные серверы вместо использования корневых ссылок. На следующем рисунке показано, как DNS разрешает имя с помощью пересылки.

В этом примере происходят следующие события:

1. Клиент запрашивает DNS-сервер для имени ftp.contoso.com.
2. DNS-сервер перенаправляет запрос на другой DNS-сервер, который называется сервером пересылки.
3. Поскольку сервер пересылки не является полномочным для имени и не имеет ответа в своем кэше, он использует корневые ссылки для поиска IP-адреса корневого сервера DNS.
4. Сервер пересылки использует итеративный запрос, чтобы запросить у корневого сервера DNS разрешение имени ftp.contoso.com. Так как имя ftp.contoso.com заканчивается именем com, корневой сервер DNS возвращает ссылку на COM-сервер, на котором размещена зона com.
5. Сервер пересылки использует итеративный запрос, попросив серверу com разрешить имя ftp.contoso.com. Так как имя ftp.contoso.com заканчивается именем contoso.com, com-сервер возвращает ссылку на сервер Contoso, на котором размещена зона contoso.com.
6. Сервер пересылки использует итеративный запрос, чтобы попросить сервера Contoso разрешить имя ftp.contoso.com. Сервер Contoso находит ответ в файлах зоны, а затем возвращает ответ на сервер.
7. Затем сервер пересылки возвращает результат исходному DNS-серверу.
8. Затем исходный DNS-сервер возвращает результат клиенту.

Способы проверки DNS-записей домена

А зачем проверять DNS-записи? Ошибки, допущенные в ресурсных записях, приводят к нарушению работоспособности сайта. Даже после внесения всех правок полноценный доступ к сайту появится не сразу, так как изменения, внесенные в ресурсные записи, вступают в силу в течение 72 часов.

Есть множество способов, позволяющих проверить DNS-записи. Можно воспользоваться как специальными командами в системе, так и онлайн-сервисами.

Встроенные в систему службы

nslookup. Действует на ОС Windows и Linux. С помощью этой утилиты можно точно узнать информацию об IP-адресе, а еще о настройке всех ресурсных записей. Утилита запускается через «Командную строку» в Windows и «Терминал» в Linux. Вводить команду нужно одинаково в обоих случаях и примерно вот так:

nslookup -type=тип_записи site.com

host. Эта утилита используется в ОС Linux. Она есть в стандартном пакете командной строки «Терминал». С ее помощью можно проверить все виды запросов к DNS-серверу. Вводится команда вот таким образом:

host site.com

Можно перед доменным именем добавить опцию -t и указать тип записи для получения более подробного поиска. Выглядеть это будет примерно вот так:

host -t A site.com

host -t MX site.com

Проверка DNS-записей с помощью сторонних сервисов

Еще можно воспользоваться бесплатными онлайн-сервисами для проверки DNS записей.

2whois.ru – известный сайт, с помощью которого можно узнать DNS-записи самого разного типа. Просто нужно указать домен в соответствующей строке и начать проверку.

dns.nettools.ru – очень удобный сервис, в котором можно получить информацию не только о ресурсных записях, но и возможности выполнения рекурсивных запросов, а также проверки сервера на возможность выгрузки данных.

functions-online.com – здесь тоже очень удобно проверять настройки DNS-записей самых различных типов. Сервис дает полную информацию, а еще предоставляет PHP документацию на разных языках.

 mail-tester.com – сервис поможет определить, попадет ли письмо, отправленное с вашего сервера, в «Спам». Еще здесь можно определить ошибки в ссылках и проверить качество форматирования писем.

xseo.in/dns – на данном ресурсе есть раздел для проверки самых разных DNS записей. 

digwebinterface.com – навороченный онлайн-сервис с очень простым исполнением. С первого взгляда может показаться сложным, но на самом деле справиться с ним может даже новичок.

Какие DNS выбрать для сайта

Многих владельце сайтов волнует вопрос, какие DNS выбрать для сайта? При регистрации домена требуется указать NS-сервера – ресурс, который предоставляет функциональность DNS. Можно воспользоваться DNS регистратора для парковки домена, но обычно сразу задаются DNS купленного хостинга и уже там производится настройка остальных параметров.

Однако DNS можно задать любые, а не использовать стандартные. Зачем менять DNS? Как правило, стандартные DNS предлагают скромные возможности, поэтому можно сменить их на расширенные. Например, сменить DNS может пригодиться для различных операций: когда нужно сделать почту для домена, для более быстрой загрузки сайта, для более удобного управления записями и т.д.

Что представляет собой DNS?

Интернет — это сеть, которая объединяет между собой миллионы компьютеров. В сети находятся компьютеры, работающие круглосуточно и без остановок. Как правило, это серверы, которые используются для хранения сайтов и электронной почты. Каждый компьютер при подключении к сети интернет получает специальный идентификатор в числовом виде. Другими словами, ip-адрес. Конечно, к серверу можно обратиться и с помощью числового идентификатора, но вот практика показывает, что людям не будет удобно запоминать адреса в виде чисел. Поэтому разработчики ввели систему буквенных доменов.

Domain Name System, или DNS — это специальная система, которая обеспечивает соответствие доменов их числовым адресам. В интернете есть специальный класс серверов — ns-серверы, которые отвечают за хранение DNS. Там можно проверить домена DNS записи. Их поддерживают с двух сторон — со стороны интернет-провайдеров и хостеров, а также со стороны администраторов доменных зон. Данные сервера имеют свою иерархию.

How do you perform a DNS lookup to check CNAME records?

Checking CNAME records can be done in many ways, the easiest of which is to use the online CNAME lookup tool on this page.

Alternatively, you may manually check records locally from your own system. Manually checking records is a little more involved, can be difficult to understand the results and will be different depending on your operating system.

Checking CNAME records online

To use the online CNAME lookup tool, simply enter the CNAME record into the search box and press search to perform a DNS CNAME lookup. Optionally choose a server to perform the lookup request.

Using the online tool provides many benefits over the manual tools as it can display, parse & highlight relevant information in a way that is easier to read than many command-line tools. Additionally, specifying alternative DNS resolvers to check against is as simple as choosing from a drop down without the need of knowing the IP address of these providers.

Checking CNAME records on Windows

On Windows based systems including Windows 7, Windows 10 & Windows Server, using the tool allows you to perform a DNS lookup for CNAME records using your local resolver or specify any public recursive resolver.

Using the nslookup command

Using the locally configured resolver:

nslookup
> set q=cname
> www.example.com

Using a specific resolver:

nslookup
> set q=cname
> server 1.1.1.1
> www.example.com

Checking CNAME records on Linux and Mac

On Linux and Mac systems including Mac OS X, MacOS, Ubuntu, Debian, CentOS & Red Hat, you have the choice of using either the tool, or the more powerful tool to perform a DNS CNAME lookup.

Using the host command

Using the locally configured resolver:

host -t cname www.example.com

Using a specific resolver:

host -t cname www.example.com 1.1.1.1

Using the dig command

Using the locally configured resolver:

dig cname www.example.com

Using a specific resolver:

dig cname www.example.com @1.1.1.1

Записи DNS

Записи DNS, или Ресурсные записи (англ. Resource Records, RR) — единицы хранения и передачи информации в DNS. Каждая ресурсная запись состоит из следующих полей:

• имя (NAME) — доменное имя, к которому привязана или которому «принадлежит» данная ресурсная запись,
• тип (TYPE) ресурсной записи — определяет формат и назначение данной ресурсной записи,
• класс (CLASS) ресурсной записи; теоретически считается, что DNS может использоваться не только с TCP/IP, но и с другими типами сетей, код в поле класс определяет тип сети,
• TTL (Time To Live) — допустимое время хранения данной ресурсной записи в кэше неответственного DNS-сервера,
• длина поля данных (RDLEN),
• поле данных (RDATA), формат и содержание которого зависит от типа записи.

Наиболее важные типы DNS-записей:

• Запись A (address record) или запись адреса связывает имя хоста с адресом протокола IPv4. Например, запрос A-записи на имя referrals.icann.org вернёт его IPv4-адрес — 192.0.34.164.
• Запись AAAA (IPv6 address record) связывает имя хоста с адресом протокола IPv6. Например, запрос AAAA-записи на имя K.ROOT-SERVERS.NET вернёт его IPv6-адрес — 2001:7fd::1.
• Запись CNAME (canonical name record) или каноническая запись имени (псевдоним) используется для перенаправления на другое имя.
• Запись MX (mail exchange) или почтовый обменник указывает сервер(ы) обмена почтой для данного домена.
• Запись NS (name server) указывает на DNS-сервер для данного домена.
• Запись PTR (point to reverse) или запись указателя связывает IP-адрес хоста с его каноническим именем. Запрос в домене in-addr.arpa на IP-адрес хоста в reverse-форме вернёт имя (FQDN) данного хоста (см. Обратный DNS-запрос). Например (на момент написания), для IP-адреса 192.0.34.164 запрос записи PTR 164.34.0.192.in-addr.arpa вернёт его каноническое имя referrals.icann.org. В целях уменьшения объёма нежелательной корреспонденции (спама) многие серверы-получатели электронной почты могут проверять наличие PTR-записи для хоста, с которого происходит отправка. В этом случае PTR-запись для IP-адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP-сессии.
• Запись SOA (Start of Authority) или начальная запись зоны указывает, на каком сервере хранится эталонная информация о данном домене, содержит контактную информацию лица, ответственного за данную зону, тайминги (параметры времени) кеширования зонной информации и взаимодействия DNS-серверов.
• SRV-запись (server selection) указывает на серверы для сервисов, используется, в частности, для Jabber и Active Directory.

Интернациональные доменные имена

Доменное имя может состоять только из ограниченного набора ASCII-символов, позволяя набрать адрес домена независимо от языка пользователя. ICANN утвердил основанную на Punycode систему IDNA, преобразующую любую строку в кодировке Unicode в допустимый DNS набор символов.

Имена доменов

Система доменных имен — это иерархия доменов. Иерархия начинается с корневого домена с именем ‘ . ‘. Ниже находятся домены верхнего уровня, такие как com, net, org, uk и jp. Под этими доменами верхнего уровня расположены домены второго уровня, например org.uk и co.jp. Эти домены в иерархии DNS глобально распределены на DNS-серверах по всему миру.

Регистратор доменных имен — это организация, которая позволяет приобрести доменное имя, например . Купив доменное имя, вы получаете право управлять иерархией DNS под этим именем, например настроить перенаправление на веб-сайт вашей компании при вводе адреса . Регистратор может размещать домен на своих собственных серверах доменных имен от вашего имени, либо вы можете указать альтернативные серверы доменных имен.

Azure DNS предоставляет глобально распределенную инфраструктуру серверов доменных имен высокого уровня доступности, которую можно использовать для размещения вашего домена. Размещая домены в Azure DNS, вы можете управлять своими записями DNS с помощью тех же учетных данных, API, инструментов, выставления счетов и поддержки, что и в других службах Azure.

Azure DNS в настоящее время не поддерживает приобретение доменных имен. Если необходимо приобрести доменное имя, требуется использовать регистратор доменных имен стороннего поставщика. Регистратор обычно взимает небольшую годовую плату. Затем вы сможете разместить домены в Azure DNS, чтобы управлять записями DNS. Дополнительные сведения см. в статье Делегирование домена в Azure DNS.

When to use CNAME records and why are they useful?

CNAME records can be used for many reasons and can be useful when maintaining your DNS zone configuration.

Some examples of why you may use CNAME records:

Easier Management — The most common use of a CNAME record is so that you only need to configure the underling IP address once. For example, the base domain name would have an IP address configured as an A or AAAA record, while having CNAME records point back to this record for subdomains like . This means that when updating the IP address, you are only required to update the address on the record and the subdomain will be updated automatically.

Service Providers — Another common case for using CNAME records is when you are using third party services. Often these third parties will ask you to use a CNAME record to point a subdomain to their domain name which allows them to change IP addresses as they need without having to ask all their customers to make the change manually. If this is the case, you may set up a CNAME record for to point to .

Domain Verification — Often TXT records are used for domain verification, but sometimes providers also use CNAME records. Providers may generate a unique verification code as a subdomain which they ask you to point to them to prove ownership of a parent domain name. For example, you may be required to set up a CNAME record like which points to .

Зоны DNS

Зона DNS используется для размещения DNS-записей определенного домена. Чтобы разместить свой домен в Azure DNS, необходимо создать зону DNS для этого доменного имени. Каждая запись DNS для вашего домена создается внутри этой зоны DNS.

Например, домен contoso.com может содержать несколько записей DNS, включая mail.contoso.com (для почтового сервера) и www.contoso.com (для веб-сайта).

При создании зоны DNS в Azure DNS учитывайте следующее.

• Имя зоны должно быть уникальным в пределах группы ресурсов, а зона не должна существовать. В противном случае операция завершится ошибкой.
• То же имя зоны можно использовать повторно в другой группе ресурсов или другой подписке Azure.
• Если нескольким зонам присвоено одно и то же имя, каждому экземпляру назначаются разные адреса серверов доменных имен. С помощью регистратора доменных имен можно настроить только один набор адресов.

Примечание

Для создания зоны DNS с доменным именем в Azure DNS необязательно быть его владельцем. Однако, чтобы настроить серверы доменных имен Azure DNS в качестве правильных серверов для доменного имени с помощью регистратора доменных имен, необходимо быть владельцем домена.

Дополнительные сведения см. в статье Делегирование домена в Azure DNS.

Этап 1. Добавление записи типа TXT или MX для подтверждения права собственности на домен

Рекомендуется: Проверка с помощью записи TXT

Сначала необходимо подтвердить, что вы владеете доменом, который вы хотите добавить в Microsoft 365.

1. Войдите в центр администрирования Microsoft 365, а затем выберите Показать все > Настройки > Домены.

2. В новой вкладке или окне браузера, войдите в свой поставщик услуг размещения DNS и найдите место, в котором вы управляете параметрами DNS (например, параметры файла зоны, управление доменами, диспетчер доменов, диспетчер DNS).

3. Перейдите на страницу диспетчера DNS поставщика, добавьте запись TXT, указанную в центре администрирования, в ваш домен.

   Добавление этой записи не повлияет на ваши существующие сообщения электронной почты и другие службы, и вы можете безопасно удалить ее после подключения домена к Microsoft 365.

   Пример.

   • Имя TXT:
   • Значение TXT: MS=ms######## (уникальный идентификатор из центра администрирования);
   • TTL: (или значение вашего поставщика по умолчанию)

4. Сохраните запись, вернитесь в центр администрирования и выберите Проверить. Как правило, регистрация изменений занимает около 15 минут, но иногда это может занять больше времени. Предоставьте процессу некоторое время и выполните несколько попыток, чтобы изменение вступило в силу.

Когда продукт корпорации Майкрософт обнаружит правильную запись TXT, ваш домен будет подтвержден.

Проверка с помощью записи MX

Если регистратор не поддерживает добавление записей типа TXT, выполните проверку, добавив запись MX.

1. Войдите в центр администрирования Microsoft 365, а затем выберите Показать все > Настройки > Домены.
2. В новой вкладке или окне браузера, войдите в свой поставщик услуг размещения DNS и найдите место, в котором вы управляете параметрами DNS (например, параметры файла зоны, управление доменами, диспетчер доменов, диспетчер DNS).
3. Перейдите на страницу диспетчера DNS поставщика, добавьте запись MX, указанную в центре администрирования, в ваш домен.

Priority (Приоритет) этой записи MX должен быть самым высоким из всех существующих записей MX для домена. В противном случае она может помешать отправке и получению электронной почты. Такие записи следует удалить сразу после завершения проверки домена.

Убедитесь, что значения полей точно соответствуют указанным ниже.

• Record Type (Тип записи):
• Приоритет: установите любое крупное значение, которое еще не используется.
• Host Name (Имя узла):
• Указывает на адрес: скопируйте значение из центра администрирования и вставьте его сюда.
• TTL: (или значение вашего поставщика по умолчанию)

Когда продукт корпорации Майкрософт обнаружит правильную запись MX, ваш домен будет подтвержден.