SPF, DKIM и DMARC: что это такое, как настроить и почему это важно

Ваши письма безупречно составлены. Список рассылки чистый. Расписание отправки стабильное. Но показатели открытий падают, а Gmail упорно отправляет вас в спам. Проблема может быть не в том, что вы отправляете, а в том, что вы не доказали, что вы -- это действительно вы.

Аутентификация электронной почты -- это способ доказать почтовым провайдерам, что письмо, утверждающее, что оно отправлено с вашего домена, действительно пришло с вашего домена. Без неё любой может подделать ваш адрес «От» и рассылать фишинговые письма от имени вашего бренда. Почтовые провайдеры это знают, поэтому неаутентифицированная почта по умолчанию рассматривается как подозрительная.

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

Что такое аутентификация электронной почты?

Когда вы отправляете письмо по обычной почте, получатель может видеть обратный адрес -- но любой может написать любой обратный адрес на конверте. Электронная почта работает аналогично. Поле «От» в письме -- это просто текст. Без аутентификации ничто не мешает спамеру отправить письмо, которое утверждает, что оно от you@yourdomain.com.

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

• Авторизован ли этот сервер для отправки почты от имени этого домена? (SPF)
• Было ли это сообщение изменено после отправки? (DKIM)
• Что делать, если аутентификация не пройдена? (DMARC)

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

Разбираем SPF

Что такое SPF

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

Если IP совпадает, SPF пройден. Если нет, SPF провален -- и принимающий сервер понимает, что письмо может быть поддельным.

Как работает SPF (пошагово)

1. Вы отправляете письмо с hello@yourdomain.com через вашего провайдера email-рассылок (ESP).
2. Принимающий сервер видит, что письмо утверждает, что оно от yourdomain.com.
3. Он ищет SPF-запись в DNS для yourdomain.com.
4. SPF-запись содержит что-то вроде: «Только эти серверы имеют право отправлять от моего имени: 192.0.2.1 и всё, что указано в SPF-записи Mailchimp».
5. Принимающий сервер проверяет, совпадает ли IP, который фактически отправил письмо, с SPF-записью.
6. Если совпадает: SPF пройден. Если нет: SPF провален.

Как настроить SPF

Настройка SPF требует добавления одной TXT-записи в DNS вашего домена. Вот как выглядит типичная SPF-запись:

v=spf1 include:_spf.google.com include:servers.mcsv.net -all

Разберём её:

• v=spf1 -- идентифицирует эту запись как SPF
• include:_spf.google.com -- авторизует Google Workspace для отправки от имени вашего домена
• include:servers.mcsv.net -- авторизует Mailchimp для отправки от имени вашего домена
• -all -- сообщает получателям отклонять почту от любого сервера, не указанного выше

Для настройки: войдите в панель управления DNS вашего провайдера (GoDaddy, Cloudflare, Namecheap и т. д.), перейдите в раздел DNS-записей, добавьте новую TXT-запись с хостом @ (ваш корневой домен) и вставьте значение SPF. Ваш ESP подскажет, что именно включить -- проверьте его документацию.

Распространённые ошибки SPF

• Несколько SPF-записей. Ваш домен может иметь только одну SPF-запись. Если вы добавите вторую (например, одну для Google и одну для Mailchimp), обе перестанут работать. Объедините их в одну запись, используя несколько инструкций include:.
• Слишком много DNS-запросов. SPF имеет ограничение в 10 DNS-запросов. Каждый include: считается за один запрос, и вложенные include тоже учитываются. Если вы превысите 10, SPF автоматически провалится для каждого вашего письма. Используйте инструмент сглаживания SPF, если достигли лимита.
• Использование +all вместо -all. Флаг +all означает «разрешить всем отправлять от имени моего домена» -- что полностью обесценивает SPF. Всегда используйте -all (жёсткий отказ) или как минимум ~all (мягкий отказ).
• Забытые сторонние отправители. Если вы используете CRM, службу поддержки или сервис транзакционных писем, их серверы тоже должны быть в вашей SPF-записи. Типичная ситуация: маркетинговые письма проходят SPF, а транзакционные из вашего хелпдеска -- нет, потому что вы забыли их добавить.

Разбираем DKIM

Что такое DKIM

DKIM (DomainKeys Identified Mail) добавляет криптографическую цифровую подпись к каждому отправляемому вами письму. Эта подпись генерируется с помощью закрытого ключа, который есть только у вашего отправляющего сервера. Соответствующий открытый ключ публикуется в вашем DNS, чтобы любой мог проверить подпись.

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

Как работает DKIM (пошагово)

