SPF, DKIM и DMARC: полное руководство по аутентификации почты

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

Все три живут в DNS-записях вашего домена, поэтому настройки аутентификации любого домена, включая ваш собственный, можно посмотреть обычным DNS-запросом. Это руководство объясняет, за что отвечает каждая запись, как её читать и как дойти до строгой политики DMARC, случайно не заблокировав собственные счета.

Чтобы проверить все три записи сразу, включая число DNS-запросов SPF и длину ключа DKIM, воспользуйтесь нашей проверкой SPF, DKIM и DMARC.

Почему аутентификация почты важна

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

• Почта фильтруется. Неаутентифицированные письма гораздо чаще попадают в карантин, а иногда отклоняются ещё до доставки в ящик.
• Любой может подделать ваш домен. Без политики DMARC принимающий сервер не имеет указания отклонять поддельные письма с вашим именем.
• Вы не видите злоупотреблений. Отчёты DMARC — единственный способ узнать, что кто-то рассылает фишинг от вашего имени.
• Сделки буксуют. В анкетах по безопасности и проверках поставщиков регулярно спрашивают политику DMARC, и «none» всё чаще считают замечанием.

Три записи кратко

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

SPF: кому разрешено слать от вашего домена

Sender Policy Framework — это опубликованный список серверов, которым разрешено отправлять почту от вашего домена. Принимающий сервер берёт IP-адрес подключившегося узла, запрашивает вашу SPF-запись и проверяет, есть ли этот адрес в списке.

Как читать запись SPF

Типичная запись выглядит так:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all

Читается слева направо. v=spf1 — версия, она должна идти первой. Каждый include: подтягивает SPF-запись другого домена: так вы разрешаете провайдера вроде Google Workspace или сервис транзакционной почты. ip4: и ip6: разрешают конкретные адреса или диапазоны, обычно ваш собственный сервер. Последний механизм — правило «для всего остального», и именно в нём чаще всего ошибаются:

• -all — жёсткий отказ. Всё, что не перечислено, считается неразрешённым, и получатель должен его отклонить.
• ~all — мягкий отказ. Неперечисленные отправители подозрительны, но письмо принимается, обычно со штрафом к спам-оценке.
• ?all — нейтрально и не сообщает получателю ничего, что сводит на нет смысл публикации записи.

Начните с ~all, пока проверяете, что все легитимные отправители перечислены, и ужесточите до -all, когда отчёты DMARC станут чистыми.

Лимит в десять запросов

SPF допускает не более десяти DNS-запросов при вычислении записи. Считаются все include:, a, mx и redirect, в том числе вложенные. Превышение даёт постоянную ошибку, которую большинство получателей трактует как полное отсутствие SPF. Трёх-четырёх почтовых провайдеров обычно хватает, чтобы выйти за лимит, поэтому проверяйте запись при каждом новом сервисе рассылки и удаляйте тех, кем вы больше не пользуетесь.

Ещё одно правило, которое удивляет: домен может публиковать только одну SPF-запись. Две TXT-записи с v=spf1 на одном имени — это постоянная ошибка, а не объединение.

DKIM: подпись ваших писем

DomainKeys Identified Mail добавляет криптографическую подпись к каждому исходящему письму. Ваш сервер хранит приватный ключ и подписывает выбранные заголовки и тело; соответствующий публичный ключ публикуется в DNS. Получатель забирает публичный ключ, проверяет подпись и узнаёт две вещи: письмо действительно подписано вашим доменом и ничего из подписанного не изменилось в пути.

Публичный ключ лежит по имени, построенному из селектора, например google._domainkey.example.com или s1._domainkey.example.com. Селекторы нужны, чтобы держать несколько ключей одновременно, и именно это делает ротацию безболезненной: опубликуйте новый селектор, переключите на него подпись, старый уберите позже.

Поскольку подпись путешествует вместе с письмом, DKIM переживает пересылку там, где SPF её не переживает. Если рассылочный список ретранслирует ваше письмо, подключающийся IP меняется и SPF не проходит, но подпись DKIM остаётся валидной, пока список не переписал подписанные заголовки или тело. Эта устойчивость — главная причина, по которой DKIM важен, даже когда SPF уже настроен.

DMARC: что делать получателю

SPF и DKIM дают «прошло» или «не прошло», но ни один не говорит, что с этим делать, и ни один не смотрит на адрес From, который читает ваш адресат. DMARC закрывает оба пробела. Запись выглядит так:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100; adkim=s; aspf=r

