DMARC eșuează dar SPF și DKIM trec? Remedierea alinierii (2026)

Publicat 2026-07-08

Date din 2026-06-29 · metodologie v7. Date agregate din recensământul a 261 milioane de domenii clasificate. Consultați cum clasificăm.

DMARC are nevoie de mai mult decât un pass — domeniul care a trecut SPF sau DKIM trebuie să se potrivească cu domeniul dvs. From. Cea mai mare parte a e-mailului „SPF pass, DMARC fail” a trecut SPF pe domeniul de bounce al vendorului, nu al dvs. Doar 7.4% din 261,086,232 domenii clasificate trec SPF cu aliniere sub o politică DMARC aplicată, conform recensământului Defaults.Exposed (2026-06-29).

Remedierea este mai rapidă decât sugerează confuzia. Citiți antetul Authentication-Results pentru a vedea care picior — SPF sau DKIM — trece pe domeniul greșit; apoi activați semnarea DKIM cu domeniu personalizat a serviciului dvs. de trimitere (de obicei câteva CNAMEs și remedierea care supraviețuiește redirecționării), sau setați return-path-ul personalizat astfel încât SPF să treacă pe domeniul dvs. Un picior aliniat este tot ce are nevoie DMARC.

Cum poate eșua DMARC când SPF și DKIM trec amândouă?

Deoarece DMARC nu întreabă niciodată „a trecut SPF?” Întreabă: a trecut SPF sau DKIM pentru un domeniu care se potrivește cu adresa From pe care o vede destinatarul? Acea condiție suplimentară se numește aliniere și este întregul scop al DMARC — fără ea, oricine ar putea trece SPF pe un domeniu pe care îl deține în timp ce afișează al dvs. în antetul From.

Fiecare verificare autentifică un domeniu diferit:

Verificare	Domeniul pe care îl evaluează de fapt	Unde se vede
SPF	Return-Path (RFC5321.MailFrom, adresa de bounce/envelope-from) — nu antetul From	`smtp.mailfrom=` în Authentication-Results
DKIM	Domeniul din tagul `d=` al semnăturii — orice a ales semnatarul	`header.d=` în Authentication-Results
DMARC	*Domeniul dvs. din antetul From — și cere ca domeniul SPF sau* `d=` DKIM să se potrivească cu el**	`header.from=` în Authentication-Results

Iată cum merg de obicei prost lucrurile: platforma dvs. de newsletter sau CRM trimite cu un Return-Path precum [email protected], SPF este verificat față de vendor.com și trece, DKIM trece cu d=vendor.com — și DMARC eșuează, deoarece niciun domeniu care a trecut nu se potrivește cu yourcompany.com. Fiecare verificare a spus adevărul; niciuna nu v-a autentificat pe dvs. Editarea propriei înregistrări SPF nu poate repara asta — nu a fost niciodată consultată. Este aceeași capcană acoperită în SPF eșuează pentru instrumentele SaaS.

Recensământul arată cât de puțini expeditori finalizează acest ultim pas: 27,640,987 din 261,086,232 domenii clasificate (10.59%) au o politică DMARC aplicată deloc, și doar 7.4% trec SPF cu aliniere sub una. Dintre cele 77.5 milioane de domenii al căror SPF se termină în softfail (~all), doar 9.2% stau sub o politică DMARC aplicată; dintre publicatorii hardfail (-all), 12,142,351 sunt aplicate în timp ce 42,514,532 nu sunt. Cele mai multe domenii se opresc la „SPF trece” — care, fără DMARC care să acționeze pe el, nu protejează aproape nimic.

Cum citesc Authentication-Results pentru a vedea care picior este nealiniat?

Trimiteți-vă un mesaj prin serviciul care eșuează, deschideți sursa brută și găsiți antetul Authentication-Results. Un rezultat nealiniat tipic arată astfel:

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

Citiți-l în trei comparații:

Piciorul SPF: se termină smtp.mailfrom= în domeniul dvs.? Aici este bounces.espmail.net — nealiniat.
Piciorul DKIM: se termină header.d= în domeniul dvs.? Aici este espmail.net — nealiniat.
Verdictul DMARC: header.from= este domeniul pe care îl apără DMARC. Niciunul dintre picioare nu s-a potrivit cu el, deci dmarc=fail — chiar dacă ambele verificări individuale spun pass.

Oricare picior implică deja propriul dvs. domeniu (sau poate fi făcut să o facă) este cel de reparat. Aveți nevoie de unul singur.

Care este diferența dintre alinierea relaxed și cea strictă?

DMARC oferă două moduri de potrivire, setate cu tagurile aspf (SPF) și adkim (DKIM) din înregistrarea dvs. DMARC:

Relaxed (r, valoarea implicită): cele două domenii trebuie să împărtășească același domeniu organizațional — domeniul înregistrabil per Public Suffix List. bounce.yourcompany.com se aliniază cu yourcompany.com; la fel și un DKIM d=mail.yourcompany.com. De aceea funcționează return-path-urile personalizate ale vendorilor și DKIM personalizat, care se află pe subdomenii.
Strict (s): domeniile trebuie să se potrivească exact, caracter cu caracter. bounce.yourcompany.com nu se mai aliniază cu yourcompany.com.

Dacă înregistrarea dvs. nu menționează aspf sau adkim, sunteți în modul relaxed — și aproape sigur doriți să rămâneți acolo. Modul strict nu adaugă securitate semnificativă pentru cei mai mulți expeditori și strică silențios fiecare expeditor legitim pe subdomeniu pe care l-ați configurat. Dacă DMARC eșuează și înregistrarea dvs. conține aspf=s sau adkim=s, aceea singură poate fi eroarea.

Cum remediez alinierea DMARC?

Rulați scanarea gratuită la defaults.exposed înainte de a atinge DNS-ul. Arată înregistrarea și politica DMARC, dacă SPF și DKIM sunt configurate să se alinieze și ce altceva este stricat — astfel reparați mai întâi piciorul corect.
Testați fiecare serviciu de trimitere și citiți Authentication-Results (ca mai sus). Listați fiecare sursă — furnizor de căsuță poștală, instrument de newsletter, CRM, aplicație de facturare — și notați per sursă dacă smtp.mailfrom și header.d sunt domeniul dvs. sau al vendorului.
Activați semnarea DKIM cu domeniu personalizat pentru fiecare vendor — remedierea care durează. Fiecare serviciu de trimitere serios oferă „autentificarea domeniului”: câteva înregistrări CNAME care îi permit să semneze ca d=yourcompany.com (sau un subdomeniu, care se aliniază în modul relaxed). DKIM aliniat este de obicei remedierea mai ușoară și singura care supraviețuiește redirecționării, deoarece redirecționarea strică SPF prin design.
Pentru alinierea SPF, activați return-path-ul personalizat al vendorului (adesea numit domeniu de bounce personalizat) — de obicei un CNAME precum bounce.yourcompany.com pointând la vendor. SPF trece atunci pe domeniul dvs. organizațional și se aliniază. Faceți asta unde este oferit, dar tratați-l ca al doilea picior, nu un substitut pentru DKIM aliniat.
Lăsați alinierea în modul relaxed dacă nu aveți un motiv specific și înțeles pentru aspf=s/adkim=s.
Re-scanați și confirmați ambele picioare, apoi avansați spre aplicare. O politică DMARC de p=none raportează dar nu blochează nimic; odată ce expeditorii dvs. reali se aliniază, calea completă spre o politică care vă protejează este pe pagina corectați DMARC, iar ghidurile furnizorilor precum DMARC pe IONOS acoperă clicurile din panoul DNS.

Ar trebui să repar alinierea SPF sau alinierea DKIM?

