Зачем это нужно
Протокол электронной почты изначально не проверяет, кто на самом деле отправил письмо: в поле «От кого» можно написать что угодно. Поэтому крупные почтовые сервисы стали проверять отправителя сами и требуют от домена три подтверждения. Если их нет, письмо подозрительно: его отправляют в спам, помечают предупреждением или отклоняют вовсе.
Требования касаются любых писем с вашего домена: обычной переписки в почте для домена и автоматических писем сайта, которые уходят через SMTP-сервер или API. Все три записи — TXT-записи в DNS-зоне домена, и добавляются они у вашего регистратора или DNS-хостинга.
| Запись | Что подтверждает | Где хранится |
|---|---|---|
| SPF | Какие серверы вправе отправлять почту от имени домена | TXT на корне домена |
| DKIM | Что письмо не изменено по пути и подписано владельцем домена | TXT на поддомене селектора |
| DMARC | Что делать с письмами, не прошедшими SPF и DKIM, и куда слать отчёты | TXT на поддомене _dmarc |
SPF: кому можно отправлять
SPF (Sender Policy Framework) — это список серверов и сервисов, которым разрешено отправлять почту от имени вашего домена. Получатель смотрит, с какого IP-адреса пришло письмо, и сверяет его со списком.
v=spf1 include:spf.example.net ~allЧасть include: подключает список отправляющего сервиса, а ~all означает «остальные отправители подозрительны». Значение include для вашего аккаунта в этом примере условное: настоящее вы увидите в кабинете, когда добавите домен.
DKIM: цифровая подпись письма
DKIM (DomainKeys Identified Mail) добавляет к каждому письму электронную подпись. Приватный ключ хранится у отправителя, а публичная часть публикуется в DNS. Получатель берёт открытый ключ, проверяет подпись и убеждается, что письмо отправлено владельцем домена и по пути не менялось.
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…Имя селектора (selector1 в примере) и ключ p= у каждого сервиса свои, поэтому копируйте их из кабинета целиком. Современным стандартом считается ключ длиной 2048 бит, именно такими подписывает письма SlenderMail.
DMARC: политика и отчёты
DMARC связывает SPF и DKIM с адресом, который пользователь видит в поле «От кого», и задаёт правило для писем, не прошедших проверку. Кроме того, он включает отчёты: почтовые сервисы присылают вам статистику о том, кто и с каких адресов отправлял письма от вашего домена.
v=DMARC1; p=none; rua=mailto:dmarc@example.ruПараметр p — политика, rua — адрес, на который приходят сводные отчёты.
Политика DMARC шаг за шагом
Не включайте строгую политику сразу: можно случайно заблокировать собственные легальные письма.
p=none — наблюдение
Письма не блокируются, но вы получаете отчёты. Несколько недель изучайте их и убедитесь, что все ваши источники почты проходят SPF или DKIM.
p=quarantine — карантин
Письма, не прошедшие проверку, отправляются в спам. Если ложных срабатываний нет, оставьте политику на пару недель.
p=reject — отклонение
Получатели не принимают поддельные письма вовсе. Это самый надёжный уровень защиты домена от подделки.
Частые ошибки
- Две SPF-записи. У домена должна быть ровно одна запись с v=spf1. Если сервисов несколько, объедините их include в одну строку.
- Больше 10 DNS-запросов в SPF. Каждый include и подобные механизмы считаются, и при превышении лимита SPF не проходит. Уберите лишние сервисы.
- Неверное имя хоста. Одни регистраторы просят вписать в поле «Имя» полное selector1._domainkey.example.ru, другие автоматически дописывают домен, и нужно ввести только selector1._domainkey. Иначе получится удвоенное имя.
- Лишние кавычки и переносы. Длинный DKIM-ключ некоторые панели разбивают на части. Значение должно собираться в одну строку без пробелов внутри ключа.
- Не дождались обновления DNS. Новая запись становится видна не мгновенно: время зависит от TTL и регистратора и составляет от нескольких минут до нескольких часов.
- Сразу p=reject. Без этапа наблюдения легко потерять важные письма, например, от CRM или бухгалтерской системы.
Как проверить, что всё работает
Отправьте письмо со своего домена на ящик в Gmail, Яндекс.Почте или другом сервисе и откройте служебные заголовки («Показать оригинал» или «Исходный текст»). Найдите заголовок Authentication-Results: в нём должны быть dkim=pass, spf=pass и dmarc=pass.
Как это делает SlenderMail
Вам не нужно вручную составлять записи. Когда вы добавляете домен, кабинет генерирует точные значения для DKIM, SPF и DMARC и показывает, в какие поля их вставить. Затем страница сама опрашивает DNS и подсвечивает каждую запись, как только она появляется. После подтверждения все письма домена подписываются 2048-битным DKIM-ключом.
Дальше можно создать ящики на домене, отправлять письма сайта по API или подключить CMS к SMTP. Общая последовательность действий описана в инструкции.
Частые вопросы
Что будет, если не настроить DKIM, SPF и DMARC?
Письма с вашего домена, скорее всего, попадут в спам или будут отклонены: крупные почтовые сервисы требуют, чтобы отправитель подтверждал право писать от имени домена.
Нужны ли все три записи или достаточно одной?
Нужны все три. SPF и DKIM подтверждают отправителя разными способами, а DMARC связывает их с адресом в From и задаёт политику для писем, которые проверку не прошли.
Сколько ждать, пока DNS-записи заработают?
Обычно от нескольких минут до нескольких часов. Время зависит от TTL записи и от регистратора, в редких случаях обновление занимает до суток.
Можно ли добавить две SPF-записи?
Нет. У домена должна быть ровно одна TXT-запись SPF, начинающаяся с v=spf1. Если сервисов несколько, их include объединяют в одну запись.
С какой политики DMARC начать?
С p=none: письма не блокируются, а вы получаете отчёты и видите, кто отправляет от имени домена. После исправления ошибок переходят к quarantine, затем к reject.
Как проверить, что всё работает?
Отправьте письмо на ящик в Gmail или другом сервисе и откройте исходный текст: в заголовке Authentication-Results должны быть dkim=pass, spf=pass и dmarc=pass.