Все статьи

SPF, DKIM и DMARC: как сделать, чтобы деловые письма доходили до адресата

Опубликовано · 9 мин чтения

Прослушать статью · читает голос ИИ

Допустим, вы отправляете клиенту счёт с адреса info@your-company.ge, а письмо не приходит. Через неделю клиент пишет, что нашёл его в папке «Спам». Или письмо вообще не дошло, и вы об этом не узнали. Частая причина в том, что принимающий сервер не смог проверить, что письмо действительно отправлено от имени вашего домена.

Три DNS-записи, SPF, DKIM и DMARC, как раз и нужны для такого подтверждения. В статье разбираем, что делает каждая из них, чего требуют Google и Yahoo и как внедрять защиту постепенно, чтобы не потерять собственную почту. Примеры записей взяты из DNS домена esn.ge.

Почему письма попадают в спам: отправитель без подтверждения

Адрес отправителя в письме можно указать любой. Это похоже на бумажное письмо: на конверте написано «Банк», но печати нет. Получатель не знает, настоящий ли это банк. Сервер, принимающий почту, находится в такой же ситуации. Письмо подписано «info@your-company.ge», но кто его на самом деле отправил, сервер не знает.

Поэтому принимающий сервер доверяет письму только тогда, когда отправляющий домен это подтверждает:

  • SPF называет серверы, которым разрешено отправлять почту от имени домена;
  • DKIM подписывает каждое письмо;
  • DMARC сообщает получателям, что делать с письмами, не прошедшими проверку, и присылает владельцу домена отчёты.

Если этих записей нет, вашим счетам и коммерческим предложениям грозит папка «Спам» или отказ в приёме. Google и Yahoo с февраля 2024 года прямо требуют такие настройки от отправителей.

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

SPF — это TXT-запись домена, которая начинается с v=spf1. В ней перечислено, откуда разрешена отправка. Получив письмо, сервер сверяет, с разрешённого ли сервера оно пришло (RFC 7208).

Запись esn.ge выглядит так:

v=spf1 mx include:_spf.webhosting.systems include:_spf.protonmail.ch -all

Разберём её по частям:

  • v=spf1 — начало записи, версия SPF;
  • mx — разрешены серверы, указанные в MX-записях домена, то есть те, что принимают его почту;
  • include: — добавляет разрешённые серверы другого домена. В записи два таких элемента: _spf.webhosting.systems и _spf.protonmail.ch;
  • -all — все остальные серверы проверку не проходят.

У SPF есть ограничение: при проверке политики допускается не более 10 элементов, требующих запроса к DNS. Сам запрос записи SPF в этот лимит не входит (Mailhardener со ссылкой на RFC 7208, раздел 4.6.4). Считается вся проверка целиком, а не только ваша строка. Каждый include: и mx требует обращения к DNS, поэтому с каждым подключённым сервисом рассылок запас уменьшается. Добавляйте в запись только тех отправителей, которыми вы действительно пользуетесь.

DKIM: подпись каждого письма

SPF проверяет сервер, DKIM проверяет само письмо. Отправляющий сервер подписывает каждое письмо закрытым ключом и добавляет подпись в заголовок DKIM-Signature. В нём указаны домен (d=) и селектор (s=). Селектор позволяет домену иметь несколько ключей одновременно (RFC 6376).

Получатель берёт по домену и селектору открытый ключ из TXT-записи по адресу <селектор>._domainkey.<домен> и проверяет подпись. Если письмо по дороге изменили, подпись перестаёт совпадать. Закрытый ключ остаётся на вашем сервере, а открытый публикуется в DNS.

Вот форма такой записи. Это пример с условными значениями для домена your-company.ge, а не реальный ключ:

mail._domainkey.your-company.ge   TXT   "v=DKIM1; k=rsa; p=<открытый ключ>"

