SPF, DKIM и DMARC: почему зелёных галочек мало

Аутентификация почты: почему настроенных SPF, DKIM и DMARC всё равно недостаточно

Вы всё сделали как положено. Потратили часы на DNS, копируя непонятные текстовые строки из сервисов рассылки. Запустили проверку. Везде увидели зелёные галочки. Почему же открываемость падает? Почему транзакционные письма, например сбросы пароля, счета и уведомления, попадают в спам или вовсе исчезают?

Вот неприятная правда об аутентификации почты с помощью SPF, DKIM и DMARC: корректная настройка ещё не означает хорошую репутацию. Действительное удостоверение личности не поможет пьяному пройти мимо охраны. С февраля 2024 года такие провайдеры, как Google, Yahoo и Microsoft, стали оценивать не только вероятность спама, но и точность соблюдения протоколов. Если панель показывает зелёный свет, а выручка подаёт тревожные сигналы, вероятно, вы столкнулись с одним из скрытых барьеров за пределами базовых аббревиатур.

Ловушка массового отправителя: порог ниже, чем кажется

Самое опасное заблуждение звучит так: «Я отправляю меньше 5,000 писем в день, поэтому требования для массовых отправителей меня не касаются».

Это неверно сразу по двум причинам, и даже безупречная настройка SPF, DKIM и DMARC от этой ловушки не защитит. Во-первых, Google может учитывать объём на уровне основного домена. Если вы отправляете 2,000 маркетинговых писем с news.example.com, 2,000 транзакционных писем с app.example.com и 1,500 внутренних уведомлений с corp.example.com, вы считаетесь массовым отправителем. Объёмы поддоменов суммируются на уровне корневого домена.

Во-вторых, действует принцип достигнутого максимума. Если хотя бы один раз перейти порог в 5,000 писем, например во время рассылки в Чёрную пятницу или разового обновления базы, Google может навсегда отнести домен к массовым отправителям. Даже если затем объём снизится до 50 писем в день, к домену продолжат применять наиболее строгие требования. Актуальные правила всегда следует сверять в документации провайдера.

Microsoft учитывает и другие факторы. Записи SPF, DKIM и DMARC могут быть безупречными, но возраст IP-адреса и характер отправки тоже имеют значение. Если сразу отправить 2,000 писем с нового домена и нового IP, Microsoft может ограничить поток ответами 4xx независимо от результата SPF. Для провайдера это ещё неизвестный отправитель, а значит, доверие придётся наращивать постепенно.

Почему SPF, DKIM и DMARC не срабатывают: три взаимосвязанные причины

Многие настраивают SPF, DKIM и DMARC, проверяют синтаксис и больше к теме не возвращаются. Но правильный синтаксис ещё не гарантирует правильную работу. Ниже перечислены основные точки отказа.

SPF: чёрная дыра при пересылке

SPF представляет собой список разрешённых IP-адресов. По сути, запись сообщает: «IP 1.2.3.4 разрешено отправлять почту от имени example.com». Всё работает, пока пользователь не включает автоматическую пересылку.

Вы отправляете счёт на client@smallbiz.com, а клиент пересылает всю почту на client@gmail.com. Gmail видит соединение с IP-адреса smallbiz.com, а не с вашего. Этого адреса нет в вашей записи SPF, поэтому проверка завершается неудачно. Если полагаться только на SPF, пересланное письмо может попасть в спам или быть отклонено. Чтобы пережить пересылку, подпись DKIM обязана оставаться действительной, хотя сама по себе она не гарантирует доставку во входящие. Подробности настройки SPF приведены в нашем руководстве по записи SPF.

DKIM: проблема согласования доменов

DMARC проверяет два условия: прошла ли проверка SPF или DKIM в соответствии с RFC 6376 и согласованы ли домены. Согласование означает, что домен в заголовке From соответствует техническим доменам заголовков: Return-Path для SPF или d= для DKIM.

Типичная проблема службы поддержки: CRM вроде Zendesk или HubSpot отправляет письма от имени support@yourcompany.com. Возвраты обрабатывает CRM, поэтому в Return-Path указан bounces.zendesk.com, и согласование SPF не проходит. Пользовательский CNAME не настроен, поэтому DKIM подписывает письмо доменом d=zendesk.com, и согласование DKIM тоже не проходит. Технически письмо аутентифицировано: его отправил Zendesk и он же поставил подпись. Но DMARC не видит ни одного протокола, согласованного с вашим доменом. При политике p=reject такое письмо, скорее всего, будет отклонено.

Ограничение в 10 DNS-запросов

В SPF, описанном в RFC 7208, установлен жёсткий предел: 10 DNS-запросов на одну проверку записи. Агентствам с клиентами, которые активно используют SaaS-сервисы, эта проблема хорошо знакома. Один Google Workspace может потребовать 4 запроса. Добавьте Mailchimp, HubSpot, систему заявок и кадровый сервис:

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

