Настройка SPF, DKIM и DMARC: записи, ошибки и проверка

Q: Что использовать в SPF: ~all или -all?

Google рекомендует ~all; Microsoft рекомендует -all для доменов, которые также используют DKIM и DMARC. Начните с ~all, пока отчёты DMARC не подтвердят, что вы нашли всех отправителей, а затем решите, стоит ли переключаться.

Опубликовано 2026-11-03 ／ Обновлено 2026-11-03 ／ Автор Yuki Nakazawa

Настройка SPF, DKIM и DMARC больше не является необязательной, если вы отправляете почту со своего домена. Действуйте в таком порядке: опубликуйте одну запись SPF, включите подпись DKIM с ключом длиной 2048 бит, а затем опубликуйте запись DMARC, начав с p=none и включив отчёты. Заодно убедитесь, что у IP-адреса, с которого уходит ваша почта, есть соответствующая обратная запись DNS (PTR).

Это руководство подходит независимо от того, отправляете ли вы почту с виртуального хостинга, собственного VPS, через Google Workspace, Microsoft 365 или сервис массовых рассылок. В нём есть записи, которые можно адаптировать под себя, ошибки, которые чаще всего ломают аутентификацию, и способ убедиться по заголовку реального письма, что всё работает.

Сведения ниже сверены с RFC и официальными страницами Google, Yahoo и Microsoft по состоянию на ноябрь 2026 года. Требования почтовых сервисов меняются, поэтому окончательным источником считайте их страницы.

Бесплатно проверьте, не числится ли ваш домен или IP-адрес примерно в 345 чёрных списках.

Что подтверждают SPF, DKIM и DMARC и в каком порядке их настраивать

SPF (Sender Policy Framework) позволяет домену перечислить в DNS серверы, которым разрешено отправлять его почту. Принимающий сервер смотрит на отправителя конверта (адрес SMTP MAIL FROM, который затем отображается как Return-Path), получает запись SPF этого домена и проверяет, есть ли в списке IP-адрес подключившегося сервера. Сам по себе SPF ничего не говорит об адресе From, который видит читатель.

DKIM (DomainKeys Identified Mail) добавляет к каждому письму криптографическую подпись. Отправляющая система подписывает письмо закрытым ключом, а получатели проверяют подпись с помощью открытого ключа, опубликованного в DNS. Действительная подпись доказывает, что подписывающий домен (значение d=) взял на себя ответственность за письмо и что подписанные заголовки и тело не были изменены в пути.

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

Механизм	Где находится запись	Что проверяет
SPF	TXT на `example.com`	IP-адрес отправки на соответствие домену MAIL FROM
DKIM	TXT (или CNAME) на `selector._domainkey.example.com`	Подпись и домен `d=`
DMARC	TXT на `_dmarc.example.com`	Выравнивание с доменом From, а также политика и отчёты

Порядок настройки

Составьте список всех систем, отправляющих почту от имени вашего домена: собственный сервер, Google Workspace или Microsoft 365, сервисы рассылок и транзакционных писем, веб-формы, системы выставления счетов и службы поддержки.
Опубликуйте одну запись SPF, охватывающую их все.
Включите DKIM в каждой отправляющей системе и опубликуйте её открытый ключ.
Опубликуйте DMARC с p=none и адресом для отчётов rua. Google советует подождать 48 часов после настройки SPF и DKIM, прежде чем добавлять DMARC.
Изучите отчёты, исправьте источники, не проходящие проверку, затем перейдите на p=quarantine и, наконец, на p=reject.

Настройка SPF: одна запись, десять запросов

SPF — это запись TXT на самом домене. Вот пример домена, который отправляет почту с собственного сервера по IPv4 и IPv6 и также использует Google Workspace:

example.com.  3600  IN  TXT  "v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 include:_spf.google.com ~all"

В большинстве панелей управления DNS поле хоста оставляют пустым (или вводят @), выбирают тип TXT и вставляют значение, начинающееся с v=spf1. Типовые составляющие:

Источник отправки	Что добавить
Собственный VPS или почтовый сервер	`ip4:203.0.113.10` и/или `ip6:2001:db8::10`
Google Workspace	`include:_spf.google.com`
Microsoft 365	`include:spf.protection.outlook.com`
Виртуальный хостинг или почтовый сервис	`include:` или диапазон IP-адресов, указанный в документации провайдера

Подводные камни SPF