Вместо <открытый ключ> подставляется ключ, который выдаёт ваш почтовый сервер или провайдер. Имя селектора (здесь mail) тоже зависит от настройки.

Учтите требование Google: для отправки на личные адреса Gmail нужен ключ DKIM длиной 1024 бита или больше.

DMARC: что происходит с письмами без подтверждения, и отчёты

SPF и DKIM сами по себе не говорят получателю, как поступать с письмом, не прошедшим проверку. Это задаёт DMARC. Его запись — TXT-запись по адресу _dmarc.<домен>.

Важное понятие здесь — соответствие (alignment). Письмо проходит DMARC, если проходит проверку SPF или DKIM и домен этой проверки соответствует домену в адресе отправителя From:, который видит получатель (RFC 9989). Так DMARC закрывает лазейку: подтверждённым оказывается именно тот адрес, который читает человек.

Политика p= имеет три значения:

  • p=none — только собирать отчёты, письма не затрагиваются;
  • p=quarantine — получателям предлагается считать такие письма подозрительными, например отправить в папку «Спам»;
  • p=reject — получателям предлагается отклонять такие письма.

Два вида отчётов настраиваются тегами: rua указывает, куда отправлять сводные (агрегированные) отчёты, ruf — куда отправлять отчёты о сбоях. По ним владелец домена видит, кто ещё отправляет почту от его имени.

В мае 2026 года вышла новая спецификация DMARC, в сообществе её называют DMARCbis. Она опубликована как три RFC: RFC 9989 (основной протокол), RFC 9990 (сводные отчёты) и RFC 9991 (отчёты о сбоях) (RFC 9989, PowerDMARC). RFC 9989 опубликован 19 мая 2026 года и заменяет RFC 7489 от 2015 года и экспериментальный RFC 9091 (SMTPedia). Теперь DMARC имеет статус предлагаемого стандарта (Proposed Standard) IETF, а раньше имел информационный статус (PowerDMARC). Записи по-прежнему начинаются с v=DMARC1, так что для большинства рабочих систем срочных действий не требуется (DMARCTrust).

Что Google и Yahoo требуют от отправителей

Google разделяет требования на два уровня. С 1 февраля 2024 года все, кто отправляет почту на адреса Gmail, обязаны выполнять первый набор. Те, кто отправляет на Gmail больше 5000 писем в сутки, должны выполнять и второй, более строгий.

Требование Все отправители Более 5000 писем в сутки
Аутентификация домена SPF или DKIM SPF и DKIM
DMARC в списке не назван нужен, политика может быть none
Соответствие домена в From: в списке не названо домену SPF или домену DKIM
Доля жалоб на спам в Postmaster Tools ниже 0,3% действует и этот пункт, он относится ко всем
Отписка в один клик в списке не названа нужна для рассылок и подписных писем

Ещё два пояснения от Google. В разделе о мониторинге советуют держать долю жалоб ниже 0,10% и никогда не доходить до 0,30% и выше. Отписка в один клик работает через заголовки List-Unsubscribe-Post: List-Unsubscribe=One-Click и List-Unsubscribe (RFC 2369, RFC 8058); кроме того, в тексте письма должна быть хорошо заметная ссылка для отписки.

Yahoo начала применять свои требования в феврале 2024 года. Вводились они постепенно: компания наблюдала за соблюдением в течение первой половины года. Минимум для отправителя — реализовать SPF или DKIM.

Для небольшой компании вывод простой. Даже если вы отправляете далеко не 5000 писем в сутки, SPF или DKIM обязательны, а лучше настроить оба. DMARC в первом списке Google не назван, но именно он даёт вам отчёты и контроль над тем, что происходит с письмами. Поэтому мы советуем настраивать все три записи.

Вводим постепенно: от p=none через p=quarantine к p=reject

