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

Я часто настраиваю почту для сайтов на PHP 8.1–8.3, WordPress, Bitrix и Laravel, и в 2026 году связка SPF, DKIM и DMARC — это уже не «дополнительная защита», а базовая гигиена домена. Если её не сделать, письма с формы, уведомления из CRM, счета и транзакционные сообщения начинают улетать в спам или вообще отваливаться на стороне Gmail, Outlook и Яндекса.

Честно говоря, многие до сих пор думают, что достаточно просто подключить SMTP и купить SSL. Но на деле это плохая идея: без корректных DNS-записей домен легко подделывается, а репутация отправителя проседает очень быстро. И потом уже начинается классика — «почему письма не доходят», «почему Gmail ругается на spoofing», «почему у нас падает конверсия из формы заявки».

Что изменилось в 2026 году и почему старые настройки уже не всегда работают

Если вы когда-то настраивали SPF и DKIM лет пять назад, не спешите считать задачу закрытой. В 2026 году почтовые провайдеры стали строже к аутентификации, а требования к репутации домена — выше. У Google и Microsoft заметно сильнее фильтруются письма без DMARC, а некоторые сервисы вообще начинают просить выровненные домены From и Return-Path.

На моей практике был случай с интернет-магазином на WordPress 6.5 и PHP 8.2, где письма с WooCommerce шли через внешний SMTP-сервис, SPF был «примерно настроен», DKIM вроде бы тоже был, а DMARC отсутствовал. В итоге доставка на Gmail была в районе 71–74%, а после нормальной настройки и перевода политики с p=none на p=quarantine через несколько недель показатели выросли до 97%+. Это не магия. Это просто дисциплина DNS.

И ещё один момент. Многие домены в 2026 году используют сразу несколько источников отправки: сайт, CRM, Helpdesk, сервис рассылок, бухгалтерия, уведомления от сервера. Если всё это не описано в SPF и не подписано DKIM, вы сами создаёте хаос. Грубо говоря, почтовый сервер получателя видит не «один домен», а набор подозрительных отправителей.

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

Что такое SPF, DKIM и DMARC простыми словами

SPF — это список серверов и сервисов, которым разрешено отправлять письма от имени вашего домена. Когда письмо приходит на Gmail или Outlook, сервер проверяет, есть ли IP-адрес отправителя в SPF-записи. Если нет — это уже красный флаг.

DKIM — это криптографическая подпись письма. Сервер отправителя подписывает часть заголовков и тело письма приватным ключом, а получатель проверяет подпись публичным ключом, который лежит в DNS. Если письмо по дороге никто не менял, подпись сходится. Если менял — проверка проваливается.

DMARC — это политика поверх SPF и DKIM. Она говорит получателю, что делать, если письмо не прошло проверку: ничего не делать, отправлять в карантин или отклонять. Плюс DMARC умеет присылать отчёты, и вот это очень полезно. По ним видно, кто реально шлёт письма от вашего домена, даже если это забытый сервис или чья-то тестовая рассылка.

Я обычно объясняю клиентам так: SPF — пропускной режим, DKIM — печать на конверте, DMARC — охранник, который решает, пустить письмо внутрь или отправить его в мусор.

Кстати, если вы ещё не выстроили базовую почтовую инфраструктуру, я бы сначала посмотрел статью Настройка почты для сайта: SPF, DKIM, DMARC, а уже потом возвращался к углублённой настройке в 2026-м. И отдельно полезна статья Настройка SMTP для отправки писем с сайта в 2026 году, потому что без SMTP половина этих записей вообще не даст заметного эффекта.

С чего начать: подготовка домена и почты

Перед тем как лезть в DNS, я всегда делаю простую инвентаризацию. Какие письма у вас отправляются? Сайт? CRM? Подписки? Сервис уведомлений? Helpdesk? Сервисы массовых рассылок? Какие домены стоят в From? Где лежит почта: Яндекс 360, Mail.ru для бизнеса, Google Workspace, Microsoft 365, Zoho, Mailgun, SendGrid, UniSender, SendPulse?

Именно на этом этапе всплывает половина проблем. У одного клиента на Bitrix были письма с сайта, письма из 1C-Битрикс: Управление сайтом, уведомления из CRM и отдельный сервис рассылок. И все они использовали разные адреса отправителя, а часть шла через один SMTP, часть — через PHP mail(). Разумеется, репутация летела в разные стороны.

