[ SPF / DKIM / ALIGNMENT / POLICY ]
DMARC w 2026: SPF i DKIM to nie wszystko
Rekord SPF może przechodzić. Podpis DKIM może być poprawny. A wiadomość nadal może nie przejść DMARC. Powód najczęściej leży w alignment, czyli zgodności domen użytych podczas uwierzytelniania z domeną widoczną dla odbiorcy w polu „Od:”.
Spis treści
/// NA TEJ STRONIEDMARC sprawdza, czy domena widoczna w polu „Od:” jest zgodna z domeną uwierzytelnioną przez SPF lub DKIM. Następnie pozwala właścicielowi domeny opublikować politykę obsługi wiadomości, które tej kontroli nie przejdą.
Co właściwie robi DMARC?
SPF odpowiada przede wszystkim na pytanie, czy dany serwer może wysyłać pocztę dla określonej domeny. DKIM dodaje do wiadomości kryptograficzny podpis, który odbiorca może zweryfikować na podstawie klucza w DNS.
DMARC łączy te mechanizmy z domeną widoczną w nagłówku From. Dzięki temu nie wystarczy, że „jakiś SPF” lub „jakiś DKIM” przejdzie. Musi istnieć również odpowiednia zgodność domen.
Alignment: najczęściej pomijany element DMARC
Domena autora
To domena widoczna dla odbiorcy w nagłówku wiadomości.
SPF alignment
Domena uwierzytelniona przez SPF musi być odpowiednio zgodna z domeną autora.
DKIM alignment
Domena podpisująca DKIM musi być odpowiednio zgodna z domeną autora.
Do przejścia DMARC wystarczy poprawny i zgodny SPF albo poprawny i zgodny DKIM. W praktyce konfiguruję oba, ponieważ różne systemy wysyłające, forwarding i zewnętrzne usługi mogą zachowywać się inaczej.
p=none, quarantine i reject
| Polityka | Znaczenie operacyjne |
|---|---|
| p=none | monitorowanie bez żądania egzekwowania |
| p=quarantine | prośba o potraktowanie błędnej wiadomości jako podejrzanej |
| p=reject | prośba o odrzucenie wiadomości, która nie przejdzie DMARC |
Jak wygląda rekord DMARC?
DMARC publikuje się jako rekord TXT pod nazwą
_dmarc.twojadomena.pl.
v=DMARC1; p=none; rua=mailto:Ten adres pocztowy jest chroniony przed spamowaniem. Aby go zobaczyć, konieczne jest włączenie w przeglądarce obsługi JavaScript. To tylko przykład struktury. Nie kopiuj go bez sprawdzenia, czy skrzynka raportowa, polityka i cały ekosystem wysyłkowy są przygotowane.
Raporty DMARC są narzędziem diagnostycznym
Raporty agregowane pomagają zobaczyć, jakie źródła wysyłają pocztę w imieniu domeny, które przechodzą SPF lub DKIM i gdzie występują problemy z alignment.
Same raporty nie naprawiają konfiguracji. Ich wartość polega na tym, że pokazują ruch, którego właściciel domeny mógł wcześniej nie znać.
Google, Yahoo i Microsoft traktują uwierzytelnianie coraz poważniej
Dla nadawców masowych Gmail wymaga SPF, DKIM i DMARC. Yahoo również wymaga SPF i DKIM oraz poprawnej polityki DMARC co najmniej w trybie monitorującym.
Outlook.com, Hotmail i Live.com wymagają SPF, DKIM i DMARC dla domen wysyłających duże wolumeny.
Bezpieczna kolejność wdrożenia DMARC
Inwentaryzacja źródeł → SPF → DKIM → alignment → p=none + raporty → analiza ruchu → poprawki → stopniowe egzekwowanie polityki.
Dopiero po potwierdzeniu legalnych źródeł rozważam przejście do polityki egzekwującej.
Najczęstsze błędy
Najczęściej spotykam rekord DMARC opublikowany bez sprawdzenia wszystkich nadawców, zewnętrzny system podpisujący własną domeną DKIM, niedopasowany Return-Path, błędny SPF albo politykę zaostrzoną przed zakończeniem monitoringu.
Źródła wykorzystane przy aktualizacji
- IETF - RFC 9989: DMARC, maj 2026.
- IETF - RFC 9990: DMARC Aggregate Reporting.
- Google - Email sender guidelines.
- Yahoo Sender Hub - Sender Best Practices.
- Microsoft - Outlook requirements for high-volume senders.
Data weryfikacji: 2 września 2026 r. Wymagania odbiorców poczty i standardy uwierzytelniania mogą się zmieniać. Przed zmianą polityki DMARC sprawdzam aktualną konfigurację domeny i źródła wysyłki.
[ DNS / MAIL / SECURITY ]
Chcesz uporządkować SPF, DKIM i DMARC bez ryzyka odcięcia legalnej poczty?
Najpierw sprawdzę DNS i wszystkie źródła wysyłki, potem zaproponuję bezpieczną kolejność zmian.