1. Ваш почтовый сервер генерирует уникальный криптографический хеш заголовков и тела письма.
2. Он подписывает этот хеш вашим закрытым ключом и прикрепляет подпись к заголовку письма как поле DKIM-Signature.
3. Принимающий сервер видит подпись DKIM и извлекает из неё селектор и домен.
4. Он ищет открытый ключ в вашем DNS по селектору (например, selector1._domainkey.yourdomain.com).
5. Он использует открытый ключ для проверки подписи по содержимому письма.
6. Если подпись совпадает: DKIM пройден. Если нет: DKIM провален (сообщение было изменено или ключ не совпадает).

Как настроить DKIM

Настройка DKIM несколько сложнее, чем SPF, поскольку требует от вашего почтового провайдера генерации пары ключей. Вот общий процесс:

1. Сгенерируйте ключи DKIM в вашем ESP. Перейдите в настройки вашего почтового провайдера и найдите раздел «DKIM» или «Аутентификация почты». Большинство провайдеров (Google Workspace, Mailchimp, SendGrid и др.) генерируют ключи за вас и предоставляют DNS-запись для добавления.
2. Добавьте DKIM-запись в ваш DNS. Вы получите TXT- или CNAME-запись с хостом вроде google._domainkey и длинным значением, содержащим открытый ключ. Добавьте её в панели DNS-провайдера.
3. Активируйте DKIM в вашем ESP. Некоторые провайдеры требуют нажать «Начать аутентификацию» или аналогичную кнопку после добавления DNS-записи. Не пропускайте этот шаг.
4. Проверьте работу. Отправьте тестовое письмо и проверьте заголовки на наличие dkim=pass. Большинство ESP также показывают статус DKIM в панели управления.

DNS-запись DKIM выглядит примерно так:

Host: google._domainkey.yourdomain.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

Распространённые ошибки DKIM

• DKIM не настроен для всех отправителей. Каждый используемый вами почтовый сервис нуждается в собственном ключе DKIM. Если вы настроили DKIM для Google Workspace, но не для Mailchimp, письма от Mailchimp будут проваливать проверку DKIM.
• Слишком короткий ключ. Используйте ключи длиной не менее 1024 бит, но стандарт 2026 года -- 2048 бит. Некоторые провайдеры всё ещё по умолчанию используют 1024 -- обновите, если возможно.
• Отсутствие ротации ключей. Хотя обязательного графика ротации нет, замена ключей DKIM раз в год -- это лучшая практика безопасности. Если закрытый ключ будет скомпрометирован, кто-то сможет подписывать письма от имени вашего домена.
• DNS-запись слишком длинная для одной TXT-записи. Некоторые DNS-провайдеры имеют ограничение в 255 символов на строку TXT-записи. Если ваш 2048-битный ключ превышает этот лимит, может потребоваться разбить его на несколько строк в кавычках. Документация вашего ESP покажет, как это сделать.

Разбираем DMARC

Что такое DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance) -- это протокол, который связывает SPF и DKIM вместе и добавляет критически важный недостающий элемент: политику. DMARC сообщает принимающим серверам, что делать, когда письмо с вашего домена не проходит аутентификацию.

Без DMARC принимающим серверам приходится гадать. Доставить письмо всё равно? Отправить в спам? Полностью отклонить? Каждый сервер принимает собственное решение. DMARC позволяет вам решать, публикуя чёткую политику в вашем DNS.

DMARC также вводит выравнивание (alignment). SPF и DKIM проверяют разные части заголовка письма. DMARC требует, чтобы хотя бы один из них «совпадал» с доменом в видимом адресе «От» -- тем, который фактически видят ваши получатели. Это закрывает лазейку, при которой злоумышленник мог пройти SPF с одним доменом, но показать получателю совершенно другой домен.

Политики DMARC: none, quarantine и reject

DMARC предлагает три уровня политики:

Как настроить DMARC

DMARC -- это одна TXT-запись в вашем DNS. Вот рекомендуемый подход:

Шаг 1: Начните с мониторинга. Добавьте эту TXT-запись в ваш DNS:

Host: _dmarc.yourdomain.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

• v=DMARC1 -- идентифицирует эту запись как DMARC
• p=none -- только мониторинг, не предпринимать действий при неудачах
• rua=mailto:... -- куда отправлять агрегированные отчёты (XML-отчёты, показывающие, кто отправляет почту от имени вашего домена и проходит ли аутентификацию)

Шаг 2: Анализируйте отчёты в течение 2-4 недель. Вы будете получать XML-отчёты от крупных почтовых провайдеров. Эти отчёты показывают каждый IP-адрес, который отправлял почту с использованием вашего домена, и были ли пройдены SPF/DKIM. Используйте анализатор отчётов DMARC (например, dmarcian или EasyDMARC), чтобы сделать данные читаемыми. Ваша цель: убедиться, что все ваши легитимные отправители проходят и SPF, и DKIM.

