SPF, DKIM и DMARC: как настроить аутентификацию email

Если вы когда-нибудь запускали email-рассылку и обнаруживали, что ваши письма массово уходят в папку «Спам» - скорее всего, дело не в содержании и не в теме письма. Дело в том, что почтовые серверы получателей просто не могут подтвердить: а точно ли это письмо отправлено с вашего домена, а не от мошенника? Именно для решения этой проблемы существуют три протокола аутентификации: SPF, DKIM и DMARC. В моей практике с 2013 года я видел десятки проектов, где рассылки просто не работали - не потому что письма были плохими, а потому что базовая техническая настройка отсутствовала. Владельцы бизнеса тратили деньги на копирайтинг и шаблоны, но не потрудились потратить час на настройку spf dkim и DMARC. Результат - письма в спаме, деньги на ветер.

Эта статья - пошаговое руководство по настройке трёх протоколов аутентификации электронной почты. Я разберу каждый из них простым языком, покажу готовые примеры записей DNS, расскажу про типичные ошибки и объясню, как проверить результат. Материал подойдёт владельцам сайтов, маркетологам, администраторам серверов - всем, кто отправляет письма с собственного домена и хочет, чтобы они доходили до адресата, а не оседали в папке нежелательной почты. Настройка занимает 30-60 минут. После этого базовая защита работает долгое время - DKIM-ключи стоит периодически ротировать, а SPF-запись обновлять при смене сервисов рассылок.

Важный момент: протоколы работают на уровне DNS - это система доменных имён, которая хранит различные записи о вашем домене. Вам не нужно быть программистом, чтобы всё настроить. Нужно иметь доступ к панели управления доменом и понимать, что именно вы вносите. Если вы работаете с WordPress, управляете сайтом через хостинг или пользуетесь корпоративной почтой Google или Яндекса - всё описанное ниже применимо напрямую. Начнём с самого главного: что такое эти три протокола и почему без них ваши письма будут продолжать попадать в спам.

Что такое SPF, DKIM и DMARC - и почему без них письма идут в спам

Представьте ситуацию: злоумышленник хочет отправить фишинговое письмо от имени вашей компании. Он указывает в поле «От кого» ваш домен - и технически ничто не мешает ему это сделать, если у вас не настроена аутентификация. Сервер получателя получает письмо, видит знакомый домен, но не знает, настоящее оно или поддельное. Что он делает? Либо отправляет в спам на всякий случай, либо пропускает - и тогда ваши клиенты получают мошеннические письма якобы от вас.

Три протокола - SPF, DKIM и DMARC - решают эту проблему на разных уровнях. Каждый выполняет свою функцию, и вместе они создают надёжную систему проверки подлинности почты.

Sender Policy Framework (SPF) содержит список серверов, которым разрешено отправлять письма от имени вашего домена. Вы публикуете этот список в DNS в виде специальной TXT-записи. Когда почтовый сервер получателя принимает письмо от вашего домена, он смотрит в DNS: есть ли там SPF-запись и входит ли IP-адрес отправителя в список разрешённых? Если да - письмо прошло первую проверку. Аналог - пропуск на охраняемый объект: только те, кто в списке, могут войти.

DomainKeys Identified Mail (DKIM) добавляет цифровую подпись внутрь каждого письма. Ваш почтовый сервер подписывает письмо с помощью закрытого ключа, а публичный ключ хранится в DNS вашего домена. Сервер получателя скачивает публичный ключ и проверяет подпись. Если подпись совпадает - письмо точно отправлено вашим сервером и не было изменено в пути. DKIM защищает не только от подделки отправителя, но и от модификации содержимого письма в процессе передачи.

Domain-based Message Authentication, Reporting and Conformance (DMARC) - надстройка над SPF и DKIM. Запись в DNS говорит почтовым серверам, что делать с письмами, которые не прошли проверку SPF или DKIM. Пропустить? Отправить в спам? Отклонить? Плюс DMARC позволяет получать отчёты о том, кто и откуда пытается отправлять письма от имени вашего домена - включая мошенников. По сути, это механизм обратной связи, который даёт вам контроль над ситуацией.

Как они работают в связке? Когда приходит письмо от вашего домена, сервер получателя последовательно проверяет: есть ли в DNS SPF-запись и входит ли отправитель в список (SPF-проверка), есть ли в письме DKIM-подпись и совпадает ли она с публичным ключом в DNS (DKIM-проверка), что говорит DMARC-запись - что делать, если одна или обе проверки провалены. Только пройдя эту цепочку, письмо попадает во входящие с хорошей репутацией. Без настроенных записей письма либо идут в спам, либо вы рискуете, что мошенники рассылают фишинг от вашего имени - и это бьёт по доверию к вашему домену.

