Zgodność domen w DMARC na przykładach nagłówków

spf=pass, dkim=pass, dmarc=fail — to najbardziej mylący wiersz, jaki można znaleźć w nagłówkach wiadomości, i niemal zawsze oznacza to samo: brak zgodności domen (alignment). DMARC nie pyta, czy SPF albo DKIM dały wynik pozytywny. Pyta, czy dały go dla domeny z adresu From.

Ten poradnik pokazuje, jakie domeny niesie wiadomość, jak porównuje je RFC 9989 oraz jak czytać i naprawiać prawdziwe nagłówki.

Trzy domeny w każdej wiadomości

Tożsamość	Gdzie ją widać	Kto ją sprawdza	Przykład
Domena z From (w RFC 9989: Author Domain)	nagłówek From:	DMARC — to ją chroni	example.com
Nadawca koperty (MAIL FROM)	nagłówek Return-Path:; smtp.mailfrom= w Authentication-Results	SPF	bounces.mailer.example.net
Domena podpisu DKIM	d= w DKIM-Signature; header.d= w Authentication-Results	DKIM	mailer.example.net

Wiadomość przechodzi DMARC, gdy spełniony jest co najmniej jeden warunek:

• SPF daje wynik pass i domena nadawcy koperty jest zgodna z domeną z From;
• podpis DKIM się weryfikuje i jego domena d= jest zgodna z domeną z From.

Wiadomość może mieć kilka podpisów DKIM — wystarczy jeden poprawny i zgodny. DMARC bierze pod uwagę tylko wynik SPF dla tożsamości MAIL FROM, a nie osobne sprawdzenie nazwy HELO.

Tryb relaxed i strict

Rekord DMARC ustala tryb osobno dla DKIM (adkim) i SPF (aspf). Domyślnie oba mają wartość r, czyli tryb swobodny (relaxed):

• relaxed — obie domeny mają tę samą domenę organizacyjną;
• strict (s) — obie domeny są identyczne.

Domena uwierzytelniona	Domena z From	Relaxed	Strict
example.com	example.com	zgodne	zgodne
bounce.example.com	example.com	zgodne	niezgodne
example.com	news.example.com	zgodne	niezgodne
mailer.example.net	example.com	niezgodne	niezgodne

Przy porównywaniu wielkość liter nie ma znaczenia. RFC 9989 zauważa, że niemal wszystkim właścicielom domen wystarcza tryb relaxed. Rekord zaostrzający tylko DKIM wygląda tak:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; adkim=s; rua=mailto:dmarc-reports@example.com"

Domena organizacyjna i DNS Tree Walk

W trybie relaxed odbiorca musi ustalić domenę organizacyjną każdej nazwy. RFC 7489 brał ją z Public Suffix List. RFC 9989 zastępuje to metodą DNS Tree Walk: odbiorca odpytuje rekordy _dmarc od danej domeny w górę drzewa, najwyżej ośmioma zapytaniami, i spośród nazw, pod którymi znalazł poprawny rekord DMARC, wybiera tę o najmniejszej liczbie etykiet. Wynik zmieniają dwa tagi:

• psd=n — ta domena jest domeną organizacyjną dla siebie i wszystkiego poniżej;
• psd=y — to sufiks publiczny, a rekord publikuje jego operator (np. rejestr); domeną organizacyjną jest nazwa o jedną etykietę niżej.

Jeśli odbiorca nie znajdzie żadnego rekordu, domena jest swoją własną domeną organizacyjną — a gdy dla domeny z From nie obowiązuje żaden rekord DMARC, DMARC w ogóle nie dotyczy tej wiadomości.

Przykład: wiadomość z From: news.example.com i Return-Path w bounce.example.com, a rekord DMARC tylko pod _dmarc.example.com:

_dmarc.news.example.com    → brak rekordu
_dmarc.example.com         → "v=DMARC1; p=reject; …"
_dmarc.com                 → brak rekordu

Obie nazwy prowadzą do example.com, więc SPF jest zgodny w trybie relaxed. Załóżmy teraz, że dział firmy publikuje "v=DMARC1; p=reject; psd=n" pod _dmarc.dept.example.com. Od tej chwili dept.example.com jest osobną domeną organizacyjną, a poczta z tej domeny podpisana d=example.com nie jest zgodna — nawet w trybie relaxed.

Dla zwykłych domen obie metody dają ten sam wynik. Różnice pojawiają się w strukturach wielopoziomowych i przy tagach psd.

Przykłady z nagłówkami

SPF i DKIM przechodzą, DMARC nie

Newsletter wysłany przez usługę mailingową przed skonfigurowaniem uwierzytelniania domeny:

Return-Path: <bounce-7f3a@bounces.mailer.example.net>
Authentication-Results: mx.example.org;
       spf=pass smtp.mailfrom=bounces.mailer.example.net;
       dkim=pass header.d=mailer.example.net header.s=m1;
       dmarc=fail header.from=example.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailer.example.net; s=m1; …
From: Example Shop <news@example.com>

