TXT-записи: SPF, DKIM и DMARC

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

Суть проблемы в том, что SMTP, разработанный в 1982 году, позволяет любому серверу заявить, что он отправляет почту от имени любого домена. Протокол этому ничего не препятствует. SPF, DKIM и DMARC — три уровня, добавленные позже, чтобы это исправить, и все три живут в TXT-записях.

SPF: какие серверы могут отправлять почту от вашего имени

SPF (Sender Policy Framework) публикует список серверов, которым разрешено отправлять почту от имени вашего домена. Принимающий сервер сравнивает IP подключившегося отправителя с этим списком.

example.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com ip4:93.184.216.34 ~all"

DKIM: криптографическая подпись

DKIM (DomainKeys Identified Mail) подписывает каждое исходящее сообщение закрытым ключом. Соответствующий открытый ключ вы публикуете в DNS, а получатели проверяют подпись.

selector1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."

Часть selector1 выбирает ваш почтовый провайдер, и она включается в каждое подписанное сообщение, чтобы получатели знали, какой ключ запрашивать. Селекторы позволяют менять ключи или использовать нескольких провайдеров без конфликтов.

Преимущество DKIM перед SPF в том, что подпись охватывает само сообщение, поэтому она переживает пересылку. Слабость в том, что он ничего не говорит о сообщениях, приходящих вообще без подписи, — этот пробел и закрывает DMARC.

DMARC: что делать, если первые два не прошли

DMARC (Domain-based Message Authentication, Reporting and Conformance) связывает остальные два: он требует, чтобы SPF или DKIM не просто проходили, но и совпадали (alignment) с видимым адресом From, и сообщает получателям, что делать при неудаче.

_dmarc.example.com.    IN    TXT    "v=DMARC1; p=quarantine; rua=mailto:reports@example.com; pct=100"

Безопасное внедрение всех трёх

Порядок важен. Сразу перейти на p=reject — классический способ сделать собственные счета недоставляемыми.

1. 1

   Составьте опись всего, что отправляет почту от вашего имени

   Ваш почтовый провайдер, конечно, но также инструменты выставления счетов, CRM, маркетинговые платформы, системы заявок и транзакционная почта вашего приложения. Всё, что здесь пропустите, позже сломается.

2. 2

   Опубликуйте SPF с мягким отказом

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

3. 3

   Включите подпись DKIM

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

4. 4

   Начните DMARC с p=none

   Только мониторинг. Собирайте агрегированные отчёты две-четыре недели: они выявят забытых отправителей.

5. 5

   Ужесточайте постепенно

   Когда по отчётам проходят только законные источники, переходите на p=quarantine, при желании сначала с pct=25, а затем на p=reject, когда всё чисто.

TXT-записи нужны не только для почты

Тот же тип записи несёт подтверждение владения доменом для десятков сервисов: Google Search Console, Microsoft 365, Facebook и другие просят опубликовать токен в виде записи TXT, а затем проверяют его наличие.

example.com.    IN    TXT    "google-site-verification=rXsLp2..."
example.com.    IN    TXT    "MS=ms12345678"

Они прекрасно уживаются вместе. У домена может быть много TXT-записей; правило лишь в том, что запись, начинающаяся с v=spf1, должна быть ровно одна.

Проверьте любой домен в инструменте поиска, чтобы увидеть все его TXT-записи вместе: так быстро заметить дубликат SPF-записи или токен подтверждения, который так и не удалили.