Строгая политика DMARC без подготовки опасна. Если вы забыли какой-то сервис, который отправляет почту от вашего имени (например, систему выставления счетов), его письма начнут отклоняться. Поэтому политику ужесточают поэтапно:

  1. p=none. Письма не затрагиваются, вы только получаете отчёты. По ним видно, кто отправляет почту от имени домена и что проходит проверку.
  2. p=quarantine. Когда все законные отправители подтверждены, письма с провалом проверки считаются подозрительными.
  3. p=reject. Письма без подтверждения отклоняются.

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

Запись DMARC домена esn.ge сейчас использует p=quarantine:

v=DMARC1;p=quarantine;sp=quarantine;pct=100;rua=mailto:dmarc@reports.epicsoft.email;ruf=mailto:dmarc@reports.epicsoft.email;ri=86400;aspf=r;adkim=r;fo=1;rf=afrf;

Теги разделены точкой с запятой, без пробелов. Что означает каждый:

  • v=DMARC1 — версия протокола;
  • p=quarantine — политика для домена;
  • sp=quarantine — та же политика для поддоменов;
  • pct=100 — политика применяется ко всем письмам; тег убран в RFC 9989;
  • rua=mailto:… — адрес для сводных отчётов;
  • ruf=mailto:… — адрес для отчётов о сбоях;
  • ri=86400 — интервал отчётов; тег убран в RFC 9989;
  • aspf=r и adkim=r — мягкое (relaxed) соответствие для SPF и DKIM;
  • fo=1 — отчёт о сбое запрашивается при провале любой из проверок;
  • rf=afrf — формат отчётов; тег убран в RFC 9989.

Что изменилось в RFC 9989:

  • убраны теги pct, rf и ri. Вместо pct появился тег t (тестовый режим), у которого только два состояния: «всё» (100%) или «ничего» (0%) (dmarcian). Эти три тега в нашей записи остались от прежней спецификации. В новых записях использовать их не нужно;
  • добавлен тег np — политика для несуществующих поддоменов. Если он не указан, действует политика sp (RFC 9989);
  • добавлен тег psd для доменов общедоступных суффиксов;
  • организационный домен определяется обходом дерева DNS (DNS Tree Walk), а не списком Public Suffix List (DMARCTrust).

Уже работающие записи продолжают действовать.

Дополнительно: MTA-STS для шифрования при передаче

SPF, DKIM и DMARC подтверждают отправителя. Они не гарантируют, что письмо по пути к вам зашифровано. Для этого есть MTA-STS: домен объявляет, что почту для него нужно доставлять только по TLS с действительным сертификатом (RFC 8461).

Устроено это из двух частей. Первая — TXT-запись по адресу _mta-sts.<домен> со значениями v=STSv1 и id, который меняется при каждом изменении политики. Вторая — сама политика: файл /.well-known/mta-sts.txt, доступный по HTTPS на поддомене mta-sts вашего домена, с режимом enforce, testing или none.

У домена esn.ge запись _mta-sts.esn.ge является CNAME на _mta-sts.epicsoft.email. Там находится TXT-запись:

v=STSv1;id=20261012084000

То есть esn.ge берёт запись MTA-STS у почтового домена epicsoft.email.

Как это настраивает epicsoft

В почтовой услуге epicsoft networks при подключении создаются почтовые ящики и DNS-записи вашего домена: MX, SPF, DKIM и DMARC. Записи можно настроить у вашего DNS-провайдера вместе с вами, либо DNS домена ведёт epicsoft. Почта хранится на собственных почтовых серверах в Финляндии и Германии. Письма веб-приложений в контейнерах можно направлять через наш образ smarthost (Postfix на Alpine, открытый исходный код): он передаёт почту на почтовый сервер, который покрывают записи SPF, DKIM и DMARC. Подробности: почта под вашим доменом, остальные услуги — в обзоре.

Источники

Другие статьи

Готовы к следующему шагу?

Лучшего момента, чтобы начать, ещё не было. Расскажите нам о своём проекте.

Связаться с нами