При отправке email почтовой системе получателя недостаточно увидеть адрес:

news@company.ru

Ей нужно понять, действительно ли письмо связано с доменом company.ru и имеет ли отправляющая инфраструктура право использовать этот домен.

Для этого в современной электронной почте применяются три основных механизма:

SPF, DKIM и DMARC.

Они выполняют разные функции, но работают совместно.

Если сильно упростить:

• SPF проверяет, каким серверам разрешено отправлять почту для домена;
• DKIM подтверждает письмо с помощью электронной подписи;
• DMARC связывает эти проверки с доменом в поле «От кого» и определяет политику обработки проблемных сообщений.

Разберём каждый механизм отдельно и посмотрим, почему они особенно важны для компаний, которые отправляют email-рассылки или транзакционные письма.

Зачем вообще проверять отправителя email

Адрес отправителя в электронном письме сам по себе не является достаточным доказательством происхождения сообщения.

Злоумышленник может попытаться отправить письмо, которое визуально выглядит так, будто пришло от известной компании.

Например:

support@company.ru

Хотя сервер, который фактически передал сообщение, к company.ru отношения не имеет.

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

SPF, DKIM и DMARC помогают отвечать на вопросы:

Имеет ли этот сервер право отправлять почту для домена?

Не было ли письмо изменено после подписания?

Совпадает ли проверенный домен с тем, который видит получатель?

Что делать, если проверки не пройдены?

Где находятся SPF, DKIM и DMARC

Эти настройки связаны с DNS домена.

DNS можно представить как систему записей, содержащих техническую информацию о домене.

Управление DNS обычно происходит:

• у регистратора домена;
• у хостинг-провайдера;
• в DNS-сервисе;
• в панели управления инфраструктурой компании.

Для настройки email-аутентификации туда добавляются необходимые записи.

Важно: конкретные значения нельзя копировать из чужих инструкций. Они зависят от используемой инфраструктуры отправки.

Что такое SPF

SPF — Sender Policy Framework.

SPF позволяет владельцу домена указать, какие серверы или инфраструктуры имеют право отправлять почту для этого домена.

Условно владелец company.ru сообщает:

почту для моего домена могут отправлять вот эти серверы.

Эта информация публикуется в DNS.

Когда принимающая почтовая система получает сообщение, она может проверить, соответствует ли источник отправки опубликованной SPF-политике.

Пример SPF-записи

Упрощённая запись может выглядеть примерно так:

v=spf1 include:example.com -all

Это только пример структуры, а не запись, которую нужно устанавливать для своего домена.

Конкретный SPF предоставляет ваш почтовый или email-сервис.

Что означает v=spf1

Это указание версии SPF.

Практически современные SPF-записи начинаются с:

v=spf1

После этого перечисляются разрешённые источники отправки и правила обработки остальных серверов.

Что означает include

Механизм include позволяет использовать SPF-политику другой инфраструктуры.

Например, если компания отправляет письма через внешний сервис, SPF может разрешать его серверы.

Именно поэтому при подключении сервиса рассылок часто требуется внести изменение в DNS.

Что означает all

В конце SPF обычно задаётся правило для источников, не совпавших с предыдущими условиями.

Можно встретить, например:

-all

или:

~all

Они имеют разный смысл, поэтому менять один вариант на другой без понимания настройки не стоит.

Можно ли создать несколько SPF-записей

Одна из распространённых ошибок — добавлять отдельную SPF-запись для каждого сервиса.

Например:

v=spf1 include:service1.example -all

и ещё одну:

v=spf1 include:service2.example -all

Для одного домена SPF-политику обычно нужно объединять корректно в рамках одной записи.

Если компания использует несколько систем отправки, их нужно учитывать совместно.

Что проверяет SPF

SPF связан прежде всего с источником, от которого принимающая система получила сообщение, и доменом, используемым в процессе SMTP-доставки.

Это важная техническая деталь.

SPF не просто смотрит на красивый адрес в строке:

От кого: Компания news@company.ru

Поэтому одной SPF-проверки недостаточно для полной защиты видимого домена отправителя.

