Аутентификация почты: как работают SPF, DKIM и DMARC

Аутентификация почты SPF, DKIM и DMARC стала базовой частью настройки домена. Если домен отправляет деловые письма в 2025 или 2026 году, эти записи влияют на то, как принимающие системы классифицируют или отклоняют почту, но сами по себе не гарантируют попадание во входящие. Чтобы сначала увидеть всю инфраструктуру целиком, начните с материала о корпоративной почте для малого бизнеса.

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

Теория проста, а практическая реализация требует аккуратности. SPF указывает, какие IP-адреса разрешены для фактического домена MAIL FROM, DKIM подтверждает действительность подписи для неизменившихся подписанных данных, а DMARC запрашивает обработку при сбое и проверяет выравнивание с видимым доменом From. Корректная аутентификация почты SPF, DKIM и DMARC даёт принимающей стороне важные сигналы, но не определяет её решение целиком.

Что на самом деле делает аутентификация SPF, DKIM и DMARC

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

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

SPF: кому разрешено отправлять почту для домена

Первый уровень аутентификации почты SPF, DKIM и DMARC это SPF, список разрешённых отправителей. Принимающий сервер берёт фактический домен envelope sender, то есть MAIL FROM, читает его TXT-запись SPF и проверяет полномочия подключающегося IP. Механизм полезен, но чувствителен к пересылке и длинным цепочкам include.

SPF публикуется в DNS как TXT-запись. Обычный пример:

v=spf1 include:_spf.google.com include:spf.trekmail.net -all

Значение элементов:

1. v=spf1 объявляет тип записи.
2. include: ссылается на опубликованную инфраструктуру отправки другого домена.
3. -all указывает, что остальные источники должны получить результат fail.

Здесь многие конфигурации впервые сталкиваются с ограничением: предел в 10 DNS-запросов из RFC 7208. Учитываются соответствующие механизмы и модификаторы, включая вложенные запросы за include. При превышении получатель может вернуть PermError, и оценка SPF не будет корректно завершена.

Например, вы два года назад отказались от CRM, но оставили её include:. Маркетинговая платформа добавила ещё три вложенных источника, а служба поддержки ещё один. Запись выглядела приемлемо, пока принимающая сторона не посчитала всю цепочку.

SPF также может нарушаться при пересылке. Если университет пересылает письмо в Gmail, Gmail может видеть IP университета, а не исходного сервера. Даже правильно настроенный SPF тогда может не пройти. Поэтому одного SPF недостаточно.

Если для отправки используется TrekMail, в документации показан необходимый include и способ объединить его с существующим SPF без дублирования: обязательные DNS-записи.

DKIM: кто подписал сообщение и изменилось ли оно

Второй уровень аутентификации почты SPF, DKIM и DMARC это DKIM. Отправляющая система подписывает выбранные данные закрытым ключом, а получатель проверяет подпись открытым ключом из DNS. В отличие от SPF, DKIM часто сохраняется при пересылке, если подпись остаётся действительной и канонизированные подписанные заголовки и тело не были изменены несовместимым образом.

Записи DKIM размещаются по адресу селектора, например selector1._domainkey.example.com или dkim._domainkey.example.com. Отправитель использует соответствующий селектор, а получатель получает открытый ключ из DNS и проверяет подпись.

Типичное значение DNS:

Host: dkim._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4G...

Операционные причины обычно просты:

1. После ротации сервер продолжает использовать старый селектор.
2. После смены провайдера новый открытый ключ не опубликован.
3. DNS-хостинг исказил длинное значение TXT.
4. Список рассылки переписал тело и нарушил подпись.

Для нового совместимого развёртывания разумным рекомендуемым значением по умолчанию обычно служат ключи 2048 бит, если платформа и DNS их поддерживают. Устаревшие системы с ключами 1024 бит всё ещё встречаются в 2026 году, но выбор размера следует сверять с возможностями конкретного подписывающего сервиса.

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

DMARC: правила запрашиваемой обработки

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

Запись DMARC публикуется по адресу _dmarc.example.com. Начните с простого варианта:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Переходите дальше после инвентаризации и проверок:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com

v=DMARC1; p=reject; rua=mailto:dmarc@example.com

p=none не запрашивает ограничение из-за DMARC. p=quarantine просит получателя считать сбой подозрительным, а p=reject просит отклонить письмо. Это опубликованные запросы политики, а не гарантия одинаковой обработки всеми получателями.

Основная сложность заключается в выравнивании. Например:

Видимый From: newsletter@yourcompany.com
Return-Path: bounce.vendor.com
Домен DKIM: vendor.com

SPF может пройти. DKIM тоже может пройти. Но DMARC не проходит, потому что ни один успешный домен не выровнен с yourcompany.com.

Это частая ошибка в конфигурациях Mailchimp, HubSpot, Zendesk и CRM: панель отправляющего сервиса может показывать зелёный статус, однако реальное письмо всё равно не выровнено. В актуальных рекомендациях Google для подпадающих под них массовых отправителей в личные аккаунты Gmail требуется настроить SPF и DKIM, а для прямой почты хотя бы один механизм должен быть выровнен с From. Там же указана минимальная запись DMARC, даже с p=none: частые вопросы о требованиях Google к отправителям.

SPF, DKIM или DMARC: что важнее?

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

В простой схеме с одним почтовым сервером и без внешних отправителей настройка обычно понятна. Если один домен используют служба поддержки, рассылка, CRM и пересылка, именно отчёты DMARC помогают выяснить, какие реальные потоки выровнены, а какие только кажутся такими по настройкам панели.