Типичная ошибка, которую я встречаю у клиентов: настроили SPF, но забыли про DKIM и DMARC. Или настроили все три, но не добавили в SPF сервис рассылок - и письма из Mailchimp или UniSender уходят в спам, потому что их серверы не входят в список разрешённых. Система работает только в комплексе.

Как работает запись SPF - синтаксис и готовые примеры

SPF-запись - это обычная TXT-запись в DNS вашего домена. Выглядит она как строка текста с определённым синтаксисом. Разберём структуру по частям, чтобы вы понимали, что именно прописываете - а не просто копировали чужие строки вслепую.

Базовая структура записи: v=spf1 [механизмы] [квалификатор]all

Первая часть v=spf1 - обязательная версия протокола. Всегда в начале строки. Другой версии не существует.

Далее идут механизмы - правила, которые определяют, какие серверы могут отправлять письма от имени вашего домена:

• include: - подключает SPF-запись другого домена. Используется, когда вы отправляете через сторонний сервис. Например, v=spf1 include:_spf.google.com - это значит «разрешить всё, что разрешено в SPF-записи Google».
• ip4: - конкретный IPv4-адрес или диапазон. Например, ip4:185.12.34.56 или ip4:185.12.34.0/24 для всей подсети.
• a - A-запись вашего домена. Разрешает сервер, на который указывает домен.
• mx - MX-записи домена. Разрешает серверы, которые принимают почту для домена.

В конце строки обязательно стоит завершающий механизм all с квалификатором - он определяет, что делать с серверами, которые не попали ни в один из предыдущих механизмов.

Квалификатор	Запись	Что означает для сервера получателя
+ (плюс)	+all	Разрешить все серверы. Фактически отключает SPF - так делать не нужно
- (минус)	-all	Жёсткий запрет: письма с серверов, не входящих в список, отклонять (FAIL)
~ (тильда)	~all	Мягкий режим: серверы вне списка помечаются как подозрительные (SOFTFAIL), но не отклоняются
? (вопрос)	?all	Нейтральный режим: никакого суждения, письмо пропускается без оценки

Какой выбрать - ~all или -all? На старте, когда вы только настраиваете SPF и не уверены, что все серверы учтены, используйте ~all. Это мягкий режим - письма не будут отклонены, но получат отметку. После того как убедитесь, что вся легитимная почта проходит проверку, переключайтесь на -all. В нашей студии мы всегда начинаем с тильды, выдерживаем пару недель, смотрим DMARC-отчёты - и только потом ставим жёсткий запрет.

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

Ещё одно ограничение - не более 10 DNS-запросов при обработке SPF. Каждый include:, a, mx - это дополнительный запрос. Если превысите лимит, SPF вернёт ошибку PermError, и письма могут не пройти проверку. Следите за количеством механизмов.

Готовые примеры записей (приведённые значения include: актуальны на момент написания - перед использованием проверяйте их в официальной документации сервиса):

Только Google Workspace: v=spf1 include:_spf.google.com ~all

Только Яндекс 360 для бизнеса: v=spf1 include:_spf.yandex.net ~all

Свой сервер плюс UniSender: v=spf1 ip4:185.12.34.56 include:_spf.unisender.com ~all

Google Workspace плюс сервис рассылок плюс свой сервер: v=spf1 include:_spf.google.com include:sendgrid.net ip4:185.12.34.56 ~all

На реальном проекте это выглядит так: клиент из сферы промышленного оборудования отправлял письма через корпоративный Gmail и параллельно - автоматические уведомления с сайта через хостинговый сервер. Настроили одну SPF-запись, которая включала серверы, обслуживающие оба канала: v=spf1 include:_spf.google.com ip4:[IP хостинга] ~all. До этого письма от имени его домена периодически уходили в спам - после настройки проблема исчезла.

После добавления SPF-записи ждите от 15 минут до 48 часов - столько занимает распространение DNS. Проверить результат можно через MxToolbox или аналогичные сервисы - об этом подробнее в разделе про проверку настройки.

Как настроить DKIM - генерация ключей и добавление в DNS