Именно здесь становится важен DMARC.

Что такое DKIM

DKIM — DomainKeys Identified Mail.

Если SPF отвечает на вопрос:

разрешён ли источник отправки?

то DKIM решает другую задачу.

Он позволяет добавить к письму цифровую подпись, связанную с доменом.

Упрощённая схема:

отправляющая система

↓

подписывает письмо

↓

письмо передаётся получателю

↓

принимающая система получает открытый ключ из DNS

↓

проверяет подпись.

Для чего нужна DKIM-подпись

Она помогает подтвердить:

1. что сообщение было подписано системой, имеющей соответствующий ключ;
2. что важные подписанные части сообщения не были изменены после формирования подписи.

То есть DKIM связан не только с источником отправки, но и с целостностью сообщения.

Как работает DKIM

Используется пара криптографических ключей.

Закрытый ключ

Хранится у отправляющей системы.

Он не публикуется.

Открытый ключ

Размещается в DNS домена.

Принимающий сервер использует его для проверки подписи.

Самому маркетологу обычно не требуется вручную генерировать подпись для каждого письма.

Это делает email-инфраструктура автоматически.

Что такое DKIM selector

В DKIM используется понятие selector — селектор.

Он позволяет одному домену иметь разные DKIM-ключи.

DNS-запись может находиться по адресу примерно такого вида:

selector._domainkey.company.ru

Где selector — значение, определённое отправляющей системой.

Это позволяет, например, использовать разные ключи для разных сервисов или менять ключи без изменения всей архитектуры домена.

Нужно ли вставлять DKIM в HTML письма

Нет.

DKIM — это не элемент дизайна и не часть текста письма.

Подпись добавляется на техническом уровне.

Получатель обычно вообще её не замечает.

Что такое DMARC

DMARC — Domain-based Message Authentication, Reporting and Conformance.

DMARC использует результаты SPF и DKIM и добавляет ещё один важный элемент — проверку соответствия доменов.

Это называют alignment.

Задача DMARC — связать техническую аутентификацию с доменом, который пользователь видит в поле отправителя.

Почему SPF и DKIM недостаточно без DMARC

Представим письмо:

От: support@company.ru

Но техническая SPF-проверка относится к совершенно другому домену.

Сам SPF при определённых условиях может пройти успешно.

При этом получатель видит company.ru.

DMARC проверяет, соответствует ли прошедший аутентификацию домен видимому домену отправителя по установленным правилам.

Это принципиально важное отличие.

Что такое alignment

Alignment можно перевести как соответствие доменов.

Для прохождения DMARC требуется, чтобы подходящим образом выполнялось хотя бы одно направление:

SPF + alignment

или:

DKIM + alignment.

То есть мало получить техническое:

SPF = pass.

Нужно ещё проверить связь соответствующего домена с доменом в видимом поле From.

То же самое относится к DKIM.

DMARC не требует одновременного прохождения SPF и DKIM

Это распространённое заблуждение.

Для успешной DMARC-проверки не обязательно, чтобы одновременно прошли:

SPF + DKIM + всё остальное.

В общем случае достаточно корректного прохождения одного из механизмов с требуемым alignment:

SPF

или:

DKIM.

Однако на практике профессиональную email-инфраструктуру лучше строить с корректно настроенными обоими механизмами.

Как выглядит DMARC-запись

Упрощённый пример:

v=DMARC1; p=none;

DMARC размещается в DNS по специальному имени:

_dmarc.company.ru

В записи можно задавать дополнительные параметры.

Что означает p

Один из главных параметров DMARC — политика.

Можно встретить:

p=none

Наблюдение без требования отклонять сообщения на основании политики DMARC.

p=quarantine

Сообщения, не соответствующие политике, рекомендуется обрабатывать более строго, например отправлять в спам или карантин.

p=reject

Сообщения, не прошедшие необходимые проверки, рекомендуется отклонять.

Можно ли сразу поставить p=reject

Технически возможно.

Но если компания ещё не знает все легитимные источники отправки своего домена, слишком строгая политика может затронуть и настоящие письма.