Почему пересылка и списки рассылки вызывают необычные сбои

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

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

При сбое SPF, DKIM и DMARC на пересланном письме ARC позволяет посредникам записать увиденные ими результаты, чтобы следующий получатель оценил этот контекст по собственным правилам. ARC не сохраняет автоматически доверие и не превращает DMARC в pass. В рекомендациях Google указаны отдельные условия для выравнивания DMARC при пересылке и почтовых списках, а для непрямой почты рекомендуются заголовки ARC. Отправитель обычно не настраивает ARC самостоятельно. Его практическая задача заключается в рабочем DKIM и минимизации хрупких цепочек. Если пересылка важна, далее прочитайте руководство по пересылке почты.

Дополнительные проверки, влияющие на обработку почты

Даже корректно опубликованные записи аутентификации не гарантируют попадание во входящие. Получатели учитывают обратный DNS, TLS, жалобы и механизм отказа от рассылки. Аутентификация почты SPF, DKIM и DMARC это основа, но не весь процесс.

1. Подтверждённый прямым разрешением обратный DNS: для отправляющего IP нужна PTR-запись, а её имя должно разрешаться обратно в тот же IP. Google указывает действительные прямой и обратный DNS среди требований к соответствующим отправителям.
2. TLS: крупные провайдеры ожидают передачу по TLS. В FAQ Google отсутствие TLS названо одной из причин временного или постоянного сбоя в применимых случаях.
3. Жалобы на спам: Google рекомендует соответствующим отправителям поддерживать показатель ниже 0.1% и не допускать 0.3%.
4. Отписка одним нажатием: к применимым рекламным письмам предъявляются требования к заголовкам отписки по RFC 8058, а не только к ссылке в подвале.

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

Как настроить SPF, DKIM и DMARC без нарушения рабочей почты

Безопаснее сначала составить реестр всех отправителей, опубликовать согласованные записи, проверить их на реальных письмах и переводить DMARC от наблюдения к применению поэтапно. Если пропустить инвентаризацию, можно отключить забытый SaaS-сервис.

1. Перечислите все сервисы, использующие домен: почтовый хостинг, CRM, поддержка, рассылки, формы, счета и серверы.
2. Объедините отправителей в одну запись SPF. Не публикуйте две отдельные записи SPF TXT.
3. Опубликуйте DKIM для каждого отправителя, которому нужен свой селектор.
4. Сначала опубликуйте DMARC с p=none и собирайте отчёты, учитывая их неполноту.
5. Настройте внешним отправителям собственную аутентификацию домена и проверьте выравнивание реальными письмами.
6. После нескольких репрезентативных периодов, проверки редких критичных потоков и подготовки отката постепенно переходите к p=quarantine, затем к p=reject.

Для домена TrekMail с управляемой отправкой базовые записи могут выглядеть так, но фактические значения следует брать из текущей панели и документации:

MX  @                mail.trekmail.net.            priority 10
TXT @                v=spf1 include:spf.trekmail.net -all
TXT dkim._domainkey  v=DKIM1; k=rsa; p=...unique key from dashboard...
TXT _dmarc           v=DMARC1; p=quarantine; rua=mailto:dmarc@trekmail.net

Точный формат записей и процесс проверки описаны в документации TrekMail: обязательные DNS-записи и проверка состояния DNS. Для более раннего этапа подойдёт материал как настроить почту на своём домене.

Раздельный и интегрированный подходы

Традиционный вариант заключается в оплате большого пакета на каждого пользователя или самостоятельном обслуживании почтовой системы, DNS, TLS, селекторов DKIM и репутации. Другой вариант отделяет хостинг ящиков от отправки и использует платформу, которая предоставляет записи, проверку и путь миграции на условиях выбранного плана.

В эту модель может вписаться TrekMail. По описанным в статье текущим условиям Nano позволяет разместить до 10 доменов с общим хранилищем 5 ГБ и использовать собственный SMTP. Платные планы начинаются с $3.50 в месяц и могут включать управляемый SMTP. В зависимости от плана доступны собственные домены, IMAP-ящики, catch-all, пересылка, встроенная миграция IMAP и API. Для платных планов может быть доступна бесплатная пробная версия на 14 дней, для начала которой нужна кредитная карта. Nano может оставаться бесплатным без карты согласно действующим условиям. Перед выбором проверьте актуальные цены, функции и ограничения.

Эта модель важна, поскольку аутентификация почты SPF, DKIM и DMARC требует постоянной операционной работы. При множестве доменов единая панель, общее хранилище, подготовленные DNS-записи и серверная миграция могут сократить число разрозненных процедур, но не отменяют проверку. Для такого сценария сравните мультидоменный почтовый хостинг. Актуальные цифры доступны на странице тарифов TrekMail.

Вывод: SPF, DKIM и DMARC стали базовой настройкой

Аутентификация почты SPF, DKIM и DMARC больше не относится к редким расширенным мерам. SPF указывает разрешённые IP для envelope-домена, DKIM подтверждает подпись выбранных данных, а DMARC связывает успешный механизм с видимым доменом From и публикует запрашиваемую политику.

Если вы можете заняться только одной задачей на этой неделе, составьте реестр отправителей, опубликуйте одну корректную запись SPF, рабочую запись DKIM и DMARC с p=none. Затем проверьте каждый реальный поток, включая редкие маршруты и пересылку. Переходите к применению политики только после нескольких репрезентативных периодов и с планом отката. Такая подготовка снижает риск последующей диагностики отклонений, хотя не гарантирует доставку или экономию.