DKIM (DomainKeys Identified Mail) добавляет цифровую подпись к каждому письму. Получатель проверяет подпись через публичный ключ, опубликованный в DNS вашего домена. Если подпись совпадает - письмо точно пришло от вас и не было изменено в пути.

Ключевое понятие, без которого не разобраться с DKIM, - селектор. Это уникальное имя, которое привязывает публичный ключ к конкретному сервису или версии ключа. Например, у вас может быть селектор google для Google Workspace и селектор mail для хостинговой почты. Запись в DNS выглядит так: selector._domainkey.yourdomain.com. Именно через селектор сервер получателя находит нужный ключ в DNS.

Три сценария настройки - выбирайте тот, который подходит вашей ситуации.

Сценарий 1 - через панель хостинга (самый простой). Большинство современных хостингов - Timeweb, Beget, REG.RU, ISPmanager - уже настраивают DKIM автоматически при создании почтового домена. Проверьте раздел «Почта» или «DNS» в панели управления. Если DKIM включён, вы увидите готовую TXT-запись. Вам остаётся только убедиться, что она активна.

Сценарий 2 - Google Workspace или Яндекс 360. Здесь DKIM генерируется в настройках самого сервиса. В Google Workspace: Admin Console - Приложения - Google Workspace - Gmail - Аутентификация почты - Создать новую запись. Система сама генерирует пару ключей и показывает TXT-запись, которую нужно добавить в DNS. В Яндекс 360 путь похожий: Почта - Настройки домена - DKIM.

Сценарий 3 - OpenDKIM на собственном VPS. Если у вас свой почтовый сервер, придётся генерировать ключи вручную. Команда генерации: opendkim-genkey -t -s mail -d yourdomain.com. В результате получите два файла - приватный ключ (остаётся на сервере) и файл с публичным ключом для DNS.

Формат записи DKIM в DNS во всех случаях одинаковый:

• Хост: mail._domainkey (где mail - ваш селектор)
• Тип: TXT
• Значение: v=DKIM1; k=rsa; p=MIGfMA0GCSq...

Важный подводный камень: публичный ключ RSA-2048 в base64-кодировке занимает порядка 300-400 символов. Некоторые панели управления DNS ограничивают длину TXT-записи до 255 символов. Если запись не принимается - разбейте значение на две части в кавычках: "v=DKIM1; k=rsa; p=первая_половина" "вторая_половина". Большинство современных DNS-серверов корректно склеивают такие части.

В моей практике встречал ситуацию, когда клиент часами пытался добавить DKIM через панель регистратора, и запись постоянно отклонялась. Оказалось, что интерфейс молча обрезал ключ до 255 символов. Решение - перенести DNS на Cloudflare, который без проблем принимает длинные TXT-записи. После этого и DKIM, и DMARC заработали с первой попытки.

Из практики студии «Мельница»

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

Как настроить DMARC - от мониторинга к защите

DMARC (Domain-based Message Authentication Reporting and Conformance) говорит серверу получателя, что делать с письмами, которые не прошли проверку SPF или DKIM. Без DMARC почтовый сервер сам решает, пропустить письмо или отправить в спам. С DMARC вы задаёте политику явно.

Важный момент, который часто упускают: DMARC проверяет не просто факт наличия SPF и DKIM, а выравнивание (alignment). Домен в поле From письма должен совпадать с доменом, который прошёл проверку SPF или DKIM. Это защищает от ситуации, когда злоумышленник использует чужой валидный SPF, но подставляет ваш домен в From.

Три политики DMARC - основа, которую нужно понять перед настройкой:

Политика	Что происходит с письмами, которые не прошли проверку	Когда использовать
p=none	Письма доставляются как обычно, только собираются отчёты	Старт - первые 2-4 недели, мониторинг без блокировок
p=quarantine	Письма, не прошедшие проверку, попадают в папку «Спам»	Промежуточный этап, когда уверены в легитимных потоках
p=reject	Письма, не прошедшие проверку, отклоняются полностью	Финальная защита домена, максимальная безопасность

Стратегия постепенного внедрения - единственный правильный подход. Никогда не начинайте сразу с p=reject. Если у вас есть хотя бы одна рассылка или сервис, который вы забыли добавить в SPF, все письма из него будут заблокированы.

1. Начните с p=none и укажите адрес для получения отчётов
2. Собирайте отчёты 2-4 недели, анализируйте какие серверы отправляют письма от вашего домена
3. Убедитесь, что все легитимные источники правильно настроены в SPF и DKIM
4. Переключитесь на p=quarantine, сначала с параметром pct=10 (10% писем)
5. Постепенно увеличивайте pct до 100, наблюдая за отчётами
6. Переходите на p=reject когда уверены в результате

