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

CNAME-запись (Canonical Name) это тип DNS-записи, который сопоставляет одно доменное имя другому. Вместо IP-адреса, как у A-записи, CNAME говорит: «это имя на самом деле псевдоним вон того, иди спрашивай про него». Для веб-хостинга CNAME удобны и широко используются. В почтовой инфраструктуре у них есть ограничения, на которые администраторы регулярно наступают.

Корень проблемы простой. RFC 1034 и RFC 2181 говорят, что CNAME-запись не может соседствовать ни с какой другой записью на том же имени. А поскольку доставка почты держится на MX-записях в корне домена, CNAME, поставленный туда, ломает маршрутизацию письма способами, которые не всегда заметны сразу.

Где 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-политика будет прочитана с целевого домена. Стандарт DMARC отдельно об этом ничего не говорит: это обычная работа DNS, резолвер сам проходит по CNAME (RFC 1034, раздел 3.6.2), и проверяющий сервер получает TXT целевого имени.

Однако стоит учитывать, что вы отдаёте контроль над 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-обработке.