Проверка SPF, DKIM и DMARC

Что делают три записи, по абзацу на каждую

SPF — это список серверов, которым разрешено отправлять почту от имени вашего домена; его публикуют в DNS. Сервер-получатель берёт домен из адреса отправителя в конверте (envelope sender), загружает список и проверяет, есть ли в нём IP-адрес, с которого пришло соединение. Это TXT-запись, которая начинается с v=spf1 и заканчивается вердиктом для всех, кого нет в списке: -all означает отклонить, ~all — мягкий отказ (soft fail).

DKIM добавляет криптографическую подпись в заголовок каждого письма. В подписи указан селектор, и получатель берёт соответствующий открытый ключ из TXT-записи по адресу selector._domainkey.вашдомен. Если ключ подтверждает подпись, письмо подписала сторона, у которой есть закрытый ключ, и по дороге его не меняли. Селектор выбирает тот, кто подписывает, поэтому проверка не всегда может его угадать.

DMARC связывает эти два механизма. Он определяет, какой из SPF и DKIM должен пройти и совпасть (align) с видимым доменом в From, и что делать получателям с письмами, которые не прошли: ничего (p=none), отправить в спам (p=quarantine) или отклонить (p=reject). Кроме того, он просит получателей присылать вам отчёты, а это единственный способ узнать, кто ещё пишет от имени вашего домена.

Ошибки, которые ищет эта страница

Большинство сбоев мелкие, и находят их, читая записи, а не отправляя тестовые письма.

• Две SPF-записи. Классическая случайность: вы подключили новый почтовый сервис и добавили ещё одну TXT-запись. Домен может публиковать ровно одну; если их две, SPF возвращает постоянную ошибку для каждого письма.
• Больше десяти DNS-запросов. Считается каждый include, a, mx, ptr, exists и redirect, а также каждый такой элемент внутри подключённой записи. После десяти проверка не проходит. Платформы рассылок, CRM и службы поддержки приносят свои include, так что лимит исчерпывается незаметно. Проверка проходит по include, чтобы оценить число.
• +all или отсутствие all. Запись, заканчивающаяся на +all, разрешает отправку всему интернету. Запись без завершающего вердикта ничего не говорит о посторонних.
• DMARC застрял на p=none. С него стоит начинать, но оставаться там не стоит: пока он там, ничего не блокируется. Читайте агрегированные отчёты, исправляйте отправителей, которые не проходят, и переходите на quarantine, а затем на reject.
• DKIM-ключ на 1024 бита. Он ещё проходит проверку, но считается слабым. Перейдите на 2048 бит, опубликовав новый селектор до переключения подписи.
• DMARC-запись без адреса rua. Тогда вы применяете политику вслепую.

Почему DKIM иногда «не найден»

Ключ DKIM лежит по имени, в котором есть селектор, а DNS не умеет показывать все имена под доменом. Эта страница пробует селекторы, которые по умолчанию используют распространённые провайдеры (google; selector1 и selector2 для Microsoft 365; s1, s2, k1, default и ещё несколько). Если ваш отправитель использует другой, откройте любое письмо, полученное от этого домена, найдите заголовок DKIM-Signature и скопируйте значение после s=. Вставьте его в поле селектора и запустите проверку снова.

Некоторые провайдеры публикуют ключ как CNAME на собственную запись. Это нормально и работает так же; страница читает итоговый TXT-ответ.

От разовой проверки к оповещению

Записи аутентификации меняются по обыденным причинам: новый инструмент для рассылок, перенесённый почтовый ящик, смена DNS-провайдера, после которой пропадает запись. Меняются они и из-за ошибок. DNS-монитор в Tenium может следить за TXT-записями SPF и DMARC и оповещать, когда значение перестаёт совпадать с ожидаемым, а в сообщении будут старый и новый текст (см. мониторинг DNS). Он начинается с тарифа Starter. Для более подробного просмотра записей есть страницы SPF-запрос, DMARC-запрос и DKIM-запрос: они показывают сырые ответы.

Этот инструмент читает публичный DNS из вашего браузера. Он не отправляет тестовых писем, не видит репутацию вашей рассылки и ничего не говорит о том, доставлено ли конкретное письмо. Для этого нужны заголовки письма и журналы провайдера.