По опыту, лучше сразу решить: у домена будет один основной путь отправки или несколько. Если несколько, нужно чётко понимать, какие IP и сервисы вы включаете в SPF, какие селекторы DKIM используете, и какая политика DMARC вам нужна на старте. Для большинства компаний я начинаю с p=none, чтобы собрать отчёты, а потом уже двигаюсь к quarantine или reject.

Если у вас сайт работает на WordPress, Bitrix или Laravel, и вы хотите нормально увязать почту с CMS, я советую не делать это «на коленке». В ряде проектов мы начинали с быстрой доработки через доработать под задачу, а потом уже докручивали отправку почты, логи и отчёты. Это дешевле, чем потом разгребать потерянные лиды.

И ещё момент: проверьте, кто управляет DNS. Если у регистратора, хостинга и почтового сервиса разные панели, можно легко наделать дубликатов или потерять часть записей. Я один раз видел домен, где TXT-записи SPF были добавлены сразу в двух местах, и в итоге почтовый сервер получателя видел только одну из них. Итог — случайные отказы и странные результаты в отчётах DMARC.

Как правильно настроить SPF в 2026 году

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

example.com.  IN  TXT  "v=spf1 ip4:203.0.113.10 include:_spf.yandex.net include:spf.mailgun.org -all"

Тут всё довольно просто. IP-адрес 203.0.113.10 — ваш сервер. include:_spf.yandex.net — если почта идёт через Яндекс 360. include:spf.mailgun.org — если используете Mailgun для транзакционных писем. -all в конце говорит: всё, что не перечислено, не имеет права отправлять письма.

Но вот здесь и начинается типичная ошибка. SPF имеет ограничение на количество DNS-запросов. Если вы подключите WordPress-плагин, CRM, сервис рассылок, helpdesk, help center, биллинг и ещё три внешних сервиса, запись может превысить лимит. Тогда SPF начинает возвращать permerror, и это уже почти гарантированная проблема с доставкой.

Я обычно рекомендую сначала выписать все отправители, а потом оптимизировать. Иногда лучше использовать ip4 и ip6 для своих серверов, чем тащить лишние include. Иногда проще перевести часть сервисов на один единый отправитель. И да, SPF не должен содержать два разных TXT со строками v=spf1. Нужна одна запись.

Если у вас сервер на Nginx и письма уходят с собственного VPS под Ubuntu 22.04 или 24.04, а почтовый сервер — внешний, полезно проверить, какой IP реально смотрит в интернет. Иначе вы пропишете один адрес, а отправлять будет другой. В моих проектах такое особенно часто всплывало после миграции хостинга. Кстати, про это хорошо дополняет статья Миграция сайта на новый хостинг без потери данных.

Проверять SPF я обычно начинаю через команду dig:

dig TXT example.com +short

Если запись есть, смотрю, нет ли дублирования, лишних include и странных символов. В 2026 году я бы ещё проверял всё через инструменты постмастеров Gmail, Microsoft SNDS и отчёты DMARC-провайдера. Просто TXT-записи уже недостаточно — нужны реальные данные по доставке.

Как настроить DKIM-подписи для домена

DKIM обычно настраивается чуть сложнее, чем SPF, но именно он часто спасает доставку. Идея в том, что ваш почтовый сервер генерирует пару ключей: приватный остаётся на стороне отправителя, публичный кладётся в DNS. Затем каждое письмо подписывается приватным ключом. Получатель проверяет подпись по публичному ключу.

Если вы используете Google Workspace, Microsoft 365, Яндекс 360, Mailgun, SendGrid или другой почтовый сервис, селектор и TXT-запись вам обычно выдадут в панели. Но если у вас сервер свой, например Postfix с OpenDKIM, настройка идёт руками. На VPS с Debian 12 и PHP здесь вообще нет ничего страшного, если не делать всё без логики.

Один из типовых вариантов записи выглядит так:

default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

Здесь default — селектор. Он может называться как угодно: mail, s1, s2026, tx. Я обычно советую использовать осмысленные селекторы, особенно если у вас ротация ключей. Когда через год нужно будет обновить ключи, вы сами себе скажете спасибо.

