Эта программа запускается на сервере
Как это работает
Почтовый протокол не проверяет отправителя: любой сервер может указать ваш домен в поле отправителя. Эту дверь закрывают три DNS-записи. SPF перечисляет серверы, которым разрешено отправлять почту от имени домена. DKIM подписывает каждое письмо закрытым ключом, открытая часть которого опубликована в DNS. DMARC связывает их: требует, чтобы хотя бы одна проверка прошла и совпала с видимым доменом отправителя, сообщает получателю, что делать с отказами, и запрашивает отчёты обо всём, что отправлено от вашего имени.
С февраля 2024 года Gmail и Yahoo требуют SPF, DKIM и DMARC от всех, кто отправляет их пользователям больше 5000 писем в день, и отсутствие любого из них оборачивается отклонёнными письмами или папкой «Спам». Поэтому проверять все три стоит вместе: безупречный SPF мало что даёт без DMARC, а DMARC в режиме reject при плохо опубликованном DKIM блокирует вашу же почту.
Проверка выполняется с нашего сервера через публичные DNS-запросы — так же, как это сделал бы любой почтовый сервер. SPF вычисляется полностью: мы проходим каждый include и redirect, чтобы подсчитать DNS-запросы, ведь превышение лимита в 10 делает недействительной всю запись. Также запрашиваются записи MX и необязательные MTA-STS, TLS-RPT и BIMI.
Примеры
github.comSPF · 10 / 10Восемь include провайдеров (Microsoft, Google, Zendesk, Salesforce, Mailchimp, SendGrid…) вместе с их собственными include доводят проверку ровно до лимита в 10 DNS-запросов. Ещё один провайдер — и весь SPF начнёт давать постоянную ошибку.example.comMX 0 . · v=spf1 -all · v=DMARC1;p=reject;sp=reject;adkim=s;aspf=sПравильная настройка для домена, который не отправляет и не принимает почту: нулевой MX, SPF, никого не авторизующий, и DMARC в режиме reject. Это защищает припаркованные домены — частую мишень для подделки.v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.comquarantine · 25 %Постепенное внедрение: в спам уходит лишь каждое четвёртое не прошедшее проверку письмо, а отчёты приходят в ящик из rua, чтобы выявить легитимных отправителей, ещё не прошедших аутентификацию.Сценарии использования
- Выяснить, почему письма домена попадают в спам или отклоняются Gmail, Outlook или Yahoo.
- Убедиться, что SPF не превышает 10 DNS-запросов, прежде чем добавить нового провайдера рассылок, например CRM или платформу рассылок.
- Проверить, правильно ли опубликован ключ DKIM провайдера после настройки.
- Спланировать переход DMARC с none на quarantine и reject, не отрезав легитимную почту.
- Проверить домены клиента или приобретённой компании, включая припаркованные, которые не должны отправлять почту.
- Изучить настройки подозрительного отправителя при разборе фишинговой атаки.
Часто задаваемые вопросы
Почему пишет, что DKIM не найден, если мой домен подписывает письма?
Потому что DKIM не позволяет перечислить ключи домена: каждый находится по адресу <селектор>._domainkey.<домен>, и чтобы его запросить, нужно знать селектор. Инструмент перебирает самые распространённые селекторы, но многие провайдеры используют собственные имена или имена с датой. Откройте письмо, отправленное с домена, найдите заголовок DKIM-Signature и скопируйте значение s= — с этим селектором проверка будет точной.
Что будет, если SPF превысит 10 DNS-запросов?
RFC 7208 обязывает получателя вернуть постоянную ошибку (permerror), а для DMARC это равносильно провалу SPF. Запросы расходуют механизмы include, a, mx, ptr и exists и модификатор redirect, в том числе внутри каждого include; ip4 и ip6 их не тратят. Чтобы снизить число, удалите неиспользуемых провайдеров, замените include диапазонами ip4 или отправляйте почту с поддоменов со своим SPF.
~all или -all?
При включённом DMARC разница невелика: получатель применяет политику DMARC, а не квалификатор SPF. ~all встречается чаще, потому что некоторые получатели при -all отклоняют письмо сразу, не проверив DKIM, и так можно потерять пересланную почту, которую спас бы DKIM. Без DMARC -all — единственный способ попросить отклонять неавторизованную почту.
Как перевести DMARC с none на reject, не потеряв почту?
Начните с p=none и адреса в rua и несколько недель читайте сводные отчёты: они показывают каждый сервер, отправляющий почту от вашего домена, и проходит ли он SPF или DKIM. Настройте аутентификацию недостающих легитимных отправителей, перейдите на quarantine с низким pct, постепенно повышайте pct и закончите на reject. Прямой переход на reject обычно отрезает биллинговые системы, CRM или внутренние сервисы, о которых никто не вспомнил.
Достаточно ли ключа DKIM на 1024 бита?
Работает, потому что RFC 8301 обязывает получателей принимать ключи от 1024 до 4096 бит, но тот же стандарт рекомендует подписывающим использовать не менее 2048. Ключи короче 1024 бит не считаются действительными. Перейти на 2048 просто: опубликуйте новый ключ под другим селектором, переключите подпись, а затем отзовите старый, оставив p пустым.
Зачем нужны MTA-STS, TLS-RPT и BIMI?
MTA-STS (RFC 8461) требует от отправляющих серверов использовать TLS при доставке на ваши MX, что защищает от атак с понижением соединения до открытого текста. TLS-RPT (RFC 8460) присылает отчёты, когда такие доставки не удаются. BIMI показывает логотип бренда рядом с отправителем в поддерживающих его клиентах и работает только при DMARC в режиме quarantine или reject. Ни один из них не обязателен, но все три полезны.