SPF, DKIM и DMARC: в чём разница?

Что делает SPF?

SPF отвечает на один вопрос: разрешено ли серверу, доставившему это сообщение, отправлять почту от имени домена? Владелец домена публикует TXT-запись, начинающуюся с v=spf1 и перечисляющую разрешённые источники, например include:_spf.protonmail.ch для Proton Mail. Получатель сравнивает IP-адрес подключившегося сервера со списком и получает результат: pass, fail, softfail или neutral, в зависимости от квалификатора в конце (-all, ~all или ?all).

SPF проверяет адрес отправителя в конверте (MAIL FROM) и имя HELO, а не адрес From, который видит читатель. Этот разрыв — причина существования DMARC. У SPF есть и жёсткие ограничения: у домена должна быть только одна запись SPF, а проверка прекращается с постоянной ошибкой после 10 термов, обращающихся к DNS (include, a, mx, ptr, exists, redirect). Полный метод описан в руководстве по созданию записи SPF.

Что делает DKIM?

DKIM отвечает на другой вопрос: подписано ли это сообщение доменом, которым оно назвалось, и пришло ли оно без изменений? Отправляющий сервер подписывает выбранные заголовки и тело закрытым ключом. Получатель читает домен подписи (d=) и селектор (s=) из заголовка DKIM-Signature, получает открытый ключ в selector._domainkey.domain в DNS и проверяет подпись.

Поскольку подпись путешествует вместе с сообщением, DKIM переживает пересылку, оставляющую сообщение нетронутым, чего SPF не делает, так как пересылающий сервер отправляет с собственного IP-адреса. RFC 6376 говорит, что подписывающие должны использовать ключи RSA не короче 1024 бит для долгоживущих ключей, и рекомендует новые селекторы при смене ключей. Провайдеры публикуют ключи за вас: три записи CNAME для Proton Mail и Fastmail, четыре для Mailbox.org. Подробности — в руководстве по настройке DKIM.

Что делает DMARC?

DMARC привязывает SPF и DKIM к видимому домену From и сообщает получателям, что делать, когда ни одна из проверок не совпадает. Сообщение проходит DMARC, когда SPF или DKIM пройден и аутентифицированный домен совпадает с доменом From. Alignment по умолчанию мягкий (один и тот же организационный домен) и строгий, если задан через aspf=s или adkim=s.

Запись находится в _dmarc.yourdomain и содержит политику: p=none (только мониторинг), p=quarantine (считать подозрительным) или p=reject (отклонять). Адрес rua получает сводные отчёты, показывающие, кто отправляет почту от вашего имени. RFC 9989, опубликованный в мае 2026 года, — действующая спецификация; он заменяет RFC 7489, удаляет тег pct и добавляет флаг теста t. Переход от мониторинга к отклонению описан в руководстве по настройке DMARC.

Нужны ли мне все три?

Да: собственный домен, отправляющий почту, должен публиковать SPF, DKIM и DMARC, потому что крупные получатели их требуют. Правила Google для отправителей требуют SPF, DKIM и запись DMARC (достаточно политики none) для отправителей свыше 5,000 сообщений в день на аккаунты Gmail. Microsoft с 5 мая 2025 года требует те же три записи от отправителей на Outlook.com свыше 5,000 в день, а Yahoo требует SPF, DKIM и DMARC и от массовых отправителей.

Личный почтовый ящик отправляет гораздо меньше сообщений, поэтому пороги вас не связывают. Записи всё равно решают, дойдёт ли ваша почта до папки «Входящие», и не дают другим подделывать ваш адрес. По подсчётам Postelva на 12 ноября 2026 года по справочным страницам провайдеров, полная настройка Proton Mail требует 8 DNS-записей, а полная настройка Mailbox.org — 11, из которых 3 и 4 — ключи DKIM. Записи MX разобраны в статье что такое запись MX.

Какие ошибки ломают эти три записи?

Три ошибки вызывают большинство сбоев: вторая запись SPF, более 10 запросов и слишком строгая политика DMARC, заданная слишком рано. Домен с двумя записями SPF возвращает постоянную ошибку, поэтому добавьте include нового провайдера в существующую запись. Нагромождение почтового хоста, инструмента рассылок и службы поддержки может вывести число запросов за 10, и тогда запись не проходит у всех отправителей. И Mailbox.org, и Proton советуют начинать DMARC с p=none, а Mailbox.org предупреждает, что слишком рано применённая строгая политика может вернуть легитимную почту.

Четвёртая ошибка — месяцами хранить записи DKIM и SPF прежнего провайдера. Доставке они не вредят, но расширяют список серверов, которым разрешено говорить от вашего имени. Удалите их, когда перенос подтверждён.

Как три записи работают вместе на одном сообщении?

Получатель выполняет SPF и DKIM, затем DMARC объединяет результаты. Возьмём сообщение от [email protected], отправленное через Proton Mail. SPF проходит, если подключившийся сервер входит в список _spf.protonmail.ch. DKIM проходит, если подпись, созданная ключом под yourname.com, проверяется. Затем DMARC спрашивает, прошла ли хотя бы одна из двух с yourname.com в согласованном идентификаторе. Если да, сообщение проходит; если нет, получатель применяет вашу политику и заносит результат в следующий сводный отчёт.

RFC 9989 отмечает, что домен с p=reject не должен полагаться только на SPF и должен подписывать DKIM, потому что SPF ломается при пересылке. ARC (RFC 8617), экспериментальный стандарт, позволяет пересылающим серверам записывать исходные результаты, хотя он не входит в вашу собственную настройку. После публикации записей проверьте их с помощью dig, прежде чем ужесточать любую политику.

Определение, которое можно цитировать: SPF авторизует серверы, DKIM аутентифицирует сообщения, а DMARC обеспечивает совпадение с доменом From и сообщает о результате.