Минимальная запись DMARC для старта: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Полная запись с параметрами: v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc-fails@yourdomain.com; adkim=s; aspf=s

Параметр rua - адрес для агрегированных отчётов (приходят раз в сутки, показывают статистику по всем письмам). Параметр ruf - адрес для форензических отчётов по конкретным письмам, которые не прошли проверку. Параметр pct - процент писем, к которым применяется политика, удобен при постепенном переходе. Параметры adkim и aspf со значением s - строгое выравнивание домена.

Добавляется запись как TXT с хостом _dmarc.yourdomain.com. Именно такой формат - с подчёркиванием в начале - является обязательным стандартом. Записи, которые добавлены без него, не работают.

Пошаговая инструкция - добавляем SPF, DKIM и DMARC в DNS

Мы в студии «Мельница» при запуске нового сайта всегда добавляем все три записи ещё до первой отправки писем. Это занимает 20-30 минут, а потом не приходится разбираться, почему письма уходят в спам. Ниже - конкретная инструкция, которую можно применить прямо сейчас.

Прежде всего определите, где управляете DNS вашего домена. Чаще всего это панель хостинга или личный кабинет регистратора доменных имён. Если вы подключили Cloudflare - значит DNS управляете там. Все три записи добавляются в одном месте.

1. Войдите в панель управления DNS. Найдите раздел с названием «DNS», «DNS-записи» или «Управление зоной». Вам нужен доступ к добавлению TXT-записей для вашего домена.

2. Добавьте SPF-запись. Тип - TXT, хост - @ (или пустое поле, или сам домен - зависит от панели), значение - ваша SPF-строка. Пример для тех, кто отправляет через хостинг и Google Workspace: v=spf1 include:_spf.google.com include:yourhostingspf.com ~all. TTL можно оставить по умолчанию или поставить 3600.

3. Добавьте DKIM-запись. Тип - TXT, хост - selector._domainkey (замените selector на ваш реальный селектор, например google._domainkey для Google Workspace), значение - строка публичного ключа вида v=DKIM1; k=rsa; p=.... Если ключ длинный - уточните у вашей DNS-панели, поддерживает ли она длинные TXT-записи.

4. Добавьте DMARC-запись. Тип - TXT, хост - _dmarc, значение - строка политики. Для старта: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Замените адрес на реальный почтовый ящик, куда будут приходить отчёты - он должен существовать и быть доступен.

5. Сохраните все три записи и подождите. Настройка SPF DKIM и DMARC требует времени на распространение. Минимум - 15-30 минут для простых случаев, максимум - 48 часов. Большинство изменений применяется в течение 1-2 часов.

6. Отправьте тестовое письмо. После того как записи распространились - отправьте письмо на внешний адрес (например, на Gmail или Яндекс). Почтовые сервисы крупных провайдеров показывают информацию о прохождении SPF и DKIM прямо в заголовках письма.

Несколько особенностей для популярных хостингов. На Beget и Timeweb DKIM может быть настроен автоматически - проверьте раздел «Почта» перед тем как добавлять вручную, иначе получите дублирующие записи. На REG.RU поле «Хост» при добавлении TXT-записи иногда требует указывать полное имя с точкой в конце: _dmarc.yourdomain.com. На ISPmanager настройка доступна через Менеджер DNS прямо в интерфейсе панели.

Если вы используете Cloudflare - там есть нюанс: записи типа TXT для DKIM и DMARC нельзя проксировать (оранжевое облако). Убедитесь, что статус записи - «DNS only» (серое облако). Иначе сервер получателя не сможет получить ключ, и письма не пройдут проверку.

На этом этапе все три записи добавлены. Следующий шаг - убедиться, что они работают корректно, а не просто числятся в DNS.

Как проверить правильность настройки SPF, DKIM и DMARC

Добавить записи в DNS - это половина дела. Важно убедиться, что они реально работают и письма отправлены с правильными параметрами. Я использую три способа проверки - от быстрого до детального.

Способ 1 - онлайн-инструменты. Самый простой старт. Три сервиса, которые я открываю первыми:

• MxToolbox (mxtoolbox.com) - проверяет SPF и DMARC по домену. Вводите домен, нажимаете «SPF Lookup» или «DMARC Lookup», видите текущую запись и возможные ошибки синтаксиса. Если настройка некорректна - инструмент подсветит проблему красным.
• DKIM Inspector на dmarcian.com - проверяет DKIM-запись. Нужно ввести домен и селектор (тот самый, который вы указали при генерации ключа, например google или mail). Сервис покажет, опубликован ли ключ и корректен ли он.
• mail-tester.com - самый наглядный способ. Сервис даёт вам временный адрес, вы отправляете на него письмо, и получаете оценку из 10 баллов с детальным разбором. Видно, какие параметры прошли, а какие нет - буквально по каждому из них. Целевой результат - 9-10 из 10. Если меньше 8 - смотрите, что именно упало.

Способ 2 - заголовки письма. Когда письмо отправлено и получено, можно посмотреть прямо в заголовки конкретного сообщения. В Gmail нажмите три точки у письма и выберите «Показать оригинал» (Show original). В Яндекс Почте - кнопка «Ещё» и «Служебные заголовки».

Ищите строку Authentication-Results. Там будет что-то вроде:

Authentication-Results: mx.google.com;
  spf=pass (google.com: domain of info@yourdomain.ru designates 1.2.3.4 as permitted sender)
  dkim=pass header.i=@yourdomain.ru
  dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=yourdomain.ru

Три раза pass - идеальная картина. Если видите fail или softfail - запись либо не распространилась ещё, либо настроена с ошибкой. Может быть и ситуация, когда SPF проходит, а DKIM нет - тогда смотрите на селектор и корректность записи вашего имени в DNS.

Способ 3 - Google Postmaster Tools. Долгосрочный инструмент мониторинга, а не разовая проверка. Зайдите на postmaster.google.com, добавьте домен (нужно подтвердить владение через TXT-запись), и через несколько дней после начала отправки появится дашборд. Там есть вкладка «Аутентификация домена» - видно, какой процент писем от вашего имени проходит DKIM, SPF и DMARC. Почтовые сервисы вроде Gmail ориентируются на эту репутацию при принятии решения о доставке. Если видите, что не все письма проходят аутентификацию - значит, часть рассылок идёт через сервис, который не включён в SPF.

Типичные ошибки при настройке и как их избежать

За несколько лет работы с почтовой аутентификацией я насобирал коллекцию ошибок - как своих, так и клиентских. Вот те, что встречаются чаще всего и дороже всего обходятся.

Ошибка 1. Две SPF-записи для одного домена. Симптом: SPF проверяется как fail, хотя запись вроде бы правильная. Причина: в DNS два разных TXT-значения, начинающихся с v=spf1. По стандарту RFC, если записей несколько - обе игнорируются. Решение: объедините всё в одну запись с несколькими механизмами.

Ошибка 2. Превышен лимит 10 DNS-запросов в SPF. Симптом: PermError в результатах проверки. Причина: каждый механизм include: и a: генерирует отдельный DNS-запрос, и если суммарно их больше 10 - запись считается невалидной. Решение: используйте инструменты типа dmarcian SPF Flattening, которые заменяют include-ссылки на конкретные IP-адреса.

Ошибка 3. Не добавили почтовый сервис рассылок в SPF. Симптом: ваши письма из CRM или сервиса рассылок попадают в спам. Причина: сервис отправляет письма, которые технически идут с вашего домена, но его IP не прописан в SPF. Решение: зайдите в настройки сервиса рассылок и найдите там инструкцию по настройке домена - там будет нужный include.

Ошибка 4. Поставили DMARC p=reject сразу, без мониторинга. Симптом: часть легитимных писем от имени вашего домена не доходит. Причина: вы не проверили, что все отправители прошли аутентификацию, и reject отфильтровал нужные письма. Решение: начинайте с p=none, смотрите отчёты минимум 2-4 недели, только потом ужесточайте политику.

Ошибка 5. Неправильный селектор DKIM. Симптом: DKIM fail при, казалось бы, правильной записи. Причина: в настройках почтового сервиса указан один селектор (например, mail), а в DNS вы создали запись с другим именем (например, email). Имя записи в DNS и есть тот самый селектор, который должен совпадать с тем, что использует сервер отправки. Решение: зайдите в панель почтового провайдера, скопируйте точное имя для TXT-записи - не вводите его вручную.

