---
title: "SPF и DMARC: как читать почтовые DNS-записи | Emvero"
description: "Чем отличаются SPF и DMARC, почему письмо может пройти SPF и не пройти DMARC и как читать MX и записи аутентификации в профиле Domain Intelligence."
url: https://emvero.io/ru/blog/spf-vs-dmarc/
language: ru
updated: 2026-10-07
---

Блог

# SPF и DMARC: что можно узнать из DNS-записей домена

SPF разрешает серверам отправлять почту. DMARC проверяет совпадение доменов с видимым From. Разбираем эти записи вместе с MX и объясняем границы DNS-проверки.

Опубликовано 2026-09-27

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](https://www.rfc-editor.org/rfc/rfc7208.html#section-2) и [модели проверки DMARC](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.1).

При выборе входящего маршрута SMTP ищет MX-записи. Подробности есть в [правилах маршрутизации SMTP](https://www.rfc-editor.org/rfc/rfc5321.html#section-5.1) и [словарной статье о MX](https://emvero.io/ru/glossary/mx-record/).

## Как прочитать записи одного домена

Ниже показана вымышленная 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-записям](https://emvero.io/ru/blog/how-to-find-email-provider/).

Механизм SPF `include` требует обратиться к SPF-политике другого домена. Завершающий `-all` дает результат SPF fail, если проверка дошла до него и ни один предыдущий механизм не совпал. Чтобы оценить реальную SMTP-транзакцию, нужны IP отправляющего сервера, SMTP-идентификатор и политика, на которую ссылается запись. Сама запись дает исходные данные, но не результат проверки письма. [Эти механизмы определены в RFC 7208](https://www.rfc-editor.org/rfc/rfc7208.html#section-5).

Запись DMARC публикует `p=reject` и выбирает строгий режим согласования через `aspf=s` и `adkim=s`. В строгом режиме домены должны совпадать полностью. В нестрогом режиме достаточно общего организационного домена. Политика относится к письмам с `atelier.example` в видимом `From`, а не к письмам, адресованным этому домену. [DMARC отдельно определяет согласование и политику](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.4).

Другие значения политики: `none`, которое не задает предпочтений по обработке писем, не прошедших DMARC, и `quarantine`, которое считает такие письма подозрительными. Принимающий сервис дополнительно применяет собственные правила. Опубликованное значение не гарантирует доставку. [Значения политики DMARC](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.7).

## Почему письмо может пройти 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](https://knowledge.workspace.google.com/admin/security/set-up-dmarc).

Добавление сервиса в список SPF `include` домена `atelier.example` не меняет `MAIL FROM` конкретного письма. Проверьте, какой домен сервис фактически использует в SMTP-конверте.

DKIM (DomainKeys Identified Mail) подтверждает домен подписанта через подпись письма. Если у этого письма есть корректная DKIM-подпись с доменом `atelier.example` в поле `d=`, такой результат может обеспечить прохождение DMARC даже при несогласованном SPF-идентификаторе. Для DMARC достаточно успешной проверки SPF или DKIM с согласованным доменом. Подробности есть в [спецификации DKIM](https://www.rfc-editor.org/rfc/rfc6376.html#section-3.5) и [объяснении согласования DMARC от Google](https://knowledge.workspace.google.com/admin/security/set-up-dmarc).

## Что устанавливает 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](https://docs.emvero.io/using/domain-intelligence/) описывает эти поля. Профиль не включает проверку DKIM, мониторинг DMARC, оценку репутации отправителя или тест попадания во входящие.

## Как выбрать проверку под свою задачу

Чтобы узнать, есть ли у домена маршрут входящей почты, начните с маршрутизации. Отсутствие SPF или DMARC не доказывает, что домен не может получать письма. Политика `p=reject` тоже не закрывает его ящики.

Если MX отсутствует, прочитайте разбор [домена без MX-записи](https://emvero.io/ru/blog/domain-without-mx-record/): в этом случае SMTP может использовать неявную маршрутизацию. [Запись null MX](https://www.rfc-editor.org/rfc/rfc7505.html#section-3) прямо объявляет, что домен не принимает почту.

Если вопрос касается конкретного email-адреса, выберите подходящую [полную проверку или проверку домена](https://emvero.io/ru/compare/full-check-vs-domain-check/). Свидетельства на уровне домена не доходят до ящика. Полная проверка может получить свидетельства приема для конкретного получателя, если сервер назначения это позволяет.

При проблеме с аутентификацией отправки разберите реальное письмо в принимающей системе, которую вы контролируете. Сравните домен SMTP-конверта, видимый `From`, домен DKIM-подписи и результаты аутентификации. Сама публикация DNS-записей таких результатов не дает.

Чтобы посмотреть настройки домена, откройте [Domain Intelligence](https://emvero.io/ru/domain-intelligence/) в аккаунте Emvero. Сначала прочитайте маршрут, затем наблюдения SPF и DMARC со статусом и сроком актуальности каждого поля.

## Термины, которые здесь встречаются

### MX-запись

DNS-запись с именем сервера для входящей почты домена и его приоритетом. Она не подтверждает существование ящика.

### Сбой DNS

DNS-запрос не дал нужных сведений о домене или почтовом маршруте. Отсутствующее имя и временный сбой требуют разных решений.

[Все статьи](https://emvero.io/ru/blog/)

## Выберите, что проверить дальше.

Запустите проверку в личном кабинете и посмотрите данные в результате.

Начать бесплатно