Скрытые барьеры за пределами SPF, DKIM и DMARC

Помимо трёх основных механизмов существуют технические требования без громких маркетинговых названий, которые столь же быстро могут остановить доставку.

FCrDNS, подтверждённый прямой и обратный DNS

Для каждого отправляющего IP нужна PTR-запись, то есть обратный DNS, которая указывает на имя хоста. У этого имени должна быть A-запись, ведущая обратно на исходный IP. Такая круговая проверка подтверждает контроль над инфраструктурой. Если создать облачную виртуальную машину, установить Postfix и отправлять почту без PTR-записи, Gmail может счесть источник подозрительным и сразу вернуть 550 5.7.1. Точная реакция зависит от провайдера и репутации.

RFC 8058: отписка одним нажатием

С июня 2024 года одной ссылки внизу маркетингового письма для крупных провайдеров может быть недостаточно. Необходимо добавить два специальных заголовка:

HTTPS-адрес должен принимать запрос POST, а не GET. Антиспам-боты проверяют письма, переходя по ссылкам. Если отписка срабатывает через GET, бот может случайно отписать настоящего пользователя. А если человеку сложно найти понятный выход из рассылки, он нажмёт «Спам», приблизив отправителя к критической доле жалоб 0.3%.

Порог 0.3%: экономика репутации

Идеальные SPF, DKIM и DMARC, безупречный FCrDNS и правильные заголовки не помогут, если получатели не хотят видеть ваши письма.

Один из важнейших показателей, доля жалоб на спам. Ориентир составляет 0.3%, то есть 3 жалобы на 1,000 писем. При превышении порога Google может серьёзно ограничить доставку или заблокировать домен. Методика и последствия зависят от действующих правил провайдера.

Ловушка Yahoo с расчётом по входящим

Yahoo может рассчитывать долю жалоб по письмам, попавшим во входящие, а не по общему числу отправленных. Допустим, вы отправили 1,000 писем. Репутация домена уже пошатнулась, поэтому 900 писем ушли в спам, а 100 попали во входящие. Пожаловался один человек. Расчёт: 1/100 = 1.0%, то есть 3x от указанного контрольного уровня. Одна жалоба способна усилить негативный цикл, из которого трудно выйти.

Проблема шумных соседей

Даже при корректных SPF, DKIM и DMARC на обычном виртуальном хостинге или дешёвой «безлимитной» почтовой платформе ваши письма могут отправляться с того же IP, что и сообщения тысяч других клиентов. Если один из них рассылает мошеннические предложения, Spamhaus может внести IP в блок-лист. Тогда заблокируют и ваши письма. Вы не нарушали правил, но делите репутацию инфраструктуры с проблемным соседом.

Пятничный контрольный список для SPF, DKIM и DMARC

1. Проверьте заголовки: Отправьте письмо в личный ящик Gmail. Откройте письмо, нажмите на три точки и выберите просмотр оригинала. Найдите Authentication-Results. Прошли ли SPF и DKIM? Совпадает ли домен dkim= с доменом header.from? Если нет, нарушено согласование.

2. Проверьте FCrDNS: Выполните dig -x <your-sending-ip>. Команда возвращает имя хоста? Затем выполните dig <that-hostname>. Возвращается исходный IP? Если цепочка не замыкается, приостановите отправку и исправьте DNS.

3. Разделите потоки: Не отправляйте маркетинговые рассылки с основного корпоративного домена. Используйте team@company.com для личной переписки, а newsletter@marketing.company.com для массовых рассылок. Если маркетинговый поддомен достигнет порога 0.3%, основной домен будет меньше затронут, хотя поддомены не всегда дают полную репутационную изоляцию.

4. Узнайте больше: О практических способах восстановления читайте в нашем руководстве по репутации отправителя и подробном материале о репутации почтового домена.

Тарифы TrekMail

Все платные тарифы: пробный период 14 дней, карта обязательна. Free: без карты. Перед покупкой проверьте актуальные цены и состав тарифов.

Заключение

SPF, DKIM и DMARC нельзя настроить один раз и забыть. Это постоянная операционная задача. Успешное прохождение проверок является лишь входным требованием. Чтобы письма действительно оставались во входящих, нужны строгое согласование доменов, безупречная сетевая гигиена, включая FCrDNS и заголовки отписки одним нажатием, а также стратегия управления репутацией, защищающая от соседей по IP. Настройки по умолчанию недостаточны. Инфраструктуру нужно контролировать и регулярно проверять.

Зелёные отметки SPF, DKIM и DMARC являются только началом. Попробуйте TrekMail бесплатно и возьмите аутентификацию почты под реальный контроль.