Шаг 3: Перейдите к quarantine. Когда вы уверены, что вся легитимная почта проходит проверку:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

Шаг 4: Перейдите к reject. Ещё через несколько недель чистых отчётов:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

Никогда не переходите сразу к p=reject без предварительного мониторинга. Если легитимный отправитель не прошёл аутентификацию должным образом, его письма будут молча отброшены -- и вы не узнаете об этом, пока кто-то не пожалуется, что не получил ваше сообщение.

Распространённые ошибки DMARC

• Переход сразу к p=reject. Это самая опасная ошибка. Если у вас есть забытый сторонний отправитель (старая CRM, хелпдеск, сервис транзакционных писем), который не аутентифицирован, его письма будут заблокированы без предупреждения.
• Отсутствие адреса для отчётов (rua). Без отчётов вы действуете вслепую. Вы не узнаете, проваливается ли легитимная почта или кто-то подделывает ваш домен.
• Игнорирование отчётов DMARC. Настроить p=none и никогда не смотреть отчёты -- значит лишиться смысла всей процедуры. Весь смысл мониторинга -- обнаружить проблемы до применения политики.
• Проблемы с выравниванием. DMARC требует, чтобы домен в SPF или DKIM совпадал (выравнивался) с видимым доменом «От». Если ваш ESP отправляет с другого домена и не подписывает письма DKIM вашего домена, DMARC будет провален, даже если SPF пройден.

SPF vs. DKIM vs. DMARC: сравнение

Вот сравнение, что делает каждый протокол и от чего он защищает:

Ключевой вывод: каждый протокол закрывает свой пробел. SPF сам по себе не проверяет видимый адрес «От». DKIM сам по себе не сообщает получателям, что делать при неудачной аутентификации. DMARC сам по себе не работает без SPF или DKIM в качестве якоря. Вам нужны все три протокола, работающие вместе.

Как аутентификация влияет на доставляемость

Аутентификация электронной почты -- один из фундаментальных столпов репутации отправителя. Почтовые провайдеры используют аутентификацию как базовый сигнал доверия. Она не гарантирует попадание во входящие -- вам по-прежнему нужны чистые списки, низкий уровень жалоб и хорошие показатели вовлечённости -- но без аутентификации всё остальное теряет смысл.

Вот что происходит на каждом уровне аутентификации:

• Без аутентификации: Большинство крупных провайдеров отправят ваше письмо в спам или полностью отклонят. Gmail особенно агрессивен в этом отношении с момента обновления требований к отправителям в 2024 году.
• Только SPF: Лучше, чем ничего, но остаются пробелы. Пересланные письма нарушат SPF, и нет защиты от подделки домена в видимом поле «От».
• SPF + DKIM: Значительно лучше. Вы доказываете и авторизацию сервера, и целостность сообщения. Но без DMARC нет политики и отчётов -- вы не узнаете, когда происходят неудачи.
• SPF + DKIM + DMARC (reject): Золотой стандарт. Полная аутентификация, полная защита, полная видимость. Именно это требуют Gmail и Yahoo для массовых отправителей, и к этому должен стремиться каждый домен.

Аутентификация особенно критична, если вы используете несколько сервисов отправки. Каждый ESP, CRM, хелпдеск и система транзакционных писем, отправляющая от имени вашего домена, должна быть правильно аутентифицирована. Один неаутентифицированный отправитель может подорвать репутацию всего домена. Используйте ClearBounce Deliverability Kit для мониторинга статуса аутентификации и обнаружения проблем до того, как они повлияют на попадание во входящие.

Распространённые ошибки аутентификации

Даже отправители, которые считают, что правильно настроили аутентификацию, часто имеют скрытые проблемы. Вот наиболее частые ошибки, которые мы наблюдаем:

Чек-лист аутентификации электронной почты

Используйте этот чек-лист, чтобы проверить правильность настройки аутентификации. Каждый пункт занимает минуты для проверки, но может предотвратить недели проблем с доставляемостью:

Итог

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

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

Но аутентификация -- это лишь часть пазла доставляемости. Идеально аутентифицированное письмо на несуществующий адрес всё равно приведёт к возврату. Идеально подписанное письмо, отправленное на спам-ловушку, всё равно повредит вашей репутации. Аутентификация сообщает почтовым провайдерам, что вы -- тот, за кого себя выдаёте. Верификация email обеспечивает, что вы отправляете письма людям, которые реально существуют и хотят вас слышать. Вместе они составляют фундамент стабильного попадания во входящие.

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