Aveți nevoie de un picior aliniat per sursă de trimitere. Dacă puteți face doar unul, alegerea nu este grea:

Remediere	Ce implică	Supraviețuiește redirecționării?
DKIM aliniat (semnare cu domeniu personalizat)	Câteva CNAMEs în panoul „domain authentication” al vendorului	Da — semnătura călătorește cu mesajul
SPF aliniat (return-path/bounce domain personalizat)	Un CNAME, unde oferă vendul	Nu — IP-ul oricărui forwarder înlocuiește pe cel al vendorului

Cazul special de știut: Google Workspace și Microsoft 365 vor semna DKIM e-mailul dvs. implicit cu propriile domenii de rezervă (gappssmtp.com, onmicrosoft.com) — deci DKIM arată pass în timp ce DMARC eșuează totuși. Este cea mai frecventă instanță specifică a întregii probleme și are propriul ghid: DKIM trece dar DMARC tot eșuează: capcana semnăturii implicite.

Întrebări frecvente

Trebuie ambele SPF și DKIM să se alinieze pentru ca DMARC să treacă? Nu — un singur pass aliniat este suficient. Cea mai bună practică este să le aliniați pe amândouă oricum, astfel încât când redirecționarea strică piciorul SPF, piciorul DKIM să poarte totuși pass-ul DMARC. Din 261,086,232 domenii clasificate în recensământul 2026-06-29, doar 3.87% completează triada completă SPF + DMARC + DKIM.

Tabloul de bord ESP spune că SPF și DKIM sunt „verificate” — de ce eșuează totuși DMARC? „Verificat” înseamnă de obicei că trimiterea proprie a vendorului trece pe domeniile vendorului. Dacă nu ați finalizat pașii lor de domeniu personalizat (CNAMEs DKIM, return-path personalizat), e-mailul se autentifică ca vendor, nu ca dvs. — iar DMARC compară față de domeniul dvs. From.

Un record SPF strict -all este suficient fără aliniere? Nu. Un calificator strict întărește verdictul SPF pe domeniul Return-Path, dar DMARC tot trebuie ca acel domeniu să fie al dvs. Din recensământul 2026-06-29, doar 12,142,351 din domeniile care publică -all stau sub o politică DMARC aplicată — celelalte 42,514,532 au o înregistrare strictă pe care nicio politică nu acționează.

Ar trebui să trec la alinierea strictă (aspf=s/adkim=s) pentru mai multă securitate? Aproape niciodată. Alinierea relaxed cere deja același domeniu înregistrabil, pe care un falsificator nu îl controlează. Modul strict în principal strică propriii expeditori pe subdomeniu — verificați-l ori de câte ori alinierea eșuează neașteptat.

DMARC eșuează doar pe e-mailul pe care destinatarii îl redirecționează — aceeași reparație? Acela este piciorul SPF care moare în tranzit: serverul forwarderului nu se află în niciun record SPF pentru return-path-ul dvs. Nu puteți remedia SPF pentru e-mailul redirecționat; DKIM aliniat este răspunsul, deoarece semnătura supraviețuiește redirecționării intacte. Detalii în e-mailul redirecționat eșuează SPF.

Trimiteți proprietarului raportul

Dacă reparați asta pentru un client sau angajatorul dvs., încheiați cu dovezi. Re-rulați scanarea gratuită după ce CNAMEs-urile intră în vigoare și trimiteți raportul clasificat proprietarului afacerii: datat, limbaj simplu, arătând SPF, DKIM și DMARC aliniate și trecând. Acesta este artefactul de care vor avea nevoie pentru reînnoirea asigurării cibernetice și pentru următorul chestionar de securitate al furnizorilor — dovada unei configurații funcționale, nu doar „am adăugat niște înregistrări DNS”.

Verificați domeniul → · DKIM trece dar DMARC tot eșuează → · Corectați DMARC → · Cum clasificăm → · Doar date agregate. Date stocate și procesate în UE.