На деле DKIM полезен не только для самой подписи. Он помогает выровнять домен. То есть письмо должно быть подписано тем же доменом, который указан в From. Иначе DMARC может посчитать письмо подозрительным, даже если SPF формально проходит.

Если у вас WordPress, обязательно посмотрите связку SMTP + DKIM в плагинах типа WP Mail SMTP, FluentSMTP или Post SMTP. Для Bitrix я чаще смотрю на штатные механизмы и серверную часть. В проектах на Laravel удобно завязывать отправку через Laravel Mail на внешнего провайдера с корректным DKIM. Это особенно полезно, если у вас очереди задач и массовые уведомления. Заодно рекомендую статью Настройка API интеграций на сайте: пошаговое руководство 2026, потому что почта и API очень часто живут рядом.

И ещё. Если вы настраиваете свой почтовый сервер, проверьте права на ключи и ротацию. На Linux я обычно держу приватный ключ вне webroot, с правами 600 и владельцем службы почтового агента. Забытый приватный ключ в публичной папке — это уже катастрофа. Тут без шуток.

Как настроить DMARC и выбрать политику

DMARC — это не просто «ещё одна TXT-запись». Это ваша стратегия контроля почты. Запись обычно лежит на поддомене _dmarc и содержит политику обработки писем, которые не прошли SPF/DKIM, плюс адреса для отчётов.

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; adkim=s; aspf=s; pct=100"

Начинать почти всегда стоит с p=none. Это режим наблюдения. Письма не блокируются, но вы получаете отчёты и видите, кто отправляет почту от вашего домена. Для новых или сложных доменов это однозначно лучший старт. Сразу ставить reject — это плохая идея, если у вас не собрана вся инфраструктура.

После нескольких недель отчётов можно переходить к p=quarantine, а затем к p=reject. Но не торопитесь. Если у вас в отчётах всплывает старый сервис рассылок, сторонний helpdesk или забытый плагин на сайте, сначала исправляете источник, потом ужесточаете политику. Иначе начнутся потери писем, а потом — скандалы.

Агрегированные отчёты DMARC — штука скучная, но полезная. Они покажут IP, домены отправителей, результаты SPF/DKIM и частоту. Я обычно советую хотя бы раз в месяц смотреть на них вручную. Да, можно подключить внешний сервис визуализации, но даже обычный XML-поток уже даёт много пользы.

Если у вас есть корпоративная почта на домене, и вы только выстраиваете её с нуля, хорошо зайдёт статья Корпоративная почта на домене: настройка с нуля 2026. Там я обычно связываю MX, SPF, DKIM, DMARC и SSL для почты в одну картину. Кстати, SSL для почты тоже важен — об этом отдельно есть материал Как настроить SSL для почты домена в 2026 году.

Типичные ошибки и как я их исправляю

Самая частая ошибка — несколько SPF-записей на одном домене. Я такое видел и на WordPress, и на Битриксе, и в корпоративных доменах на Microsoft 365. Люди добавляют TXT-запись в панели хостинга, потом ещё одну у регистратора, потом ещё одну через сервис почты. Получается каша.

Вторая частая проблема — DKIM есть, но письмо уходит не тем доменом. Например, From выглядит как support@example.com, а подпись идёт от mail.example.net. Формально письмо может пройти часть проверок, но DMARC уже смотрит на alignment. И вот тут начинаются отклонения или карантин.

Третья проблема — слишком ранний reject в DMARC. Да, хочется «сразу по-взрослому», но если у вас ещё живут старые интеграции и внешние сервисы, вы сами себе обрежете доставку. Я обычно трачу день на аудит источников отправки, а потом уже включаю жёсткую политику.

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

И ещё момент по старым сайтам. На хостинге с PHP 8.1 иногда можно встретить код, который шлёт письма через mail() и вообще не знает про SMTP. Это пережиток. Я обычно советую переводить отправку на нормальный SMTP или API-сервис. Для WordPress это WP Mail SMTP или FluentSMTP, для Bitrix — настройка через SMTP-модуль, для Laravel — через Mailer. Без этого в 2026 году уже грубо говоря нечего делать.

Проверка и мониторинг после настройки

