Как настроить DKIM, DMARC и SPF для домена: правильный подход

Без SPF, DKIM и DMARC письма с вашего домена легко подделать: спамеры шлют «от имени» support@ваш-домен, а фильтры и ящики получателей относятся к рассылке с недоверием. Три DNS-механизма закрывают разные слои проверки. Ниже – что это, как собрать записи и в каком порядке их вводить, чтобы не уронить доставляемость.

SPF, DKIM и DMARC: роли

  • SPF (Sender Policy Framework) – TXT-запись у домена со списком хостов, которым разрешено отправлять почту от имени домена. Получатель смотрит IP/HELO отправителя и сверяет с политикой.
  • DKIM (DomainKeys Identified Mail) – цифровая подпись тела и выбранных заголовков. Публичный ключ лежит в DNS, приватный – на MTA (Postfix, Exim, сервис рассылок). Если письмо не меняли по пути, подпись сходится.
  • DMARC (Domain-based Message Authentication, Reporting and Conformance) – политика поверх SPF/DKIM: что делать, если проверки не прошли, и куда слать отчёты. Плюс требование alignment: домен в From должен согласовываться с доменом SPF/DKIM.

По отдельности механизмы слабые: SPF ломается на пересылках, DKIM без DMARC не говорит, как поступать с «левыми» письмами. Вместе они дают и техническую проверку, и политику для получателя.

Что ломается без настройки

  • письма уходят в спам или отклоняются крупными провайдерами;
  • фишинг от «вашего» домена бьёт по репутации бренда;
  • нет отчётов: вы не видите, кто шлёт от вашего имени и где падает alignment.

Порядок внедрения

Разумная схема: сначала инвентаризация всех отправителей (свой SMTP, Google Workspace, Microsoft 365, SendGrid, CRM, тикеты), потом SPF, затем DKIM на каждом легитимном источнике, в конце DMARC с мягкой политикой и постепенным ужесточением.

1. SPF

Одна TXT-запись на имя домена (или поддомена, с которого реально шлёте). Несколько SPF-записей на одно имя – ошибка: многие резолверы берут одну или считают политику невалидной.

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all
  • include: – механизмы чужих сервисов (смотрите документацию провайдера);
  • ip4: / ip6: – свои серверы;
  • ~all (softfail) на время отладки, -all (fail) когда список полный;
  • лимит DNS-lookup: не больше 10 (включая вложенные include) – иначе SPF «ломается».

2. DKIM

На стороне MTA или сервиса рассылок генерируете пару ключей (RSA 2048+ предпочтительнее 1024). Публичный ключ публикуете TXT-записью вида:

selector._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBg..."

selector – произвольное имя (mail, s1, google). В письме заголовок DKIM-Signature укажет тот же selector. Для ротации ключей заводят новый selector, ждут распространения DNS, переключают подпись, старый ключ снимают.

3. DMARC

TXT на _dmarc.example.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensics@example.com; fo=1; adkim=r; aspf=r; pct=100
  • p=none – только мониторинг (старт);
  • p=quarantine – в спам при fail;
  • p=reject – жёсткий отказ;
  • rua – агрегированные XML-отчёты (раз в сутки от крупных провайдеров);
  • adkim/aspf: r relaxed, s strict alignment.

Типичный путь: 2-4 недели p=none, разбор отчётов, правка SPF/DKIM, затем quarantine и только после стабильных «pass» – reject. Поддомены наследуют политику, если не задали свою; для mail.example.com иногда нужна отдельная запись.

Проверка

dig +short TXT example.com
dig +short TXT selector._domainkey.example.com
dig +short TXT _dmarc.example.com

Онлайн: MXToolbox, mail-tester.com, dmarcian, Google Admin Toolbox. Отправьте тестовое письмо на Gmail/Outlook и в исходниках письма смотрите Authentication-Results: spf=pass, dkim=pass, dmarc=pass.

Частые ошибки

  • два и больше SPF на одном имени;
  • забыли include сервиса рассылок – маркетинг «ломает» DMARC;
  • DKIM-ключ обрезан в DNS (лимит длины TXT: разбивайте на части в кавычках);
  • сразу p=reject без отчётов – режутся легитимные письма;
  • From на одном домене, а SPF/DKIM только на другом, без alignment.

Сопровождение

Раз в квартал сверяйте список include с реальными отправителями. При смене ESP добавьте SPF/DKIM до cutover. Отчёты DMARC удобно складывать в парсер (свой ящик + скрипт или SaaS). Дополнительно к тройке: TLS (MTA-STS, TLS-RPT), 2FA на почтовых ящиках, обучение людей не кликать по «срочным» письмам от «бухгалтерии».

Краткий чеклист

  1. Собрать все IP и сервисы, которые шлют от домена.
  2. Опубликовать один корректный SPF с ~all или -all.
  3. Включить DKIM на каждом источнике, проверить selector в DNS.
  4. DMARC p=none + rua, читать отчёты.
  5. Ужесточить политику до quarantine/reject.

Источники и ссылки


Комментарии загружаются…