SPF, DKIM и DMARC на сервере: частые ошибки и решения

MAATRIX

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

DKIM не проходит из-за переносов строк

Самая частая ошибка: проверка показывает dkim=fail или dkim=none, хотя подпись настроена. В подавляющем большинстве случаев виноват публичный ключ в DNS — при вставке длинной строки в панель DNS-провайдера в неё попали переносы строк, лишние пробелы или ключ разбился неправильно. DKIM-запись должна собираться в одно точное значение. Проверьте, что видит мир:

dig TXT mail._domainkey.вашдомен.ru +short

Сравните вывод с содержимым сгенерированного файла ключа на сервере — они должны совпадать символ в символ (без учёта разбиения на кавычки, которое DNS склеивает). Если ключ длинный (2048 бит), некоторые DNS-панели требуют разбить его на части в кавычках — это нормально, DNS склеит их обратно. Вторая причина fail — неверный селектор: имя записи селектор._domainkey должно совпадать с селектором, которым подписывает сервер. Третья — запись только что добавлена и DNS ещё не распространился, подождите. После правки проверьте отправкой тестового письма.

Две SPF-записи ломают проверку

Письма стали помечаться подозрительными, SPF показывает permerror. Частая причина — в домене оказалось две TXT-записи, начинающиеся с v=spf1. По стандарту SPF-запись должна быть ровно одна; две записи делают проверку недействительной. Это происходит, когда добавляют новый сервис (например, рассылку), создавая отдельную SPF-запись вместо дополнения существующей.

Решение — объединить всё в одну запись. Не создавайте вторую строку v=spf1, а добавьте нужные источники в имеющуюся:

вашдомен.ru.  TXT  "v=spf1 a mx ip4:ВАШ_IP include:sender-service.com -all"

Все механизмы (ip4, include, a, mx) перечисляются в единственной SPF-записи через пробел, а -all идёт последним. Проверьте, что в домене нет второй записи с v=spf1, и удалите лишнюю. Это одна из самых частых и незаметных ошибок при подключении новых почтовых сервисов к домену.

Превышен лимит 10 DNS-запросов SPF

SPF показывает permerror, хотя запись одна и выглядит правильно. Причина — превышен жёсткий лимит стандарта: SPF-запись при проверке не должна порождать более 10 DNS-запросов. Каждый механизм include, a, mx внутри записи стоит запросов, а include чужих сервисов часто тянет за собой ещё свои вложенные include. Несколько подключённых сервисов легко выбивают лимит, и запись целиком становится недействительной.

Решение — сократить число запросов. Уберите неиспользуемые include, замените там, где возможно, include на прямые ip4-адреса (они не стоят запросов), и не держите в SPF источники, которые давно не шлют вашу почту. Существуют техники «плоского» SPF (flattening), разворачивающие include в список IP, но за ними нужно следить, потому что IP сервисов меняются. Главное правило — держать SPF-запись компактной и регулярно чистить от лишних источников.

DMARC или SPF падает при пересылке письма

Письма проходят проверки при прямой отправке, но получатели, которым письмо переслали (форвардинг), видят spf=fail или dmarc=fail. Это не ошибка вашей настройки, а фундаментальное свойство: при пересылке письмо отправляется с сервера пересылающего, а не с вашего, поэтому SPF по вашему домену не проходит — IP уже чужой. Вот почему DMARC полагается не только на SPF, но и на DKIM.

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

Слишком жёсткая политика режет свою почту

Настроили p=reject в DMARC, и часть собственных легитимных писем перестала доходить. Классическая ошибка спешки: строгую политику включили до того, как убедились, что вся легитимная почта проходит SPF и DKIM. Какой-то источник (сторонний сервис рассылок, скрипт на другом сервере, забытая интеграция) шлёт письма от вашего домена, но не проходит проверки — и p=reject их убивает.

Решение — вернуться к мониторингу. Смените политику на p=none, соберите DMARC-отчёты (адрес в rua=) и посмотрите, какие источники отправляют вашу почту и где не проходят проверки. Добавьте легитимные источники в SPF, настройте для них DKIM, и только когда отчёты покажут, что всё чисто, поэтапно ужесточайте политику снова: none → quarantine → reject. DMARC-отчёты — ваш главный инструмент: они показывают реальную картину отправки от домена, которую иначе не увидеть. Спешка с p=reject без анализа отчётов — частая причина внезапной потери писем.

Проверка и профилактика

Большинство ошибок ловятся до того, как навредят, если проверять записи после каждого изменения. Отправляйте тестовое письмо на сервис оценки (mail-tester), смотрите в исходниках писем строки spf=pass, dkim=pass, dmarc=pass, проверяйте записи через dig. И помните: эти три записи работают поверх базовой репутации, а её фундамент — чистый IP и корректный PTR от провайдера. В MAATRIX можно арендовать VPS под почтовый сервер с чистым IP и настройкой PTR в России, США или Великобритании и оплатить картой РФ, по СБП, криптой или токеном MAAT — иностранная карта не требуется.

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