Например, домен используется одновременно:

• CRM;
• сайтом;
• сервисом рассылок;
• корпоративной почтой;
• системой уведомлений.

Если часть инфраструктуры не учтена, резкое включение строгой политики создаст проблемы.

Поэтому DMARC желательно внедрять осознанно, предварительно проверив все источники отправки.

DMARC-отчёты

DMARC умеет не только задавать политику, но и предоставлять данные о том, кто отправляет письма от имени домена.

Для агрегированных отчётов используется, например, параметр:

rua=

Отчёты помогают увидеть:

• источники отправки;
• результаты SPF;
• результаты DKIM;
• соответствие DMARC;
• неизвестные системы, использующие домен.

Для крупных компаний это важный инструмент контроля почтовой инфраструктуры.

Зачем отчёты небольшому бизнесу

Даже небольшая компания со временем может обнаружить, что письма отправляют:

• основной сервис рассылок;
• CRM;
• WordPress;
• интернет-магазин;
• бухгалтерская система;
• форма обратной связи.

Без единой картины легко забыть одну из систем.

DMARC-отчёты могут помочь увидеть фактические источники.

Как SPF, DKIM и DMARC работают вместе

Упростим весь процесс.

Компания отправляет:

news@company.ru

Шаг 1. Письмо приходит принимающей системе

Например, почтовому сервису клиента.

Шаг 2. Проверяется SPF

Разрешён ли используемый источник политикой домена.

Шаг 3. Проверяется DKIM

Есть ли валидная цифровая подпись и соответствует ли она опубликованному ключу.

Шаг 4. DMARC анализирует результат

Сопоставляет домены и определяет, выполнены ли требования политики.

Шаг 5. Почтовая система использует результат

Аутентификация становится одним из множества сигналов при обработке сообщения.

Важно:

успешные SPF, DKIM и DMARC не гарантируют попадание письма во «Входящие».

Но отсутствие или ошибки в них могут создавать проблемы для профессиональной отправки.

SPF, DKIM и DMARC влияют на доставляемость?

Да, корректная аутентификация является важной частью email-инфраструктуры.

Но неверно представлять ситуацию так:

настроили три записи → теперь 100% писем будут во «Входящих».

Кроме аутентификации имеют значение:

• репутация отправителя;
• качество базы;
• количество ошибок;
• жалобы;
• содержание;
• история отправок;
• реакция получателей;
• правила конкретной почтовой системы.

Подробнее это разобрано в статье «Почему письма попадают в спам и что с этим делать».

SPF, DKIM и DMARC — это антиспам?

Не совсем.

Они являются механизмами аутентификации и защиты домена.

Антиспам-системы могут учитывать результаты этих проверок, но ими работа фильтра не ограничивается.

Например, письмо может:

• успешно пройти SPF;
• успешно пройти DKIM;
• пройти DMARC;

и всё равно быть признано нежелательным из-за других факторов.

Поэтому нельзя использовать аутентификацию как разрешение:

теперь можно отправлять любые письма любой базе.

Защищают ли SPF, DKIM и DMARC от подделки домена

Они существенно помогают бороться с неавторизованным использованием домена в email.

Особенно важен здесь DMARC с правильно настроенной политикой.

Но эффективность зависит от корректности всей конфигурации.

Просто создать TXT-запись недостаточно.

Нужно убедиться, что:

• SPF действительно учитывает нужные источники;
• DKIM подписывает сообщения нужным доменом;
• alignment работает;
• DMARC-политика соответствует инфраструктуре.

Нужно ли настраивать эти записи для массовых рассылок

Для профессиональной отправки со своего домена — да, доменную аутентификацию стоит рассматривать как базовую техническую часть настройки.

Особенно если компания регулярно отправляет:

• маркетинговые рассылки;
• автоматические цепочки;
• транзакционные уведомления;
• письма через SMTP;
• email через API.

Для интеграционной отправки можно использовать SMTP и API QWERTYMAIL.

Что будет, если не настроить SPF

Результат зависит от инфраструктуры и принимающей системы.

Возможны:

• ошибки аутентификации;
• ухудшение доверия к отправителю;
• ограничения;
• проблемы с доставкой.

Но нельзя сказать:

нет SPF = каждое письмо обязательно попадёт в спам.

Почтовые системы принимают решения по совокупности факторов.

Что будет, если не настроить DKIM

Письма не будут иметь соответствующей DKIM-подписи от нужного домена.

Для современной профессиональной отправки это серьёзный недостаток.

Особенно при использовании DMARC и развитой доменной инфраструктуры.

Что будет без DMARC

SPF и DKIM могут продолжать работать самостоятельно.

Но владелец домена теряет важный слой контроля:

• alignment;
• опубликованную политику;
• DMARC-отчётность.

Поэтому SPF + DKIM нельзя считать полным аналогом SPF + DKIM + DMARC.

Что настраивать первым

Обычно логика выглядит так:

1. Определить все системы, отправляющие email

↓

2. Проверить SPF

↓

3. Настроить DKIM для используемых сервисов

↓

4. Проверить результаты

↓

5. Добавить и контролировать DMARC

↓

6. После проверки инфраструктуры постепенно выбирать подходящую DMARC-политику

Главное — сначала понять архитектуру.

Определите все источники отправки

Перед изменением DNS составьте список.

Например:

Система	Что отправляет
Корпоративная почта	Переписка сотрудников
QWERTYMAIL	Email-рассылки
CRM	Автоматические уведомления
Интернет-магазин	Заказы
Сайт	Формы и системные сообщения

Это помогает не забыть какую-либо инфраструктуру при изменении SPF или DMARC.

Ошибка №1. Несколько SPF-записей

Очень распространённая проблема.

Компания подключила один сервис:

добавили SPF.

Позже подключила второй:

добавили ещё один SPF.

В итоге DNS содержит несколько конкурирующих SPF-политик.

Правильнее корректно сформировать единую политику для домена.

Ошибка №2. Скопировать SPF другой компании

Нельзя брать запись из статьи:

v=spf1 include:example.com -all

и просто устанавливать себе.

В SPF должны быть указаны именно те источники, которыми пользуется ваша компания.

Ошибка №3. Поменять SPF и забыть старые системы

Например, маркетолог подключил новый сервис рассылок.

Создал новую SPF-запись и удалил старую.

После этого перестала нормально работать корпоративная почта или CRM.

Поэтому изменение SPF должно учитывать все легитимные источники.

Ошибка №4. DKIM-запись создана неправильно

Можно ошибиться:

• в selector;
• имени DNS-записи;
• значении ключа;
• типе записи;
• расположении записи.

Поэтому после настройки нужно обязательно проверить, что запись действительно доступна через DNS.

Ошибка №5. DNS-запись ещё не распространилась

DNS-изменения не всегда становятся видны всем системам мгновенно.

После изменения иногда требуется время.

Поэтому ситуация:

добавил запись две минуты назад → проверка показывает ошибку

не всегда означает, что запись неправильная.

Ошибка №6. DMARC reject включён слишком рано

Компания ещё не разобралась с инфраструктурой, но сразу устанавливает строгую политику.

После этого оказывается, что:

• CRM не подписывает письма нужным образом;
• сайт использует другой источник;
• часть корпоративной почты не соответствует политике.

Сначала лучше получить ясную картину отправки.

Ошибка №7. Проверять только наличие записи

Например:

SPF есть — значит всё настроено.

Не обязательно.

Запись может существовать, но:

• не включать нужный сервис;
• содержать ошибку;
• превышать технические ограничения;
• конфликтовать с архитектурой.

Наличие и корректность — разные вещи.

Как проверить SPF

Существуют DNS-инструменты, позволяющие посмотреть TXT-записи домена.

Но простого отображения текста недостаточно.

Нужно проверить:

• присутствует ли SPF;
• нет ли нескольких SPF-политик;
• учтены ли нужные источники;
• корректен ли синтаксис.

Если вы используете сторонний сервис отправки, сверяйтесь с его актуальной инструкцией.

Как проверить DKIM

Для проверки необходимо знать selector.