Одна запись SPF на имя. RFC 7208 запрещает несколько записей SPF для одного домена: получатели возвращают permerror, и SPF не проходит ни для одного письма. Подключая новый сервис, отредактируйте существующую запись и добавьте в неё его include:, а не создавайте вторую запись v=spf1.
Лимит в 10 запросов. Механизмы include, a, mx, ptr и exists, а также модификатор redirect порождают DNS-запросы, и их общее число за всю проверку, включая запросы внутри вложенных include, не должно превышать 10. Превышение даёт permerror. ip4:, ip6: и all запросов не требуют. RFC 7208 также указывает, что получателям следует прекращать проверку после двух запросов без ответа, поэтому удаляйте include сервисов, которыми больше не пользуетесь.
~all или -all. -all означает, что неперечисленные источники не авторизованы (fail); ~all — что они, вероятно, не авторизованы (softfail). Google рекомендует ~all для доменов Workspace; Microsoft рекомендует -all для доменов Microsoft 365, которые также используют DKIM и DMARC. Если вы ещё не уверены, что нашли всех отправителей, начните с ~all и предоставьте применение политики DMARC.
Поддоменам нужна собственная запись. Запись SPF на example.com не распространяется на news.example.com. Если вынести сервис массовых рассылок на отдельный поддомен, он также получит собственный лимит в 10 запросов, а его репутация будет отделена от почты сотрудников.
Синтаксические ошибки. Microsoft перечисляет типичные: include= вместо include:, пробел после двоеточия и точка в конце подключаемого домена.

Для доменов, которые никогда не отправляют почту, опубликуйте v=spf1 -all, чтобы их было сложнее подделать.

Настройка DKIM: ключи 2048 бит и селекторы

DKIM состоит из двух половин: отправляющая система подписывает письма закрытым ключом, а в DNS публикуется соответствующий открытый ключ. В Google Workspace, Microsoft 365, большинстве панелей управления хостингом и большинстве почтовых сервисов ключ создаётся в консоли администратора, и вы копируете показанное там значение для DNS.

Длина ключа и селекторы

Используйте ключ RSA длиной 2048 бит. RFC 8301 устанавливает минимум в 1024 бита и указывает, что подписывающим следует использовать не менее 2048 бит; там же запрещён rsa-sha1. Рекомендации Google совпадают: выбирайте 2048 бит, если ваш DNS-хостинг это поддерживает, и переходите на 1024 только в противном случае.

Селектор — это метка, указывающая, каким ключом подписано письмо, поэтому у домена может быть одновременно несколько ключей: по одному на каждый сервис отправки или на каждый период ротации. Открытый ключ размещается по адресу selector._domainkey.yourdomain. Google Workspace по умолчанию использует селектор google. Microsoft 365 использует две записи CNAME, selector1._domainkey и selector2._domainkey, указывающие на ключи, размещённые у Microsoft; точные целевые значения берите на портале Defender или из Get-DkimSigningConfig, потому что формат зависит от клиента (tenant).

Публикация длинного открытого ключа

Открытый ключ длиной 2048 бит длиннее 255 символов, допустимых в одной символьной строке DNS, поэтому в файле зоны он записывается как несколько строк в кавычках в одной записи TXT:

selector1._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA(first part of your key)"
    "(rest of your key)IDAQAB" )

Замените части в скобках своим настоящим ключом. Получатели склеивают строки без пробелов, поэтому разбивать ключ можно в любом месте. Многие панели управления разбивают длинные значения автоматически: сначала вставьте значение целиком и разбивайте его сами, только если панель его не принимает. Следите, чтобы при копировании ничего не потерялось: пустой p= означает, что ключ отозван.

На собственном VPS с Postfix или аналогичным MTA пару ключей может создать подписывающий milter, например OpenDKIM: opendkim-genkey -b 2048 -s selector1 -d example.com. Опубликуйте содержимое созданного файла открытого ключа, как показано выше.

Убедитесь, что письма действительно подписываются

Откройте отправленное вами письмо и найдите заголовок DKIM-Signature:. Его тег d= должен содержать ваш домен, а s= — опубликованный вами селектор. Многие почтовые сервисы по умолчанию подписывают письма своим доменом; такая подпись проходит DKIM, но не выровнена с вашим доменом From и поэтому не помогает с DMARC. Включите в сервисе аутентификацию собственного домена, чтобы в d= стоял ваш домен.

Настройка DMARC: начните с p=none, затем ужесточайте

DMARC — это запись TXT на _dmarc в вашем домене. Начните с режима мониторинга, в котором получателей просят не менять обработку вашей почты, и запросите агрегированные отчёты:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Агрегированные отчёты — это машиночитаемые сводки о том, какие IP-адреса отправляли почту от имени вашего домена и проходила ли она проверку; Google советует завести для них отдельный ящик или группу. Когда отчёты покажут, что все легитимные источники проходят проверку с выравниванием, ужесточите политику, отредактировав ту же запись, а не добавляя вторую:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Тег	Значение
`v=DMARC1`	Обязателен и должен стоять первым
`p=`	`none` (без действий), `quarantine` (считать подозрительным, например помещать в папку «Спам») или `reject`
`sp=`	Политика для поддоменов; если тег отсутствует, поддомены наследуют `p=`
`rua=`	Куда отправлять агрегированные отчёты; без него отчётов не будет
`adkim=` / `aspf=`	Режим выравнивания для DKIM и SPF: `r` — мягкий (relaxed, по умолчанию) или `s` — строгий (strict)