p= — политика: none (только наблюдение), quarantine (считать сбои спамом) или reject (отклонять на входе). rua= — адрес, куда приходят ежедневные сводные отчёты, и это самая ценная часть записи. pct= позволяет применять политику к доле писем во время внедрения.

Выравнивание — то, что упускают почти все

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

adkim и aspf задают строгость совпадения. Мягкий режим (r, по умолчанию) принимает поддомен вида mail.example.com; строгий (s) требует точного совпадения. Начинайте с мягкого. DMARC проходит, если прошёл хотя бы один из SPF и DKIM и он выровнен, так что достаточно одной выровненной подписи DKIM.

Как безопасно включить политику

1. Опубликуйте p=none с адресом для отчётов. Для вашей почты ничего не меняется, но начинают приходить отчёты.
2. Читайте отчёты две-четыре недели. Они покажут забытые сервисы рассылки: CRM, службу поддержки, систему счетов, старую маркетинговую платформу.
3. Закройте пробелы. Добавьте каждого легитимного отправителя в SPF, включите подпись DKIM с выровненным доменом и проверьте результат в следующем отчёте.
4. Перейдите на p=quarantine. При больших объёмах наращивайте долю через pct=.
5. Завершите на p=reject. Только когда в отчётах не останется сбоев легитимной почты. Именно эта политика действительно останавливает подделку.

Как проверить собственные записи

Все три записи публичные и типа TXT, так что проверка занимает секунды:

1. SPF. Сделайте TXT-запрос к домену без поддомена инструментом DNS-запрос и найдите строку, начинающуюся с v=spf1. Убедитесь, что она ровно одна, и посчитайте запросы.
2. DMARC. Сделайте TXT-запрос к _dmarc. плюс ваш домен. Если ничего не вернулось, у вас нет ни политики, ни отчётов.
3. DKIM. Сделайте TXT-запрос к селектор._domainkey. плюс ваш домен. Нужный селектор указан в документации почтового провайдера.
4. Проверьте сквозным тестом. Отправьте письмо на ящик крупного провайдера и посмотрите полученные заголовки. Режим Gmail «Показать оригинал» выводит результаты SPF, DKIM и DMARC для только что отправленного письма, и это единственная проверка всей цепочки.

Раз уж вы в DNS, заодно подтвердите остальную почтовую конфигурацию: проверьте, что MX-записи указывают туда, куда вы ожидаете, и что имя в сертификате вашего сервера совпадает, — это легко посмотреть проверкой SSL-сертификата.

Частые ошибки

• Две записи SPF. Объедините их в одну. Две — постоянная ошибка.
• Навсегда оставить DMARC в p=none. Наблюдение — старт, а не финиш. Подделку предотвращают только quarantine или reject.
• Нет адреса для отчётов. Запись DMARC без rua= выбрасывает ровно ту информацию, которая нужна для безопасного ужесточения.
• Забытые припаркованные домены. Домены, которые не шлют почту, должны публиковать v=spf1 -all и p=reject — именно потому, что злоумышленники предпочитают неиспользуемые домены.
• Сразу строгое выравнивание. adkim=s и aspf=s до чистых отчётов сломают легитимную почту с поддоменов.
• Игнорировать TTL. Большой TTL у TXT-записи означает, что исправление расходится часами. Снизьте его перед миграцией и поднимите после.

Настройте аутентификацию сегодня

Аутентификация почты — одна из немногих задач безопасности с однозначной отдачей: лучше доставляемость, видно злоупотребления, домен нельзя подделать мимоходом. К тому же она полностью читается снаружи, так что гадать о собственной конфигурации незачем. Начните с TXT-запроса к своему домену через бесплатный DNS-запрос, прочитайте, что опубликовано на самом деле, и пройдите внедрение выше шаг за шагом.

Связанные инструменты и руководства:

• DNS-запрос — запросите TXT, MX, SPF и любые другие записи любого домена.
• DNS-запрос: полное руководство — с разбором каждого типа записи.
• Проверка SSL-сертификата — посмотрите сертификат почтового или веб-сервера.
• Коды состояния HTTP — быстрый справочник по всем кодам ответа.
• Почему SPF-запись не проходит проверку — и как это исправить - лимит в десять запросов, сломанные include и другие причины сбоев SPF.

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