Например:

selector._domainkey.company.ru

После этого можно проверить наличие соответствующей DNS-записи.

Но финальная проверка — это не только наличие ключа.

Полезно также убедиться, что реальные отправляемые сообщения получают корректную DKIM-подпись.

Как проверить DMARC

DMARC ищется по адресу:

_dmarc.company.ru

Например, запись может начинаться:

v=DMARC1;

После этого нужно проверить параметры политики.

Если DMARC используется с отчётами, необходимо также убедиться, что адрес получения отчётов работает и данные анализируются.

Как увидеть результаты аутентификации в самом письме

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

В зависимости от почтового сервиса встречаются данные вроде:

spf=pass
dkim=pass
dmarc=pass

Это очень полезный способ диагностики.

Если запись в DNS существует, но реальное письмо получает:

dkim=fail

значит одной проверки DNS недостаточно — нужно разбираться с фактической отправкой.

Что значит pass

Упрощённо:

соответствующая проверка успешно пройдена.

Но даже три значения:

spf=pass
dkim=pass
dmarc=pass

не являются гарантией доставки во «Входящие».

Это подтверждение корректной аутентификации, а не оценка всего письма.

Что значит fail

Это означает, что проверка не выполнена согласно условиям механизма.

Причину нужно искать отдельно.

Например:

• неправильный источник;
• проблема с подписью;
• отсутствие alignment;
• неверная DNS-конфигурация.

SPF и переадресация

При пересылке email схема доставки может становиться сложнее.

SPF особенно чувствителен к тому, какой сервер фактически передаёт письмо следующему получателю.

Именно поэтому наличие DKIM становится особенно полезным: корректная подпись может пережить часть сценариев пересылки, если подписанное содержимое не изменилось критически.

DMARC, в свою очередь, может использовать прошедший DKIM с alignment.

DKIM и изменение письма

Если после подписания изменить части сообщения, которые входят в DKIM-подпись, проверка может перестать проходить.

Это логично:

подпись подтверждает определённое содержимое.

После существенного изменения оно уже не совпадает с подписанным вариантом.

Можно ли использовать один домен для нескольких сервисов

Да.

Например:

• корпоративная почта;
• CRM;
• сервис email-рассылок;
• интернет-магазин.

Но все системы нужно учитывать в общей архитектуре аутентификации.

SPF, DKIM и DMARC как раз позволяют управлять такой инфраструктурой.

Можно ли использовать поддомен

Да, компании часто разделяют разные потоки с помощью поддоменов.

Например условно:

mail.company.ru

или:

notify.company.ru

Конкретная архитектура зависит от проекта.

Разделение может быть удобно для управления разными типами email, но само по себе не является магическим способом улучшить доставляемость.

SPF, DKIM, DMARC и SMTP

Это тоже разные уровни.

SMTP — протокол передачи email.

SPF/DKIM/DMARC — механизмы аутентификации и контроля домена.

То есть компания может отправлять письма через SMTP, а домен отправителя при этом проверяется с помощью SPF, DKIM и DMARC.

Подробнее про техническую отправку:

SMTP для рассылки писем: что это и когда он нужен.

SPF, DKIM и API

При API-отправке ситуация аналогичная.

То, что приложение передало письмо через REST API, не отменяет необходимости корректной доменной инфраструктуры.

API — способ взаимодействия приложения с email-сервисом.

А доменная аутентификация решает другую задачу.

Подробнее:

SMTP или API для отправки email: что выбрать.

А что насчёт транзакционных писем

Транзакционные сообщения тоже должны иметь корректную инфраструктуру отправителя.

Особенно потому, что некоторые из них критичны:

• восстановление доступа;
• подтверждение заказа;
• регистрация;
• уведомление об операции.

Подробнее:

Транзакционные письма: что это такое.

SPF и качество базы — разные задачи

Правильно настроенный SPF не исправит базу, состоящую из несуществующих адресов.

А чистая база не исправит ошибочную DNS-конфигурацию.

Поэтому доставляемость нужно рассматривать комплексно.