Выравнивание простыми словами

Чтобы пройти DMARC, хотя бы один из механизмов, SPF или DKIM, должен пройти для домена, совпадающего с доменом From. В мягком режиме должны совпадать организационные домены, поэтому подпись DKIM с d=example.com выровнена с почтой от alerts@news.example.com. Строгий режим требует точного совпадения. Почтовые сервисы часто используют в Return-Path свой домен, поэтому SPF не будет выровнен, даже если проходит; выровненный DKIM — практичный способ провести такие письма через DMARC.

Если для поддоменов нужна другая политика, добавьте sp=. Например, p=reject; sp=quarantine отклоняет непрошедшие письма с основного домена, а для поддоменов лишь помещает их в карантин.

Об обновлённом стандарте

В мае 2026 года DMARC был переиздан как RFC 9989, который заменяет RFC 7489. Существующие записи продолжают работать и по-прежнему начинаются с v=DMARC1. В новом стандарте убран тег pct, который редко применялся точно, кроме значений 0 и 100, и добавлены такие теги, как t=y (тестовый режим) и np (политика для несуществующих поддоменов). На некоторых справочных страницах провайдеров pct всё ещё встречается, поэтому наименее двусмысленный способ постепенно ввести применение политики — последовательно менять значения p=.

Обратная запись DNS (PTR) для IP-адреса отправки

Обратная зона DNS сопоставляет IP-адресу имя хоста. Google требует, чтобы у всех, кто отправляет почту на личные аккаунты Gmail, была запись PTR, имя хоста в которой разрешается обратно в тот же IP-адрес отправки, а Yahoo требует корректных прямых и обратных записей DNS для IP-адресов отправки и рекомендует осмысленную, не шаблонную запись PTR.

203.0.113.10       PTR  mail.example.com.
mail.example.com.  A    203.0.113.10

Запись PTR находится не в зоне вашего домена. Ею управляет владелец IP-адреса, поэтому на VPS её задают в панели управления провайдера (часто раздел называется «обратный DNS» или rDNS), а затем создают соответствующую запись A (AAAA для IPv6) в своём DNS. Если вы отправляете почту по IPv6, для адреса IPv6 нужно сделать то же самое. В Google Workspace, Microsoft 365, почтовых сервисах и на большинстве виртуальных хостингов IP-адресами отправки и их обратными записями DNS управляет провайдер.

Как проверить настройку

Изучите Authentication-Results

Отправьте тестовое письмо на внешний почтовый ящик и посмотрите полные заголовки. В Gmail откройте письмо и выберите «Показать оригинал». В справке Google по DKIM отмечено, что письмо следует отправлять другому пользователю, а не себе. Найдите заголовок вида:

Authentication-Results: mx.example.net;
       dkim=pass header.i=@example.com header.s=selector1;
       spf=pass smtp.mailfrom=example.com;
       dmarc=pass header.from=example.com

Точный формат зависит от получателя. Важно, чтобы были spf=pass, dkim=pass и dmarc=pass, а в header.i или header.d и в header.from стоял ваш собственный домен. Если SPF проходит для домена сервиса, а в DKIM указан другой домен, DMARC не пройдёт: сначала исправьте выравнивание DKIM.

Запросите DNS напрямую

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com
dig +short -x 203.0.113.10

В Windows то же самое делает nslookup -type=TXT _dmarc.example.com. Изменения DNS распространяются не сразу; по словам Google, SPF и DKIM могут начать работать в течение 48 часов каждый. Бесплатные онлайн-сервисы проверки тоже умеют разбирать ваши записи и подсчитывать запросы SPF.

Если аутентификация проходит, а письма всё равно возвращаются или попадают в спам, проверьте, не числится ли ваш IP-адрес или домен отправки в DNSBL, с помощью нашей проверки по чёрным спискам, а дальнейшие шаги описаны в статье письма не доходят из-за чёрного списка.

Требования Gmail, Yahoo и Outlook.com к отправителям

Крупные почтовые сервисы теперь требуют аутентификацию. По состоянию на ноябрь 2026 года их официальные страницы сообщают следующее.

