SPF
SPF (Sender Policy Framework, RFC 7208) — DNS-запись перечисляющая какие серверы имеют право отправлять почту от имени домена. Получатель проверяет: пришло ли сообщение от указанного IP. Первая линия защиты от подделки отправителя. Работает с 2006.
Как записывается
Обычная TXT-запись в DNS:
example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.10 include:_spf.google.com ~all"
Разбор:
- v=spf1 — версия (только эта существует).
- ip4:, ip6: — «эти IP имеют право».
- include: — «также подтяни SPF по этому домену».
- a, mx — «A-записи домена / MX-записи имеют право».
- ~all — «всё остальное — softfail». Или
-all(fail),?all(neutral),+all(pass, никогда не используй).
Механизмы
| Механизм | Значение |
|---|---|
| all | Совпадает всегда. Обычно последний |
| ip4:1.2.3.0/24 | IPv4-сеть |
| ip6:2001:db8::/32 | IPv6-сеть |
| a / a:host.com | A/AAAA-записи хоста |
| mx / mx:host.com | MX-записи |
| ptr (deprecated) | Rdns-имя оканчивается на этот суффикс. Не используй — медленно и небезопасно |
| exists:host.com | A-запись существует |
| include:domain.com | Рекурсивно подтянуть SPF от domain.com |
Квалификаторы
| Префикс | Результат |
|---|---|
| + (по умолчанию) | Pass — принять |
| - | Fail — отклонить |
| ~ | SoftFail — принять, но пометить |
| ? | Neutral |
Reserved 10 lookups
Ключевое ограничение SPF — не более 10 DNS-lookups при проверке. Каждый include:, a, mx, ptr, exists потребляет lookup. Превысил → PermError, письмо отклонено.
Частая ловушка — include:_spf.google.com сам по себе тратит несколько lookups. Комбо из Google + Mailchimp + SendGrid + свой сервер = легко перебор.
Инструменты проверки
$ dig +short TXT example.com | grep spf
"v=spf1 ip4:1.2.3.4 include:_spf.google.com ~all"
# Онлайн:
# https://mxtoolbox.com/spf.aspx
# https://easydmarc.com/tools/spf-lookup
# Проверить сколько lookups:
# https://www.dmarcanalyzer.com/spf/checker/
Return-Path vs From
Важно. SPF проверяет домен из envelope-from (SMTP MAIL FROM), не из заголовка From:. Это два разных поля:
SMTP:
MAIL FROM: <bounce@service.example.com> ← SPF проверяет этот
DATA:
From: alice@example.com ← Пользователь видит этот
Отсюда phishing-технология: envelope-from от разрешённого bounce@evil.com (SPF pass), а From: подделан на ceo@bank.com. Юзер видит «CEO банка», SPF pass. Против этого — DMARC alignment.
Проблема с форвардингом
Классический сценарий:
- Alice шлёт с
alice@example.comнаbob@forward.com. - Bob настроил forwarding:
bob@forward.com → bob@gmail.com. - Forward.com пересылает письмо, но с оригинальным Return-Path
alice@example.com. - Gmail проверяет SPF: пришло с IP forward.com, но envelope-from example.com. SPF fail.
Решения:
- SRS (Sender Rewriting Scheme) — forwarder переписывает envelope-from на свой (
SRS0=hash=alice=example.com@forward.com). - ARC — цепочка подписей fresh at each hop.
Пример конфигов
# Только один свой сервер
"v=spf1 ip4:1.2.3.4 -all"
# Google Workspace
"v=spf1 include:_spf.google.com ~all"
# Google + Mailchimp
"v=spf1 include:_spf.google.com include:servers.mcsv.net ~all"
# Домен вообще не отправляет почту
"v=spf1 -all"
Тонкости
- -all vs ~all.
-allстроже. Многие используют~allчтобы не терять письма при ошибке SPF. С DMARC — можно смело-all. - Subdomains. SPF на
example.comНЕ распространяется наmail.example.com. Нужна отдельная запись (или DMARC с политикой домена). - Multiple SPF records. Домен может иметь только одну SPF-запись. Две = PermError.