SPF (Sender Policy Framework) описывает, каким серверам разрешено отправлять письма с доменом в SMTP-конверте. DMARC (Domain-based Message Authentication, Reporting, and Conformance) проверяет, согласуется ли домен, прошедший SPF или DKIM, с доменом в видимом адресе From. Он также задает политику для писем, которые не прошли эту проверку. MX решает отдельную задачу: указывает, куда направлять входящую почту домена.
Когда проверяете домен клиента через Domain Intelligence, начните с нужного вам ответа. MX описывает входящий маршрут, SPF и DMARC относятся к настройкам отправки. Для вопроса о конкретном ящике нужны свидетельства проверки email-адреса.
Чем отличаются SPF, DMARC и MX
| Запись | Основной вопрос | Чего не доказывает сама публикация |
|---|---|---|
| MX | Куда направлять письма, адресованные этому домену? | Что конкретный ящик существует или сервер примет письмо |
| SPF | Разрешено ли отправляющему серверу использовать доменный идентификатор SMTP? | Что домен видимого From прошел аутентификацию |
| DMARC | Согласуется ли домен, прошедший SPF или DKIM, с доменом видимого From? |
Что конкретное письмо прошло аутентификацию или попало во входящие |
SPF использует SMTP-идентификатор MAIL FROM и может также проверять HELO. DMARC ориентируется на домен видимого From. Эти роли описаны в обзоре работы SPF и модели проверки DMARC.
При выборе входящего маршрута SMTP ищет MX-записи. Подробности есть в правилах маршрутизации SMTP и словарной статье о MX.
Как прочитать записи одного домена
Ниже показана вымышленная DNS-конфигурация. Все имена используют зарезервированную зону .example. Это учебный пример, а не готовая настройка для рабочего домена.
atelier.example. IN MX 10 inbound.gateway.example.
atelier.example. IN TXT "v=spf1 include:_spf.sender.example -all"
_dmarc.atelier.example. IN TXT "v=DMARC1; p=reject; aspf=s; adkim=s"
MX указывает входящий сервер. Им может быть фильтрующий шлюз, за которым работает другой сервис почтовых ящиков. Сервис отправки из SPF тоже может отличаться от сервиса приема. Эти ограничения разобраны в статье о том, как определить почтового провайдера по MX-записям.
Механизм SPF include требует обратиться к SPF-политике другого домена. Завершающий -all дает результат SPF fail, если проверка дошла до него и ни один предыдущий механизм не совпал. Чтобы оценить реальную SMTP-транзакцию, нужны IP отправляющего сервера, SMTP-идентификатор и политика, на которую ссылается запись. Сама запись дает исходные данные, но не результат проверки письма. Эти механизмы определены в RFC 7208.
Запись DMARC публикует p=reject и выбирает строгий режим согласования через aspf=s и adkim=s. В строгом режиме домены должны совпадать полностью. В нестрогом режиме достаточно общего организационного домена. Политика относится к письмам с atelier.example в видимом From, а не к письмам, адресованным этому домену. DMARC отдельно определяет согласование и политику.
Другие значения политики: none, которое не задает предпочтений по обработке писем, не прошедших DMARC, и quarantine, которое считает такие письма подозрительными. Принимающий сервис дополнительно применяет собственные правила. Опубликованное значение не гарантирует доставку. Значения политики DMARC.
Почему письмо может пройти SPF и не пройти DMARC
Предположим, сервис отправки передает письмо с такими идентификаторами:
Visible From: hello@atelier.example
SMTP MAIL FROM: bounce@sender.example
SPF result for sender.example: pass
DKIM: no passing aligned signature
Это вымышленный пример письма, а не ответ Domain Intelligence. Считаем, что принимающий сервер уже установил успешный результат SPF для sender.example. Этот домен отличается от atelier.example, поэтому результат SPF не выполняет условие согласования DMARC. Если нет корректной DKIM-подписи с согласованным доменом, письмо не проходит DMARC. Руководство Google объясняет это требование к SPF.
Добавление сервиса в список SPF include домена atelier.example не меняет MAIL FROM конкретного письма. Проверьте, какой домен сервис фактически использует в SMTP-конверте.
DKIM (DomainKeys Identified Mail) подтверждает домен подписанта через подпись письма. Если у этого письма есть корректная DKIM-подпись с доменом atelier.example в поле d=, такой результат может обеспечить прохождение DMARC даже при несогласованном SPF-идентификаторе. Для DMARC достаточно успешной проверки SPF или DKIM с согласованным доменом. Подробности есть в спецификации DKIM и объяснении согласования DMARC от Google.
Что устанавливает Domain Intelligence
Domain Intelligence в Emvero читает почтовый маршрут и MX-записи, определяет видимого провайдера входящей почты, когда может его распознать, и возвращает поддерживаемые поля опубликованных записей SPF и DMARC. Проверка не открывает SMTP-сессию и не аутентифицирует письмо.
| Поле профиля | Как его читать |
|---|---|
mail_routing.status |
routable означает, что DNS задает почтовый маршрут; прием письма для конкретного получателя не проверялся |
SPF present и syntax |
Найдена ли запись и удалось ли проверить синтаксис ее публикации |
SPF includes, redirect, all_qualifier |
Извлеченные части записи; проверка не выполняет рекурсивную оценку SPF-политик по ссылкам |
DMARC policy_domain и inherited |
Где найдена политика и была ли она унаследована |
DMARC published_policy и effective_policy |
Опубликованная и действующая политика после поддерживаемых правил поиска и применения политики; ни одно поле не является вердиктом для письма |
SPF/DMARC evaluation |
not_performed: проверка аутентификации отправителя или письма не выполнялась |
В профиле partial почтовый маршрут может быть известен, даже если другое наблюдение недоступно. Прочитайте метаданные нужного поля, включая observed_at, expires_at и stale. Устаревшее наблюдение описывает прежний результат, а значение unknown оставляет вопрос открытым. Ни одно из этих состояний не дает оснований считать результат отрицательным в вашем приложении.
Документация ответа Domain Intelligence описывает эти поля. Профиль не включает проверку DKIM, мониторинг DMARC, оценку репутации отправителя или тест попадания во входящие.
Как выбрать проверку под свою задачу
Чтобы узнать, есть ли у домена маршрут входящей почты, начните с маршрутизации. Отсутствие SPF или DMARC не доказывает, что домен не может получать письма. Политика p=reject тоже не закрывает его ящики.
Если MX отсутствует, прочитайте разбор домена без MX-записи: в этом случае SMTP может использовать неявную маршрутизацию. Запись null MX прямо объявляет, что домен не принимает почту.
Если вопрос касается конкретного email-адреса, выберите подходящую полную проверку или проверку домена. Свидетельства на уровне домена не доходят до ящика. Полная проверка может получить свидетельства приема для конкретного получателя, если сервер назначения это позволяет.
При проблеме с аутентификацией отправки разберите реальное письмо в принимающей системе, которую вы контролируете. Сравните домен SMTP-конверта, видимый From, домен DKIM-подписи и результаты аутентификации. Сама публикация DNS-записей таких результатов не дает.
Чтобы посмотреть настройки домена, откройте Domain Intelligence в аккаунте Emvero. Сначала прочитайте маршрут, затем наблюдения SPF и DMARC со статусом и сроком актуальности каждого поля.