Gmail (действует с 1 февраля 2024 года): всем, кто отправляет письма на личные аккаунты Gmail, нужны SPF или DKIM, совпадающие прямая и обратная записи DNS, соединение по TLS и доля спама ниже 0,3% в Postmaster Tools. Отправителям более 5 000 писем в день также нужны и SPF, и DKIM, запись DMARC (p=none допустимо), домен From, выровненный с SPF или DKIM, и отписка в один клик для маркетинговых писем. Ключи DKIM должны быть не короче 1024 бит, рекомендуется 2048.
Yahoo (применение с февраля 2024 года): всем отправителям нужны SPF или DKIM, корректные прямая и обратная записи DNS и доля спама ниже 0,3%. Массовым отправителям нужны и SPF, и DKIM, проходящая проверку политика DMARC не ниже p=none, выравнивание From (мягкого достаточно), работающая отписка в один клик и корректные прямая и обратная записи DNS для IP-адресов отправки.
Outlook.com (потребительский сервис, стоящий за outlook.com, hotmail.com и live.com): домены, отправляющие более 5 000 писем в день, должны проходить SPF и DKIM и публиковать DMARC не ниже p=none с выравниванием по SPF или DKIM. Microsoft сообщала, что с 5 мая 2025 года несоответствующие письма будут отклоняться с ошибкой 550; 5.7.515.

Полный текст читайте в правилах Google для отправителей, рекомендациях Yahoo для отправителей и объявлении Microsoft об Outlook.com. Даже если вы отправляете гораздо меньше писем, настройка всех трёх механизмов уже сейчас означает, что снижение порога в будущем не застанет вас врасплох. Решение проблем, характерных для Gmail, — в статье Gmail не доставляет ваши письма.

Типичные ошибки

Вторая запись SPF. Если для каждого сервиса добавлять новую запись v=spf1, SPF становится недействительным для всего домена. Объедините всё в одну запись.
Слишком много include. Старые сервисы, оставшиеся в SPF, расходуют лимит в 10 запросов. Удалите то, чем больше не пользуетесь, и вынесите массовые рассылки на поддомен.
Ключ опубликован, но подпись не включена. В Google Workspace после того, как запись DNS заработала, всё равно нужно нажать «Начать аутентификацию»; на других платформах есть похожий переключатель.
Сервис подписывает письма своим доменом. И SPF, и DKIM проходят, а DMARC — нет. Включите подпись собственным доменом.
Сразу переходить на p=reject. Забытая веб-форма или система выставления счетов в одночасье перестаёт доставлять почту. Начните с p=none и изучайте отчёты.
Ошибки при копировании. Лишние кавычки внутри значения, обрезанный ключ или имя хоста, которое превращается в _dmarc.example.com.example.com, потому что панель сама дописывает домен. Быстрая проверка через dig выявляет всё это.

Если не хотите разбираться самостоятельно

Мы порекомендуем специалистов, которые возьмут на себя запросы на исключение из списков, консультации и советы (от JPY 50,000). Решение об исключении принимает оператор каждого списка, поэтому результат гарантировать нельзя.

Получить помощь

Этот сайт может получать вознаграждение за рекомендацию от указанных специалистов. About

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

Нужны все три механизма или достаточно одного?

Gmail и Yahoo принимают от отправителей с небольшим объёмом SPF или DKIM, но массовым отправителям нужны все три. Только DMARC защищает адрес From, который действительно видят люди, поэтому настройте все три, даже если отправляете мало писем.

Что использовать в SPF: ~all или -all?

Google рекомендует ~all; Microsoft рекомендует -all для доменов, которые также используют DKIM и DMARC. Начните с ~all, пока отчёты DMARC не подтвердят, что вы нашли всех отправителей, а затем решите, стоит ли переключаться.

Можно ли оставить DMARC на p=none?

Это удовлетворяет требованиям Gmail, Yahoo и Outlook.com к массовым отправителям, но просит получателей ничего не предпринимать, поэтому не останавливает подделку. Считайте p=none этапом мониторинга и переходите на quarantine, а затем на reject, когда отчёты станут чистыми.

Мой DNS-хостинг не принимает ключ DKIM длиной 2048 бит. Что делать?

Разбейте ключ на несколько строк в кавычках в одной записи TXT; получатели склеивают их без пробелов. Уточните ограничения длины TXT в справке вашего DNS-хостинга. Используйте ключ длиной 1024 бита, только если хостинг вообще не может хранить ключ длиной 2048 бит.

Все проверки проходят, но письма всё равно попадают в спам. Почему?

Аутентификация — это входной билет, а не гарантия попадания во «Входящие». Репутация отправителя, доля жалоб и записи в чёрных списках по-прежнему важны. Если вы в списке Spamhaus, прочитайте статью как выйти из чёрного списка Spamhaus.

Использованные официальные страницы

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