Ошибка 6. Забыли про поддомены. Симптом: рассылки с news.yourdomain.ru не проходят аутентификацию. Причина: SPF и DKIM нужно настраивать отдельно для каждого поддомена, с которого идёт отправка. Решение: проверьте, с каких адресов реально уходят ваши письма - основной домен, поддомен для рассылок, поддомен для транзакционных писем. Для каждого - отдельная настройка.

Ошибка 7. Проверяют до распространения DNS. Симптом: «проверил - не работает», хотя настройка правильная. Причина: DNS-записи распространяются от нескольких минут до 48 часов. Если проверять через 5 минут после добавления - может быть ещё старый кеш. У одного клиента я потратил полчаса на поиск несуществующей ошибки, пока не вспомнил, что запись добавили буквально только что. Решение: подождите минимум 15-30 минут, а лучше проверьте через TTL-период записи. Можно проверить, распространилась ли новая запись, через сервис dnschecker.org - он показывает статус по разным серверам мира.

Как SPF, DKIM и DMARC влияют на доставляемость и репутацию домена

Многие воспринимают SPF, DKIM и DMARC как формальность - «надо настроить, потому что так говорят». На практике это прямой рычаг, влияющий на то, куда попадают ваши письма и как почтовые сервисы оценивают ваш домен.

Требования крупных платформ. В 2024 году Google и Yahoo ввели обязательные требования для массовых отправителей: если вы отправляете более 5000 писем в день на Gmail или Yahoo, наличие SPF, DKIM и DMARC стало обязательным условием. Без них ваши письма будут отклоняться на уровне сервера. Но даже если вы отправляете меньше - эти же сервисы учитывают аутентификацию при оценке репутации домена, просто без жёсткого отказа.

Принцип простой: почтовые сервисы доверяют письмам, у которых есть подтверждённая идентичность. Если письма от имени вашего домена стабильно проходят все три проверки - домен накапливает положительную репутацию. Это значит, что процент доставки в inbox растёт, и со временем даже письма без идеального контента реже попадают в спам.

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

Прогрев новой почты или нового домена. Если вы запускаете новый домен или новый почтовый адрес для рассылок - настройка аутентификации нужна с первого же письма. Репутация не появляется сразу: она накапливается постепенно, по мере того как ваши письма доставляются, открываются и не отмечаются как спам. Но без правильной аутентификации эта репутация не начнёт строиться вообще - письма просто не будут доходить в нужном объёме.

Начинайте с малых объёмов: первые дни - несколько десятков писем в день, потом наращивайте. DMARC в режиме p=none с первого дня позволяет собирать отчёты и видеть, всё ли в порядке с аутентификацией, не блокируя при этом доставку.

DMARC как инструмент защиты от фишинга. Это менее очевидная, но важная функция. Когда мошенники рассылают письма от имени вашего домена - пытаясь обмануть ваших клиентов или партнёров - DMARC-отчёты это фиксируют. Вы получаете XML-файлы на адрес, указанный в rua=, и можете видеть: кто ещё отправляет письма от имени вашего домена, с каких IP, и сколько таких попыток. Это позволяет вовремя обнаружить атаку и при необходимости переключить политику на reject.

Доверие к домену, которое вы строите правильной аутентификацией, работает в обе стороны. Ваши легитимные письма доходят лучше - и одновременно мошенники не могут легко паразитировать на репутации вашего домена. Настройка SPF, DKIM и DMARC занимает час-два разово. Дальше она работает сама - без вашего участия, годами. Это один из тех редких случаев в email-маркетинге, где разовое техническое усилие даёт долгосрочный и измеримый результат: ваши письма доходят туда, куда должны, и почтовые сервисы относятся к ним с доверием.

Эта статья основана на личном опыте автора и актуальна на момент публикации. Интерфейсы сервисов и алгоритмы поисковых систем регулярно меняются - рекомендую проверять актуальность инструкций на официальных ресурсах. Если у вас остались вопросы - задайте их в комментариях.

Список литературы

1. IETF / S. Kitterman - Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 // RFC Editor (rfc-editor.org), 2014. RFC 7208
2. IETF / D. Crocker, T. Hansen, M. Kucherawy - DomainKeys Identified Mail (DKIM) Signatures // RFC Editor (rfc-editor.org), 2011. RFC 6376
3. IETF / M. Kucherawy, E. Zwicky - Domain-based Message Authentication, Reporting, and Conformance (DMARC) // RFC Editor (rfc-editor.org), 2015. RFC 7489
4. Google - Email sender guidelines // Google Workspace Admin Help (support.google.com), 2024