DMARC nie przechodzi, ale SPF i DKIM tak? Naprawa wyrównania (2026)

Opublikowano 2026-07-08

Dane z 2026-06-29 · metodologia v7. Zagregowane dane ze spisu 261 milionów ocenionych domen. Zobacz jak oceniamy.

DMARC potrzebuje więcej niż zaliczenia — domena, która zaliczyła SPF lub DKIM, musi pasować do Twojej domeny From. Większość poczty „SPF pass, DMARC fail” zaliczyła SPF na domenie bounce dostawcy, nie Twojej. Tylko 7,4% z 261 086 232 ocenionych domen przechodzi SPF z wyrównaniem pod wymuszającą polityką DMARC, zgodnie ze spisem Defaults.Exposed (2026-06-29).

Naprawa jest szybsza niż sugeruje zamieszanie. Odczytaj nagłówek Authentication-Results, żeby zobaczyć, która noga — SPF czy DKIM — przechodzi na złej domenie; a następnie albo włącz podpisywanie DKIM z własną domeną w swojej usłudze wysyłkowej (zazwyczaj kilka CNAME i naprawa, która przeżywa przekazywanie), albo ustaw jej niestandardowy return-path, żeby SPF przechodziło na Twojej domenie. DMARC potrzebuje tylko jednej wyrównanej nogi.

Jak DMARC może nie przechodzić, gdy SPF i DKIM oboje przechodzą?

Ponieważ DMARC nigdy nie pyta „czy SPF przeszło?” Pyta: czy SPF lub DKIM przeszło dla domeny pasującej do adresu From, który widzi odbiorca? Ten dodatkowy warunek to wyrównanie, i to jest cały cel DMARC — bez niego, każdy mógłby przejść SPF na domenie, którą posiada, wyświetlając jednocześnie Twoją domenę w nagłówku From.

Każda kontrola uwierzytelnia inną domenę:

Kontrola	Domena, którą faktycznie ocenia	Gdzie ją zobaczyć
SPF	Return-Path (RFC5321.MailFrom, adres bounce/envelope-from) — nie nagłówek From	`smtp.mailfrom=` w Authentication-Results
DKIM	Domena w tagu `d=` podpisu — cokolwiek wybrał podpisujący	`header.d=` w Authentication-Results
DMARC	*Twoja domena w nagłówku From — i wymaga, żeby domena SPF lub* `d=` DKIM do niej pasowała**	`header.from=` w Authentication-Results

Oto jak zazwyczaj idzie to nie tak: Twoja platforma newslettera lub CRM wysyła z Return-Path jak [email protected], SPF jest sprawdzany względem vendor.com i przechodzi, DKIM przechodzi z d=vendor.com — i DMARC nie przechodzi, bo żadna z zaliczonych domen nie pasuje do yourcompany.com. Każda kontrola powiedziała prawdę; żadna z nich nie uwierzytelniła Ciebie. Edytowanie własnego rekordu SPF tego nie naprawi — nigdy nie był konsultowany. To ta sama pułapka opisana w SPF nie przechodzi dla narzędzi SaaS.

Spis pokazuje, jak mało nadawców wykonuje ten ostatni krok: 27 640 987 z 261 086 232 ocenionych domen (10,59%) w ogóle ma wymuszającą politykę DMARC, a tylko 7,4% przechodzi SPF z wyrównaniem pod jedną. Spośród 77,5 milionów domen, których SPF kończy się na softfail (~all), tylko 9,2% działa pod wymuszającą polityką DMARC; spośród wydawców hardfail (-all), 12 142 351 jest wymuszone, a 42 514 532 nie. Większość domen zatrzymuje się na „SPF przechodzi” — co bez DMARC działającego na tym, chroni prawie nic.

Jak odczytać Authentication-Results, żeby zobaczyć, która noga nie jest wyrównana?

Wyślij do siebie wiadomość przez nieprzechodzącą usługę, otwórz źródło surowe i znajdź nagłówek Authentication-Results. Typowy niesekwencjonowany wynik wygląda tak:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=bounces.espmail.net;
       dkim=pass header.d=espmail.net;
       dmarc=fail (p=NONE) header.from=yourcompany.com

Odczytaj to w trzech porównaniach:

Noga SPF: czy smtp.mailfrom= kończy się Twoją domeną? Tutaj to bounces.espmail.net — niesekwencjonowane.
Noga DKIM: czy header.d= kończy się Twoją domeną? Tutaj to espmail.net — niesekwencjonowane.
Werdykt DMARC: header.from= to domena, którą DMARC broni. Żadna noga jej nie pasowała, więc dmarc=fail — nawet jeśli obie indywidualne kontrole mówią pass.

Którąkolwiek noga już zawiera Twoją własną domenę (lub może zostać do tego doprowadzona) jest tą do naprawy. Potrzebujesz tylko jednej.

Jaka jest różnica między luźnym a ścisłym wyrównaniem?

DMARC oferuje dwa tryby dopasowania, ustawiane tagami aspf (SPF) i adkim (DKIM) w Twoim rekordzie DMARC:

Luźny (r, domyślny): dwie domeny muszą dzielić tę samą domenę organizacyjną — domenę możliwą do zarejestrowania wg Public Suffix List. bounce.yourcompany.com wyrównuje się z yourcompany.com; tak samo DKIM d=mail.yourcompany.com. Dlatego niestandardowe return-paths i niestandardowy DKIM dostawców, które działają na subdomenach, działają.
Ścisły (s): domeny muszą pasować dokładnie, znak po znaku. bounce.yourcompany.com już nie wyrównuje się z yourcompany.com.

Jeśli Twój rekord nie wspomina aspf lub adkim, jesteś w trybie luźnym — i prawie na pewno powinieneś tam zostać. Tryb ścisły nie dodaje żadnego znaczącego bezpieczeństwa dla większości nadawców i po cichu psuje każdego legalnego nadawcę subdomen, którego skonfiguruje. Jeśli DMARC nie przechodzi i Twój rekord zawiera aspf=s lub adkim=s, to samo w sobie może być błędem.

Jak naprawić wyrównanie DMARC?

Uruchom bezpłatne skanowanie na defaults.exposed przed dotykaniem DNS. Pokazuje Twój rekord DMARC i politykę, czy Twój SPF i DKIM są skonfigurowane do wyrównania i co jeszcze jest zepsute — żebyś naprawił najpierw właściwą nogę.
Przetestuj każdą usługę wysyłkową i odczytaj jej Authentication-Results (jak powyżej). Wylistuj każde źródło — dostawca skrzynki, narzędzie do newsletterów, CRM, aplikacja do fakturowania — i zanotuj dla każdego źródła, czy smtp.mailfrom i header.d to Twoja domena czy domena dostawcy.
Włącz podpisywanie DKIM z własną domeną dla każdego dostawcy — naprawa, która trwa. Każda poważna usługa wysyłkowa oferuje „uwierzytelnianie domeny”: kilka rekordów CNAME, które pozwalają jej podpisywać jako d=yourcompany.com (lub subdomenę, która wyrównuje w trybie luźnym). Wyrównany DKIM jest zazwyczaj łatwiejszą naprawą i jedyną, która przeżywa przekazywanie, bo przekazywanie z założenia niszczy SPF.
Dla wyrównania SPF, włącz niestandardowy return-path dostawcy (często nazywany niestandardową domeną bounce) — zazwyczaj jeden CNAME jak bounce.yourcompany.com wskazujący na dostawcę. SPF przechodzi wtedy na Twojej organizacyjnej domenie i wyrównuje. Rób to gdzie jest oferowane, ale traktuj to jako drugą nogę, a nie zastępstwo wyrównanego DKIM.
Zostaw wyrównanie w trybie luźnym chyba że masz konkretny, rozumiany powód dla aspf=s/adkim=s.
Ponów skanowanie i potwierdź obie nogi, a następnie zmierzaj do wymuszania. Polityka DMARC p=none raportuje ale nic nie blokuje; gdy Twoi prawdziwi nadawcy się wyrównają, pełna ścieżka do polityki, która Cię chroni, jest na stronie naprawy DMARC, a przewodniki dla dostawców jak DMARC w IONOS opisują kliknięcia w panelu DNS.

Czy powinienem naprawić wyrównanie SPF czy DKIM?

Potrzebujesz jednej wyrównanej nogi na jedno źródło wysyłkowe. Jeśli możesz zrobić tylko jedno, wybór nie jest trudny:

Naprawa	Co wymaga	Przeżywa przekazywanie?
Wyrównany DKIM (podpisywanie z własną domeną)	Kilka CNAME w panelu „uwierzytelniania domeny” dostawcy	Tak — podpis podróżuje z wiadomością
Wyrównany SPF (niestandardowy return-path/domena bounce)	Jeden CNAME, gdzie dostawca go oferuje	Nie — IP każdego przekazującego zastępuje IP dostawcy

Szczególny przypadek wart poznania: Google Workspace i Microsoft 365 będą domyślnie podpisywać DKIM Twoją pocztę własnymi domenami zapasowymi (gappssmtp.com, onmicrosoft.com) — więc DKIM pokazuje pass, a DMARC nadal nie przechodzi. To najczęstszy konkretny przypadek całego tego problemu i ma własny przewodnik: DKIM przechodzi, ale DMARC nadal nie: pułapka domyślnego podpisu.

Często zadawane pytania

Czy zarówno SPF jak i DKIM muszą się wyrównywać, żeby DMARC przeszło? Nie — jedno wyrównane zaliczenie wystarczy. Najlepsza praktyka to wyrównywanie obu tak czy inaczej, żeby gdy przekazywanie niszczy nogę SPF, noga DKIM nadal niosła zaliczenie DMARC. Spośród 261 086 232 domen ocenionych w spisie 2026-06-29, tylko 3,87% wypełnia pełną triadę SPF + DMARC + DKIM.

Dashboard mojego ESP mówi, że SPF i DKIM są „zweryfikowane” — dlaczego DMARC nadal nie przechodzi? „Zweryfikowane” zazwyczaj oznacza, że własne wysyłanie dostawcy przechodzi na domenach dostawcy. Jeśli nie wykonałeś kroków niestandardowej domeny (CNAME DKIM, niestandardowy return-path), poczta uwierzytelnia się jako dostawca, a nie jako Ty — a DMARC porównuje względem Twojej domeny From.

Czy ścisły rekord SPF -all wystarczy bez wyrównania? Nie. Ścisły kwalifikator wzmacnia werdykt SPF dla domeny Return-Path, ale DMARC nadal potrzebuje, żeby ta domena była Twoja. Według spisu 2026-06-29, tylko 12 142 351 z domen publikujących -all działa pod wymuszającą polityką DMARC — pozostałe 42 514 532 mają ścisły rekord, na który żadna polityka nie działa.

Czy powinienem przejść na ścisłe wyrównanie (aspf=s/adkim=s) dla większego bezpieczeństwa? Prawie nigdy. Luźne wyrównanie już wymaga tej samej domeny możliwej do zarejestrowania, której spoofer nie kontroluje. Tryb ścisły głównie psuje własnych nadawców subdomen — sprawdź go za każdym razem, gdy wyrównanie niespodziewanie nie przechodzi.

DMARC nie przechodzi tylko dla poczty, którą odbiorcy przekazują — ta sama naprawa? To noga SPF umierająca w tranzycie: IP przekazującego nie ma w czyimkolwiek rekordzie SPF dla Twojego return-path. Nie możesz naprawić SPF dla przekazywanej poczty; wyrównany DKIM jest odpowiedzią, bo podpis przeżywa przekazywanie nienaruszony. Szczegóły w przekazywana poczta nie przechodzi SPF.

Wyślij właścicielowi raport

Jeśli naprawiasz to dla klienta lub pracodawcy, zamknij pętlę z dowodem. Ponów bezpłatne skanowanie gdy CNAME są aktywne i prześlij oceniony raport właścicielowi firmy: z datą, w prostym języku, pokazujący SPF, DKIM i DMARC wyrównane i przechodzące. To artefakt, który będzie mu potrzebny przy przedłużeniu ubezpieczenia cybernetycznego i kolejnym kwestionariuszu bezpieczeństwa dostawcy — dowód działającej konfiguracji, a nie tylko „dodałem kilka rekordów DNS”.

Sprawdź swoją domenę → · DKIM przechodzi, ale DMARC nadal nie → · Napraw DMARC → · Jak oceniamy → · Tylko dane zagregowane. Dane przechowywane i przetwarzane w UE.