Фишинговые письма могут уходить от имени вашего домена без вашего ведома. SPF / DKIM / DMARC останавливают это. Вот роль каждого и как настроить их безопасно.
Роль каждого
| Настройка | Роль (в одну строку) |
|---|---|
| SPF | Объявляет в DNS, какие серверы могут отправлять для этого домена |
| DKIM | Добавляет криптографическую подпись, доказывающую, что письмо не изменено и от легитимного источника |
| DMARC | Объявляет, что делать, если SPF/DKIM не прошли, и получает отчёты (настройка, связывающая все три вместе) |
Все три — текстовые (TXT) записи в DNS. Для example.com они выглядят так (значения — примеры).
| Настройка | Куда пишется | Пример значения |
|---|---|---|
| SPF | example.com | v=spf1 include:_spf.mail-service.example ~all |
| DKIM | selector._domainkey.example.com | v=DKIM1; k=rsa; p=(открытый ключ от вашего сервиса отправки) |
| DMARC | _dmarc.example.com | v=DMARC1; p=none; rua=mailto:dmarc@example.com |
Для include: в SPF используйте значение, которое указывает ваш сервис отправки почты. Открытый ключ DKIM тоже выдаёт сервис отправки, создавать его самому не нужно.
Как почта проверяется
Получатели (Gmail и т. п.) проверяют SPF и DKIM на входящем сообщении, затем применяют вашу политику DMARC, чтобы решить «пропустить / в карантин / отклонить».
Так что SPF и DKIM сами по себе могут «проверять, но ничего не делать»; только с политикой DMARC они действительно «останавливают подделку».
Что упускают: соответствие доменов
Ключ к решению DMARC — совпадение доменов. DMARC проходит, только если домен отправителя, который получатель видит в почтовой программе (заголовок From), совпадает с доменом, проверенным SPF или DKIM.
SPF проверяет не видимого отправителя, а домен скрытого отправителя конверта, который используется при доставке. Поэтому атакующий может пройти SPF со своим доменом, указав ваш домен только в поле From. Если SPF проходит, но не совпадает с доменом From, а DKIM тоже не даёт совпадения, DMARC признаёт письмо непрошедшим. Именно эта проверка совпадения и позволяет DMARC останавливать подделку адреса From.
Как настроить их безопасно
Одна корректная запись SPF
Авторизуйте каждого легитимного отправителя (свои серверы, почтовые сервисы и т. п.). Держите одну запись SPF на домен (несколько записей обычно её ломают).
Включите подписание DKIM
Включите DKIM в вашей почтовой платформе и опубликуйте открытый ключ в DNS, чтобы легитимная почта подписывалась.
Начните DMARC с p=none
Не отклоняйте сразу. Начните с p=none (только мониторинг) + отчётность, чтобы убедиться, что легитимная почта не отбрасывается.
Ужесточайте постепенно
Когда отчёты покажут, что ни один легитимный отправитель не упущен, переходите p=quarantine → p=reject, в итоге достигнув состояния «подделка отклоняется».
«Ровно одна» в шаге 1 идёт из спецификации. RFC 7208 говорит, что если у домена больше одной записи SPF, результат — permerror (постоянная ошибка). Та же спецификация ограничивает DNS-запросы от include и подобных механизмов десятью на всю проверку; превышение — тоже permerror. Добавляя почтовый сервис, дописывайте его в существующую единственную запись, а не добавляйте новую.
Частые ошибки
| Ошибка | Что происходит | Как исправить |
|---|---|---|
| Две записи SPF | SPF возвращает permerror | Объединить их в одну |
Слишком много вложенных include | DNS-запросов больше 10 → permerror | Удалить include неиспользуемых сервисов |
| DKIM не включён в сервисе отправки | Письма из этого сервиса не проходят DMARC | Включить DKIM в сервисе и опубликовать в DNS |
| DMARC оставлен на p=none | Поддельные письма продолжают проходить | Читать отчёты и поднять до reject |
| Ничего не настроено на домене, который не отправляет почту | Подделку от имени неиспользуемого домена не остановить | Опубликовать v=spf1 -all и DMARC p=reject |
Как проверить свой домен
- Введите свой домен в проверку SPF / DKIM / DMARC, чтобы увидеть, есть ли все три записи и что в них не так
- Чтобы посмотреть напрямую из командной строки, выполните
dig +short TXT example.com(SPF) иdig +short TXT _dmarc.example.com(DMARC) - Отправьте письмо со своего домена на адрес Gmail и через «Показать оригинал» в Gmail убедитесь, что у
SPF,DKIMиDMARCстоитPASS - Когда начнут приходить отчёты DMARC (rua), раз в неделю проверяйте, нет ли незнакомых отправителей
Для сайта, владение которым вы подтвердили, аудит безопасности сайта проверяет это вместе с настройками на стороне веба.
Реальный случай: поддельное письмо «с вашего же адреса»
«Мне пришло письмо с угрозами с моего же адреса на мой адрес» — типичный случай, о котором предупреждали японский IPA и другие. Чаще всего это не взлом аккаунта: просто переписано поле отправителя. Поскольку отправитель может написать в этом поле что угодно, такие письма могут попадать во входящие для доменов, которые не подняли DMARC до reject. Как распознать и что делать, разобрано здесь:
- Спам с вашего собственного адреса (за пять минут убедиться, взломали ли вас; на английском)
- Поддельная почта от имени вашего домена (как читать заголовки и как остановить это с помощью SPF, DKIM и DMARC)
Обновление спецификации (май 2026 г.)
В мае 2026 года DMARC был пересмотрен как RFC 9989, который заменяет прежний RFC 7489. Три политики — p=none, p=quarantine и p=reject — не изменились. Что изменилось: тег pct (доля применения) удалён и заменён тегом t, обозначающим тестовый режим, а также добавлен тег np для политики в отношении несуществующих поддоменов. Существующие записи не перестанут работать в одночасье, но при написании новой не используйте pct.
Мнение этого сайта: вы также защищаете своих пользователей
SPF/DKIM/DMARC — это не только про доставку вашей почты; это ещё и защита ваших пользователей от фишинга, выдающего себя за ваш домен. Фишинг в конечном счёте — это способ кражи учётных данных и ключей. Многие домены останавливаются на SPF/DKIM и никогда не поднимают DMARC до принуждения (reject). Не останавливайтесь на p=none; читайте отчёты и поднимайте до самого reject, чтобы это имело смысл.
Источники (первичные)
- IETF RFC 7208, «Sender Policy Framework (SPF)» — datatracker.ietf.org (одна запись на домен; не более 10 DNS-запросов)
- IETF RFC 6376, «DomainKeys Identified Mail (DKIM) Signatures» — datatracker.ietf.org
- IETF RFC 9989, «Domain-Based Message Authentication, Reporting, and Conformance (DMARC)» (май 2026 г.; заменяет RFC 7489) — datatracker.ietf.org
- Google, «Email sender guidelines» — support.google.com (требования с 1 февраля 2024 г.; требования к отправителям 5000+ писем в день)
Читать дальше
- Что делать: Как распознать и остановить поддельную почту · Спам с вашего собственного адреса (на английском)
- Основы: Чем опасны .env и API-ключи (защита учётных данных)
- Глоссарий: Что такое фишинг · Что такое .env
- Инструмент: Проверка SPF / DKIM / DMARC