Перед большой отправкой по старой базе можно отдельно проверить адреса через валидатор email QWERTYMAIL.

Может ли валидатор проверить SPF, DKIM и DMARC

Это отдельные задачи.

Валидатор email работает с email-адресами базы.

SPF, DKIM и DMARC относятся к инфраструктуре домена отправителя.

Не нужно смешивать:

проверку получателей

и

аутентификацию отправителя.

Обе задачи важны, но решают разные проблемы.

Настроили SPF, DKIM и DMARC — что дальше

После настройки не стоит считать работу завершённой навсегда.

Инфраструктура меняется.

Компания может:

• сменить сервис рассылок;
• подключить новую CRM;
• запустить интернет-магазин;
• добавить систему поддержки;
• отказаться от старой почтовой платформы.

После таких изменений DNS-конфигурацию нужно пересматривать.

Удаляйте неиспользуемые источники

Если компания больше не использует старый сервис, его разрешения не обязательно должны оставаться в SPF бесконечно.

Чем понятнее и актуальнее инфраструктура, тем проще её контролировать.

Чек-лист настройки домена для email

Перед массовой отправкой проверьте:

1. Известны все системы, которые отправляют письма от имени домена.
2. Для домена существует одна корректная SPF-политика.
3. SPF учитывает действующие источники.
4. DKIM настроен для используемых систем.
5. Реальные письма проходят DKIM-проверку.
6. DMARC опубликован.
7. Проверен alignment.
8. DMARC-политика соответствует текущему состоянию инфраструктуры.
9. При необходимости анализируются DMARC-отчёты.
10. Старые системы удаляются из конфигурации после отключения.
11. После изменений выполняется тестовая отправка.
12. Проверяются технические заголовки полученного письма.

Частые вопросы

Что важнее: SPF, DKIM или DMARC?

У них разные задачи, поэтому выбирать один механизм вместо остальных неправильно.

Для современной профессиональной email-инфраструктуры имеет смысл использовать их совместно.

Можно ли настроить только SPF?

Можно встретить такую конфигурацию, но она не даёт возможностей DKIM и DMARC.

Для регулярных бизнес-рассылок лучше рассматривать полный набор механизмов.

Нужно ли создавать SPF для каждой рассылки?

Нет.

SPF относится к доменной инфраструктуре, а не к конкретной маркетинговой кампании.

Нужно ли менять DKIM перед каждым письмом?

Нет.

Email-сервис автоматически подписывает сообщения соответствующим ключом.

Что лучше: p=none или p=reject?

Это не вопрос «лучше/хуже».

Политика зависит от готовности инфраструктуры. p=none часто используется для наблюдения, а p=reject — строгая политика, которую следует применять после понимания всех легитимных потоков отправки.

SPF, DKIM и DMARC гарантируют попадание во «Входящие»?

Нет.

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

Нужно ли настраивать записи при отправке через сервис рассылок?

Если сервис использует ваш домен отправителя и предоставляет инструкции по его аутентификации, эти настройки нужно выполнить в соответствии с его документацией.

Где находятся эти записи?

В DNS вашего домена.

Что в итоге

SPF, DKIM и DMARC решают три связанные, но разные задачи.

SPF

Какие источники могут отправлять почту для домена?

DKIM

Подписано ли сообщение соответствующим доменом и сохранилась ли подпись?

DMARC

Соответствует ли аутентификация видимому домену отправителя и какую политику применить при проблемах?

Вместе они формируют основу аутентификации отправителя:

домен

↓

SPF + DKIM

↓

проверка alignment

↓

DMARC

↓

дальнейшее решение принимающей почтовой системы

Но техническая аутентификация — лишь часть доставляемости.

Нужно одновременно следить за:

• состоянием базы;
• жалобами;
• репутацией;
• ошибками доставки;
• содержанием;
• стабильностью отправок.

Если письма уже начали попадать в спам, используйте отдельную инструкцию:

Почему письма попадают в спам и что с этим делать.

А если сайт, CRM или приложение должны автоматически отправлять сообщения, возможности интеграционной отправки собраны на странице SMTP и API QWERTYMAIL.