После того как SPF, DKIM и DMARC записаны в DNS, я никогда не считаю работу законченной. Нужно проверить реальную доставку. Причём не один раз, а через несколько каналов: Gmail, Outlook, Яндекс Почту, Mail.ru и корпоративные ящики. В идеале отправить письмо на разные адреса и посмотреть заголовки.

Я обычно проверяю такие строки: SPF=pass, DKIM=pass, DMARC=pass. Если хотя бы одна проверка падает, надо разбираться. Иногда проблема не в DNS, а в том, что письмо переупаковывает сторонний сервис. Иногда виноват неверный Return-Path. Иногда ломается подпись из-за вставки трекеров или сторонних скриптов, если речь идёт о массовой рассылке.

Хороший минимум мониторинга — это отчёты DMARC, логирование отправки и проверка ошибок на почтовом уровне. На стороне сервера полезно смотреть mail.log, syslog и логи MTA. Если у вас Nginx, PHP-FPM и отдельный SMTP, то ещё и смотреть, что именно отправляет письмо: сайт, cron или внешний воркер. Это особенно актуально для Laravel-проектов с очередями.

grep -i "dkim\|spf\|dmarc\|fail" /var/log/mail.log | tail -n 50

Если почта отправляется через API провайдера, полезно сохранить ID сообщения и потом сопоставить его с отчётами доставки. Я это делаю почти в каждом проекте, где есть критичные письма: восстановление доступа, подтверждение оплаты, юридические уведомления. В таких сценариях уже не шутки, и на кону реальные деньги.

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

Практические сценарии для WordPress, Bitrix и Laravel

На WordPress я обычно начинаю с SMTP-плагина, затем настраиваю SPF под конкретного провайдера и подключаю DKIM через панель почтового сервиса. Если сайт на WooCommerce, обязательно тестирую письма заказов, сброс пароля, уведомления администратору и письма шаблонов. Иначе можно получить красивую DNS-настройку, которая не спасает реальную бизнес-логику.

В Bitrix я чаще сталкиваюсь с большими корпоративными доменами, где почта сидит в Яндексе или Microsoft 365, а сайт отправляет транзакционные письма с отдельного SMTP. Там особенно полезно разнести роли: один домен для корпоративной почты, другой для массовых уведомлений, третий — для маркетинговых рассылок. Это снижает риск, что одна проблема потянет за собой всё.

В Laravel, особенно на проектах с очередями и уведомлениями, я настраиваю единый mailer, логирование и fallback-сценарии. Если письмо критичное, лучше иметь запись в базе и повторную отправку, чем молча терять его. На больших проектах с MySQL 8.0 это вообще must-have. Плюс я люблю хранить метаданные отправки, чтобы потом понимать, где письмо застряло.

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

Чек-лист готовых записей и финальная проверка

Я обычно делаю финальный чек-лист по шагам. Сначала проверяю, есть ли один корректный SPF. Потом — что DKIM-подпись реально проходит. Затем — что DMARC стоит хотя бы в режиме наблюдения и собирает отчёты. После этого отправляю тестовые письма и смотрю заголовки в Gmail и Outlook.

Если всё прошло, перевожу домен на рабочий режим. Для спокойного бизнеса это часто p=quarantine на некоторое время, а потом p=reject. Для проектов с высокой ценностью письма — авторизация, платежи, юридически значимые уведомления — reject уже вполне оправдан. Но только после того, как вы точно уверены, что всё остальное не ломается.

И ещё один совет из практики: документируйте всё. Какие IP разрешены в SPF, какие селекторы DKIM используются, где лежат ключи, кто отвечает за отчёты DMARC, когда менялся SMTP-провайдер. Через полгода это сэкономит часы, а иногда и дни. На поддержке сайтов я это вижу постоянно. Когда документации нет, любой инцидент превращается в квест.

Если в процессе настройки выясняется, что у вас вообще не выстроена почта, формы шлют через PHP mail(), а домен живёт без нормальной проверки, я бы не тянул. Сначала базовая настройка почты для сайта, потом SPF/DKIM/DMARC, потом мониторинг и уже после этого можно говорить, что почтовая часть действительно работает как надо.

На моей практике хорошая почта — это не «галочка в DNS», а живая система. И если сделать её нормально в 2026 году, письма доходят стабильно, заявки не теряются, а домен не выглядит подозрительным для почтовых фильтров. Вот это и есть нормальный результат.