An SPF pass svar på om en avsender-IP var autorisert for den evaluerte SPF identiteten. DMARC stiller et tilleggsspørsmål: stemmer den autentiserte identiteten med domenet i From? An samlet rapport kan derfor vise rå SPF pass og en SPF-relatert DMARC feil uten å motsi seg selv.
Identifiser domenet SPF som er autentisert
Referanser: RFC 9990 §3.1.1.13, RFC 7208 §2.4, RFC 9989 §4.4.2.
Les auth_results/spf/domene og resultat sammen. Inspiser identifikatorer/header_from, eventuell konvolutt_fra og det rapporterte omfanget. Ikke anta at SPF sjekket det synlige Fra-domenet. RFC 7208 definerer POST FRA identitet, mens RFC 9989 bruker denne identiteten for SPF bidrag til DMARC .
For en null omvendt bane, definerer SPF en MAIL FROM-identitet ved å bruke postmaster på HELO domene. Det spesielle tilfellet bør ikke bli en regel om at et uavhengig HELO pass tilfredsstiller DMARC . Nåværende RFC 9990 rapportering tillatelser mfrom som SPF omfanget; eldre rapportformater kan avdekke ulike felt og trenger eksplisitt tolkning.
Bruk riktig justeringsmodus
Referanser: RFC 9989 §3.2.10.2, RFC 9989 §4.10.2, RFC 9990 §3.1.1.9.
Strenge SPF justering krever at det autentiserte domenet samsvarer nøyaktig med forfatterdomenet. Avslappet justering tillater forholdet som er definert gjennom gjeldende organisasjonsdomeneregler. Ikke beregn det bare ved å fjerne et fast antall etiketter: offentlig suffiks og informasjon om policy-oppdagelse betyr noe.
SPF verdien under rad/policy_evaluert uttrykker det DMARC-relaterte resultatet, ikke et duplikat av det rå SPF resultatet. En råfeil eller feil kan ikke bli en vellykket SPF -bane bare fordi domenenavnene ligner hverandre. Autentisering må lykkes i tillegg til å justere.
Arbeid gjennom to kontrasterende rader
Referanser: RFC 9989 §5.3.5.
Anta gjeldende gyldige retningslinjer, fullførte kontroller og urelaterte organisasjonsdomener for brand.example og vendor.example . Syntetisk rad A bruker header_from= brand.example , MAIL FROM= vendor.example og raw SPF =pass. Den urelaterte identiteten stemmer ikke overens, så policy_evaluated/ spf=fail forventes. Å legge til en leverandør-IP til brand.example sin SPF endrer ikke identiteten som denne ruten faktisk evaluerer.
Syntetisk rad B bruker header_from= brand.example og MAIL FROM= bounce.brand.example med rå SPF =pass. Anta at den aktuelle oppdagelsen av organisasjonsdomene plasserer dem sammen. Avslappet SPF justering kan passere, mens streng SPF justering mislykkes fordi navnene er forskjellige. Dette er illustrative feltarmaturer, ikke observert trafikk.
For hver rad, inspiser justert DKIM før de konkluderte med at DMARC som helhet mislyktes. En pasning på linje DKIM signatur kan gi den vellykkede DMARC banen uavhengig av SPF .
Velg en reparasjon som endrer det mislykkede laget
Referanser: RFC 7208 §10.3.
Hvis rå SPF mislykkes, undersøk autorisasjonen og tilkoblingsbanen for det faktisk evaluerte domenet. Hvis rå SPF passerer, men ikke justeres, undersøk en støttet tilpasset MAIL FROM-konfigurasjon eller en annen justert autentiseringsbane. Ikke fortsett å legge til IP-er til et urelatert domene SPF rekord.
Bekreft endringer med kontrollert mottatt e-post og senere rapporteringsbevis, og bevarer både rå og justerte resultater. Videresending kan endre tilkoblings-IP, så test relevante ruter og unngå å behandle SPF alene som en garanti for levering. Avslutt undersøkelsen med den evaluerte identiteten, innrettingsmodusen og det demonstrerte resultatet.
Ta vare på de rå-til-justerte testsakene
Fire delvis syntetiske kart deler header_from= brand.example , policy p=reject og epokeintervall 1704067200–1704153600. A bruker MAIL FROM= vendor.example med rå SPF pass og ingen DKIM signaturer: justert SPF og DMARC mislykkes. B bruker MAIL FROM= bounce.brand.example med rå SPF pass og ingen DKIM : under et eksplisitt antatt delt organisasjonsdomene passerer avslappet modus SPF justering og DMARC . Den samme B-inngangen under streng modus mislykkes begge. Et fjerde tilfelle gjenoppretter As urelaterte SPF identitet, men legger til bestått DKIM for brand.example /selector billing1: DMARC går gjennom DKIM .
Den medfølgende lokale identitetsøvelsen reproduserer alle fire utfallene fra de medfølgende identitetene, resultatene og justeringsmodi. Den bruker et eksplisitt organisasjonsdomenekart, ikke en DNS -trevandringsimplementering. Den tester heller ikke en reell null revers-path-melding; null-baneveiledningen ovenfor er spesifikasjonsbasert. Faktisk leverandør- og mottakeradferd trenger fortsatt bevis for mottatt melding.
Hold øvelsen innenfor rekkevidde
Eksemplene er partielle feltprojeksjoner, ikke skjemavalide rapporter eller målt trafikk. Lokale sjekker bruker eksplisitt oppgitte autentiseringsresultater og organisatoriske relasjoner; de utfører ikke DNS oppdagelse, SPF evaluering, kryptografisk verifisering, rapportinntak eller tester for mottakerlevering. Ta vare på den originale rapporten og pålitelige meldingsbevis før du gjør en produksjonsendring.