SPF przeszedł dla bounces.mailer.example.net, DKIM dla mailer.example.net. Żadna z tych domen nie ma wspólnej domeny organizacyjnej z example.com, więc nic nie jest zgodne i DMARC daje fail. Przy p=reject ten legalny newsletter zostałby odrzucony.

Własna domena zwrotna: SPF zgodny

Ta sama usługa po ustawieniu domeny zwrotnej (return-path) w Twojej domenie:

Return-Path: <bounce-7f3a@bounce.example.com>
Authentication-Results: mx.example.org;
       spf=pass smtp.mailfrom=bounce.example.com;
       dkim=pass header.d=mailer.example.net header.s=m1;
       dmarc=pass header.from=example.com
From: Example Shop <news@example.com>

bounce.example.com i example.com mają wspólną domenę organizacyjną, więc SPF jest zgodny w trybie relaxed i DMARC przechodzi. Przy aspf=s wynik byłby negatywny. DMARC opiera się teraz wyłącznie na SPF, a ten zawodzi, gdy tylko wiadomość zostanie przekazana dalej.

Własny podpis DKIM: DKIM zgodny

Usługa podpisuje teraz wiadomości Twoją domeną:

Authentication-Results: mx.example.org;
       spf=pass smtp.mailfrom=bounces.mailer.example.net;
       dkim=pass header.d=example.com header.s=esp1;
       dmarc=pass header.from=example.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=esp1; …
From: Example Shop <news@example.com>

Domena d=example.com jest identyczna z domeną z From, więc DKIM jest zgodny nawet w trybie strict. Od tej poprawki warto zacząć, bo podpis podróżuje razem z wiadomością.

Wiadomość przekazana dalej

Twoja wiadomość przekazana z adresu uczelnianego do prywatnej skrzynki:

Authentication-Results: mx.example.org;
       spf=fail smtp.mailfrom=example.com;
       dkim=pass header.d=example.com header.s=s2026;
       dmarc=pass header.from=example.com

Serwera przekazującego nie ma w Twoim rekordzie SPF, więc SPF daje fail. Jeśli serwer przekazujący przepisuje nadawcę koperty, SPF przejdzie dla jego domeny — która i tak nie jest zgodna. Podpis DKIM przetrwał, więc DMARC przechodzi. Lista dyskusyjna, która zmienia temat albo dopisuje stopkę, psuje także DKIM — i wtedy DMARC zawodzi.

Tryb strict dla DKIM i subdomena w From

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; adkim=s"

Authentication-Results: mx.example.org;
       spf=pass smtp.mailfrom=mailer.example.net;
       dkim=pass header.d=example.com header.s=s2026;
       dmarc=fail header.from=news.example.com

news.example.com nie ma własnego rekordu, więc obowiązuje rekord example.com razem z adkim=s. Domena d=example.com nie jest identyczna z news.example.com, więc DKIM nie jest zgodny. Podpisuj wiadomości z d=news.example.com albo wróć do trybu relaxed dla DKIM.

Jak naprawić brak zgodności

1. Własna domena DKIM u każdego dostawcy. Dostawcy nazywają to uwierzytelnianiem domeny, „custom DKIM” albo „sender authentication”: publikujesz podane przez nich rekordy (często CNAME pod _domainkey), a oni podpisują pocztę z d= ustawionym na Twoją domenę. Zacznij od tego.
2. Własna domena zwrotna. Nazywana też custom return-path, custom MAIL FROM lub domeną odbić: subdomena, np. bounce.example.com, wskazująca na dostawcę, dzięki której SPF przechodzi dla domeny w obrębie Twojej domeny organizacyjnej. Daje zgodność tylko w trybie relaxed.
3. Własne serwery. Podpisuj pocztę swoją domeną i używaj nadawcy koperty w swojej domenie, objętego Twoim rekordem SPF.

Co nie pomaga: dopisanie include: dostawcy do rekordu SPF, gdy usługa wciąż używa własnego nadawcy koperty; poprzestanie na podpisie DKIM domeną dostawcy; zmiana Reply-To, na który DMARC w ogóle nie patrzy.

Sprawdź zgodność samodzielnie

1. Wyślij wiadomość do skrzynki u dużego dostawcy, otwórz jej źródło i wklej nagłówki do narzędzia Analizator nagłówków e-mail. Zobaczysz obok siebie smtp.mailfrom, header.d i domenę z From. Ocena zgodności w analizatorze opiera się na Public Suffix List, więc w rzadkich, wielopoziomowych konfiguracjach odbiorca stosujący RFC 9989 może zdecydować inaczej. Pozostałe nagłówki objaśnia poradnik Jak czytać nagłówki e-mail.
2. Uruchom Sprawdzanie DMARC, by zobaczyć, który rekord obowiązuje dla Twojej domeny z From oraz jakie ma ustawienia adkim i aspf.
3. Czytaj raporty zbiorcze: dla każdego źródła porównuj surowe auth_results z wynikami po sprawdzeniu zgodności w policy_evaluated — zobacz Jak czytać raporty zbiorcze DMARC.

Szerszy obraz współpracy SPF, DKIM i DMARC znajdziesz w poradniku SPF, DKIM i DMARC: czym się różnią i co robią.