Зачем вообще разбираться в SPF/DKIM/DMARC, если «почта и так отправляется»
Проблемы с доставляемостью редко выглядят как одна «фатальная» ошибка. Чаще это цепочка мелочей: домен настроен частично, подпись DKIM то есть, то нет, SPF «раздувается» из include, rDNS не совпадает, а в логах видны мягкие отказы (temporary) и постепенное падение репутации. В итоге часть писем уходит в spam, часть — в отказы, а часть принимается, но режется фильтрами по контенту.
SPF, DKIM и DMARC — это три уровня проверки подлинности:
- SPF отвечает на вопрос «имел ли этот сервер право отправлять письма от имени домена в envelope-from (MAIL FROM)».
- DKIM отвечает на вопрос «не изменилось ли письмо по пути и действительно ли его подписал владелец домена (d=...)».
- DMARC задаёт политику: что делать, если SPF и/или DKIM не прошли, и требует alignment — согласованности доменов между From и SPF/DKIM.
Если вы админ/девопс и вам нужно быстро понять, почему конкретное письмо не дошло, то «истина» почти всегда лежит в двух местах: заголовки письма (message headers) и логи MTA (SMTP logs). Ниже — практический разбор, который можно применять в инциденте.
Базовая терминология: что именно сравнивают SPF, DKIM и DMARC
Два «отправителя»: From и MAIL FROM (Return-Path)
В письме есть видимый заголовок From: и есть SMTP-адрес в конверте: MAIL FROM (часто попадает в доставленное письмо как Return-Path). SPF почти всегда проверяется по MAIL FROM (или по HELO, если MAIL FROM пустой), а DMARC — по домену в From:.
Типичная ситуация: SPF=pass (для bounce-домена сервиса рассылки), DKIM=pass (подписано сервисом рассылки), но DMARC=fail, потому что домен в From: не совпал ни со SPF-доменом, ни с DKIM d=.
Alignment в DMARC: что должно «совпасть»
DMARC считает письмо «аутентифицированным», если выполняется хотя бы одно условие:
- SPF=pass и домен MAIL FROM aligned с доменом в
From:. - DKIM=pass и домен DKIM
d=aligned с доменом вFrom:.
Под alignment понимают совпадение домена либо строго (strict), либо по организационному домену (relaxed). Например, mailer.example.com и example.com в relaxed-режиме считаются aligned.
Если вы только переносите сайт/CRM на новую инфраструктуру и параллельно настраиваете исходящую почту, удобнее делать это на предсказуемой платформе: VDS даёт полный контроль над hostname, MTA и сетевыми настройками (PTR обычно настраивается через провайдера).
Как быстро проверить письмо по заголовкам: что искать в message headers
Самое полезное в заголовках — это строки, которые добавляет принимающая сторона. Обычно там есть Authentication-Results:, иногда Received-SPF:, а при форвардинге — заголовки ARC.
Authentication-Results: «карта местности» по аутентификации
Типичный пример (формат зависит от провайдера):
Authentication-Results: mx.receiver.tld;
spf=pass (sender SPF authorized) smtp.mailfrom=mail.example.com;
dkim=pass header.d=example.com header.s=selector1;
dmarc=pass (p=none) header.from=example.com
Что важно смотреть в первую очередь:
- spf=pass/fail/softfail/neutral/none/permerror и домен после
smtp.mailfrom=. - dkim=pass/fail/none и домен после
header.d=, а также селекторheader.s=. - dmarc=pass/fail и домен после
header.from=(это домен, который пользователь видит в From).
Если вы видите spf=pass и dkim=pass, но dmarc=fail — в 90% случаев это alignment: домены «живут своей жизнью».
Received-SPF: почему он полезен, но не всегда главный
Некоторые системы добавляют отдельный заголовок:
Received-SPF: pass (mx.receiver.tld: domain of bounce.example.com designates 203.0.113.10 as permitted sender) client-ip=203.0.113.10;
Это удобно для детализации (какой IP проверяли, какой домен взяли), но если есть Authentication-Results, ориентируйтесь на него как на агрегированный результат.
ARC: когда письма пересылаются и ломают SPF/DKIM
Форвардинг (пересылка через другие системы, helpdesk, CRM, списки рассылки) часто меняет письмо: добавляет футеры, перекодирует MIME, «перепаковывает» вложения. DKIM может сломаться, SPF почти всегда ломается (ведь отправляет уже другой сервер). Для таких случаев существует ARC (Authenticated Received Chain): принимающая сторона может учесть, что исходная аутентификация была хорошей до пересылки.
ARC обычно выглядит как набор заголовков:
ARC-Seal: i=1; a=rsa-sha256; d=forwarder.tld; s=arc; cv=none; ...
ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.tld; s=arc; ...
ARC-Authentication-Results: i=1; mx.forwarder.tld; spf=pass ...; dkim=pass ...; dmarc=pass ...
Если жалоба звучит как «письма не доходят только при пересылке» — это повод разбирать ARC и схему доставки. Отдельно полезно иметь под рукой материал: как ARC помогает при пересылке и почему ломаются SPF/DKIM.
SPF на практике: типовые ошибки, которые реально бьют по доставляемости
Слишком много include и лимит 10 DNS-запросов
SPF-проверка ограничена 10 DNS-lookup (сюда входят include, a, mx, ptr, exists). Когда лимит превышен, результат часто становится permerror. Это не «мелочь»: permerror легко превращается в spam/отказы на стороне крупных провайдеров.
Смотрите в заголовках: некоторые провайдеры прямо пишут spf=permerror или «too many DNS lookups».
Неправильное завершение политики: ~all vs -all
~all (softfail) часто используют на этапе внедрения: «мы не уверены, что перечислили все источники». -all (fail) — строгий режим. Для стабильной репутации обычно лучше прийти к -all, но только после инвентаризации всех отправителей (сайт, CRM, мониторинг, формы, helpdesk, транзакционные сервисы).
SPF и поддомены
SPF не «наследуется» автоматически туда, куда вы ожидаете. Если письма уходят с bounce.mail.example.com, проверьте SPF именно для этого домена, а не только для example.com.
DKIM: подпись, селекторы и «плавающие» проблемы
Ротация селекторов и ошибки DNS
Типичный кейс: вы включили второй селектор, часть потоков подписывает s=selector2, но DNS-запись для него не добавили (или добавили не в ту зону). В заголовках это видно сразу: dkim=fail (no key for signature) и рядом header.s=selector2.
Если вы регулярно меняете ключи, полезно отдельно выстроить процесс ротации и TTL: как планировать ротацию DKIM (селекторы и TTL) без потерь.
DKIM ломается из-за изменений письма по пути
Если подпись есть, ключ найден, но dkim=fail (bad signature) — письмо изменилось после подписи. Частые причины:
- промежуточный шлюз добавляет или переписывает заголовки;
- сервис добавляет трекинг после подписи;
- антивирус/антиспам «лечит» вложения и меняет MIME;
- форвардер добавляет футер.
Решение обычно организационное: подписывать на последнем узле, где письмо становится «финальным», или менять цепочку (и учитывать ARC там, где уместно).
DMARC: политика, отчёты и как не «сломать» рассылки
p=none, quarantine, reject: безопасный переход
DMARC — это не только защита от подмены, но и инструмент управления доставкой. На практике переход делают ступенчато:
- Включают
p=noneи собирают картину по источникам. - Наводят порядок с alignment (SPF/DKIM) у всех отправителей.
- Переводят на
p=quarantineс небольшой долей черезpct=и наблюдают. - Дальше —
p=reject, если домен зрелый и источники под контролем.
DMARC не «лечит» репутацию сам по себе. Он помогает провайдерам доверять вашим письмам и защищает домен от подделок, но гигиена отправки, жалобы пользователей, качество базы и контент по-прежнему влияют на доставку.
Почему DMARC может падать при pass SPF и pass DKIM
Потому что pass не равно aligned. Проверьте в Authentication-Results три домена: smtp.mailfrom=, header.d=, header.from=. Если header.from — ваш домен, а остальные — домен внешнего сервиса, то без настройки «под ваш домен» (кастомный bounce-домен, кастомный DKIM) DMARC будет fail.
PTR rDNS, HELO и FCrDNS: что видят принимающие серверы на SMTP-уровне
Даже при идеальных SPF/DKIM/DMARC можно получить проблемы, если базовая SMTP-идентичность сервера выглядит подозрительно. Особенно это заметно на «голых» серверах, где вы поднимаете MTA сами.
PTR rDNS и соответствие IP ↔ имя
PTR rDNS — обратная DNS-запись для IP. Многие провайдеры смотрят на неё как на сигнал «сервер управляемый и не одноразовый».
Базовый минимум:
- на IP исходящего SMTP должен быть PTR (не пустой);
- PTR должен указывать на имя хоста, которое вы используете в HELO/EHLO;
- желательно, чтобы прямое A/AAAA этого имени указывало обратно на тот же IP (FCrDNS).
Если вы отправляете почту с собственной инфраструктуры, удобнее всего настраивать rDNS и hostname заранее на VDS, чтобы не упираться в «PTR missing» и «bad HELO» на старте прогрева.
HELO/EHLO и почему localhost — плохая идея
При соединении SMTP клиент представляется: EHLO mail.example.com. Если там localhost, mail без домена или несуществующее имя — это повышает вероятность фильтрации.
Как читать SMTP logs: где искать причину, когда письмо не дошло
Заголовки помогают понять, как письмо оценил получатель. Но если письмо не дошло вообще (или не вышло с вашего сервера), ваш источник правды — SMTP-логи MTA.
Ниже — что искать независимо от того, Postfix у вас, Exim или другой MTA: логика одинакова.
Связываем события по queue-id
Практический приём: найдите идентификатор очереди (queue-id) и смотрите всю цепочку: приём письма, постановку в очередь, попытки доставки, ответы удалённого сервера, финальный статус. У Postfix это обычно строка вида ABC123DEF456.
Коды ответов и bounce codes: 4xx vs 5xx
- 4xx — временная проблема (defer): серый список, перегрузка, временная блокировка, «try again later». Часто это про репутацию, объёмы и паттерны отправки.
- 5xx — постоянная ошибка (bounce): неправильный адрес, политика отклонения, жёсткая блокировка, DMARC reject на стороне получателя.
Не пытайтесь «угадать» причину по одному коду: читайте текст после него. Там часто прямо написано: «SPF fail», «DKIM missing», «PTR missing», «policy rejection», «rate limit», «message rejected as spam».
Типовые формулировки, которые стоит уметь распознавать
Примеры (формат и текст могут отличаться):
451 4.7.1 Try again later, rate limited
550 5.7.1 Message rejected due to spam content
550 5.7.26 Unauthenticated email from example.com is not accepted due to domain's DMARC policy
554 5.7.1 Service unavailable; Client host blocked
Здесь видно: где проблема репутационная/объёмная (rate limit), где контентная (spam content), где политика домена (DMARC reject), где блок по IP/хосту.
Чеклист диагностики: от симптома к конкретной правке
Симптом: письма уходят в spam, но доставляются
- Проверьте
Authentication-Results: есть ли стабильныйdmarc=passи alignment. - Посмотрите, нет ли
spf=permerrorиз-за 10 DNS lookups. - Проверьте PTR rDNS и HELO/EHLO на адекватность.
- Оцените частоту/объём: в логах будут 4xx rate limit, если вы «рванули» отправку.
- Проверьте стабильность домена и адреса в
From:: частая смена From ухудшает репутационные сигналы.
Симптом: часть писем отваливается, часть проходит
- Проверьте, одинаково ли подписываются письма (селектор DKIM, домен
d=). - Проверьте несколько получателей: разные провайдеры по-разному трактуют
softfail/neutral. - Ищите в логах, не идёт ли часть трафика через другой исходящий IP (другая репутация, другой PTR).
Симптом: письма не доходят при пересылке
- Смотрите ARC-заголовки (
ARC-Authentication-ResultsиARC-Seal). - Проверьте, ломается ли DKIM (
bad signature) из-за модификаций. - Если у вас есть форвардер, оцените сценарии сохранения SPF (например, SRS) и совместимость с вашей цепочкой.
Практика: как собрать доказательства для провайдера/антиспама и быстро закрыть инцидент
Когда на стороне бизнеса «горит», важно не просто «покрутить DNS», а собрать диагностический пакет, чтобы решение было быстрым и воспроизводимым:
- полные message headers проблемного письма;
- время отправки и адрес получателя;
- queue-id и фрагмент SMTP logs по нему;
- текущий SPF/DKIM/DMARC (TXT-записи) и какой именно источник отправляет;
- IP исходящего SMTP, его PTR rDNS и строка HELO/EHLO.
С таким набором вы быстро поймёте, это «политика/аутентификация», «репутация/лимиты», «контент» или «маршрутизация/инфраструктура».
Частые ошибки внедрения SPF/DKIM/DMARC (и почему они всплывают именно в проде)
Письма отправляются не тем доменом, который вы ожидаете
Маркетинг подключил сервис, который технически шлёт с something.provider.tld, а в From оставили ваш домен. Без кастомного DKIM и bounce-домена DMARC может не сойтись.
«Один TXT на всё»
SPF должен быть один на домен. Попытка сделать «несколько SPF TXT» приводит к ошибкам интерпретации (часто permerror), а последствия видны как падение доставляемости.
Слишком ранний переход на p=reject
Если вы включили p=reject, но забыли про один из источников (например, уведомления с сайта или тикет-система), получатели начнут возвращать жёсткие отказы. В логах это часто выглядит как 550/554 с упоминанием DMARC policy.
Вывод: что сделать прямо сейчас
- Возьмите 2–3 проблемных письма, снимите полные заголовки и найдите
Authentication-Results. - Проверьте alignment: сравните
smtp.mailfrom,header.d,header.from. - Сверьте SMTP-идентичность: PTR rDNS, FCrDNS, HELO/EHLO.
- По SMTP logs найдите реальные ответы удалённых серверов и классифицируйте их по 4xx/5xx (bounce codes).
- Только после этого правьте DNS/подписи/маршруты, чтобы изменения были измеримыми.
Так вы перестанете «перебирать настройки» и начнёте работать от фактов, которые уже есть в заголовках и логах.
