CNAME-запись и email: почему алиасы создают проблемы для почты

A CNAME record (Canonical Name) is a DNS record type that maps one domain name to another. Instead of pointing to an IP address like an A record, a CNAME says: "this name is actually an alias for that other name - go look up the target instead." For web hosting, CNAMEs are convenient and widely used. For email infrastructure, they carry restrictions that trip up administrators regularly.

The core problem is simple: RFC 1034 and RFC 2181 state that a CNAME record cannot coexist with any other record type at the same name. Since email delivery depends on MX records existing at the domain apex, placing a CNAME there breaks mail routing in ways that are not always immediately obvious.

CNAME at the domain apex

Consider a domain example.com. If you set a CNAME on example.com pointing to loadbalancer.cdn.com, you cannot simultaneously have MX records at example.com. DNS resolvers that encounter a CNAME are supposed to follow the alias and ignore any other records at that name. In practice, some resolvers return partial results, others return nothing for the MX query. The outcome: mail to user@example.com fails unpredictably.

This is why DNS providers that offer "CNAME flattening" or "ALIAS" records exist. Cloudflare, for instance, resolves the CNAME target at query time and returns an A record to the client. This preserves compatibility with MX, TXT, and other record types at the apex. It is a provider-side workaround, not a standard DNS feature.

CNAME and MX records

MX records must point to a hostname that resolves via an A or AAAA record, not via a CNAME. RFC 2181 section 10.3 explicitly prohibits MX targets from being CNAME aliases. While some MTAs follow the CNAME chain and deliver the message anyway, this behavior is not guaranteed.

A typical misconfiguration:

Here, mail.example.com is a CNAME alias. A strict MTA will refuse to deliver, because the MX target does not have a direct A record. The fix is straightforward: replace the CNAME with an A record pointing to the IP of mailserver.provider.com.

Где CNAME используется в email корректно

Несмотря на ограничения, CNAME широко и правильно используется в почтовой инфраструктуре - но не на уровне домена-отправителя и не в MX-записях. Самый распространённый случай - настройка DKIM.

Когда вы подключаете домен к ESP (SendGrid, Mailchimp, Amazon SES), вас просят создать CNAME-записи вида:

Здесь CNAME создаётся на поддомене (s1._domainkey), а не на apex. Конфликта с MX нет. ESP управляет целевой записью и может ротировать DKIM-ключи без вашего участия.

CNAME и SPF

SPF-запись - это TXT-запись на домене отправителя. Если на домене стоит CNAME, TXT-запись там же существовать не может (правило "CNAME не сочетается с другими типами"). Значит, SPF работать не будет.

Внутри самой SPF-записи есть механизм include, который ссылается на другой домен. Этот домен может иметь CNAME. Но такая конфигурация добавляет лишний DNS-запрос в цепочку разрешения SPF, и если CNAME ведёт ещё куда-то, можно упереться в лимит 10 DNS-lookups.

CNAME и DMARC

DMARC-запись размещается как TXT-запись на поддомене _dmarc.example.com. Если _dmarc.example.com является CNAME, указывающим на _dmarc.provider.com, то DMARC-политика будет прочитана с целевого домена. RFC 7489 допускает такое поведение, и большинство валидаторов корректно следуют CNAME для DMARC.

Однако стоит учитывать, что вы отдаёте контроль над DMARC-политикой стороннему сервису. Если провайдер изменит запись на целевом домене, ваша политика изменится без вашего ведома. Для критичных доменов лучше хранить DMARC-запись у себя.

Tracking domains и CNAME

ESP используют CNAME для кастомных tracking-доменов. Вместо ссылок вида click.sendgrid.net в теле письма отображается click.example.com. Для этого создаётся CNAME:

Это помогает доставляемости: ссылки на ваш собственный домен вызывают больше доверия у фильтров, чем ссылки на shared tracking domain, который может быть замечен в спаме от других клиентов того же ESP.

Типичные ошибки с CNAME в email

• CNAME на apex при наличии MX. Самый частый случай. Домен перестаёт принимать почту, потому что MX-записи фактически игнорируются.
• MX указывает на CNAME. Формально запрещено стандартами. Работает не везде.
• CNAME для домена-отправителя в envelope. Return-Path содержит домен, который является CNAME. SPF-проверка ломается, потому что TXT-запись на этом домене не может существовать рядом с CNAME.
• Длинные CNAME-цепочки. CNAME ведёт на другой CNAME, тот на третий. Каждый шаг - дополнительный DNS-запрос и потенциальная точка отказа. Некоторые резолверы обрывают цепочку после 8-10 переходов.

Проверка CNAME и валидация адресов

При валидации email-адреса проверяется DNS домена получателя. Если домен имеет CNAME на apex, валидатор следует за алиасом и ищет MX-записи на целевом домене. Если MX нет ни на исходном, ни на целевом домене, адрес признаётся невалидным.

На практике домены с CNAME на apex встречаются редко среди тех, что принимают почту. Но среди маркетинговых доменов, используемых только для отправки, такая конфигурация может существовать - и создавать проблемы при bounce-обработке.