An SPF pass svar, om en afsendende IP var godkendt til den evaluerede SPF identitet. DMARC stiller et yderligere spørgsmål: stemmer den autentificerede identitet overens med domænet i From? An samlet rapport kan derfor vise rå SPF beståelse og en SPF-relateret DMARC fejl uden at modsige sig selv.
Identificer det domæne- SPF der er godkendt
Referencer: RFC 9990 §3.1.1.13, RFC 7208 §2.4, RFC 9989 §4.4.2.
Læs auth_results/spf/domain og resultat sammen. Undersøg identifikatorer/header_from, eventuel envelope_from og det rapporterede omfang. Antag ikke, at SPF har tjekket det synlige Fra-domæne. RFC 7208 definerer MAIL FRA identitet, mens RFC 9989 bruger denne identitet til SPF 's bidrag til DMARC .
For en nul omvendt sti definerer SPF en MAIL FROM-identitet ved hjælp af postmaster på HELO domæne. Det særlige tilfælde bør ikke blive en regel om, at ethvert uafhængigt HELO opfylder DMARC . Strøm RFC 9990 indberetningstilladelser mfra som SPF omfanget; Ældre rapportformater kan afsløre forskellige felter og har brug for eksplicit fortolkning.
Anvend den korrekte justeringstilstand
Referencer: RFC 9989 §3.2.10.2, RFC 9989 §4.10.2, RFC 9990 §3.1.1.9.
Streng SPF justering kræver, at det autentificerede domæne nøjagtigt matcher forfatterdomænet. Afslappet justering tillader det forhold, der er defineret gennem de gældende regler for organisationsdomæne. Beregn det ikke blot ved at fjerne et fast antal etiketter: offentligt suffiks og oplysninger om politikopdagelse har betydning.
SPF værdien under row/policy_evaluated udtrykker det DMARC-relaterede resultat, ikke en duplikat af det rå SPF resultat. En rå fejl eller fejl kan ikke blive en vellykket SPF sti, bare fordi domænenavnene ligner hinanden. Godkendelse skal lykkes såvel som tilpasset.
Arbejd gennem to kontrasterende rækker
Referencer: RFC 9989 §5.3.5.
Antag gældende gyldige politikker, gennemførte kontroller og ikke-relaterede organisationsdomæner for brand.example og vendor.example . Syntetisk række A bruger header_from= brand.example , MAIL FROM= vendor.example og raw SPF =pass. Den ikke-relaterede identitet stemmer ikke overens, så policy_evaluated/ spf=fail forventes. Tilføjelse af en leverandør-IP til brand.example 's SPF ændrer ikke den identitet, som denne rute faktisk evaluerer.
Syntetisk række B bruger header_from= brand.example og MAIL FROM= bounce.brand.example med rå SPF =pass. Antag, at den relevante opdagelse af et organisationsdomæne placerer dem sammen. Afslappet SPF justering kan passere, mens streng SPF justering mislykkes, fordi navnene er forskellige. Disse er illustrative feltarmaturer, ikke observeret trafik.
For hver række, inspicer justeret DKIM før man konkluderede, at DMARC som helhed fejlede. En aflevering afstemt DKIM signatur kan levere den succesfulde DMARC -sti uafhængigt af SPF .
Vælg en reparation, der ændrer det mislykkede lag
Referencer: RFC 7208 §10.3.
Hvis rå SPF fejler, skal du undersøge autorisation og forbindelsesstien for det faktisk evaluerede domæne. Hvis rå SPF passerer, men ikke justeres, skal du undersøge en understøttet tilpasset MAIL FROM-konfiguration eller en anden tilpasset godkendelsessti. Bliv ikke ved med at tilføje IP'er til et ikke-relateret domæne SPF rekord.
Bekræft ændringer med kontrolleret modtaget post og senere rapporteringsbeviser, så både rå og tilpassede resultater bevares. Videresendelse kan ændre den forbindende IP, så test relevante ruter og undgå at behandle SPF alene som garanti for levering. Afslut undersøgelsen med den evaluerede identitet, alignment mode og demonstrerede resultat.
Bevar de rå-til-justerede testcases
Fire delvise syntetiske kort deler header_from= brand.example , policy p=reject og epokeinterval 1704067200–1704153600. A bruger MAIL FROM= vendor.example med rå SPF -pas og ingen DKIM signaturer: aligned SPF og DMARC fail. B bruger MAIL FROM= bounce.brand.example med rå SPF pas og ingen DKIM : under et eksplicit antaget delt organisationsdomæne passerer afslappet tilstand SPF justering og DMARC . Det samme B-input under streng tilstand mislykkes begge. Et fjerde tilfælde gendanner A's ikke-relaterede SPF identitet, men tilføjer videregående DKIM til brand.example /selector billing1: DMARC passerer gennem DKIM .
Den leverede lokale identitetsøvelse gengiver alle fire resultater fra de leverede identiteter, resultater og justeringsmetoder. Den bruger et eksplicit organisationsdomænekort, ikke en DNS -trævandringsimplementering. Den tester heller ikke en rigtig nul-omvendt sti-meddelelse; nul-sti-vejledningen ovenfor er specifikationsbaseret. Faktisk udbyder- og modtageradfærd kræver stadig bevis for modtaget besked.
Hold øvelsen inden for rammerne
Eksemplerne er delvise feltprojektioner, ikke skemavalide rapporter eller målt trafik. Lokale kontroller bruger eksplicit leverede autentificeringsresultater og organisatoriske relationer; de udfører ikke DNS opdagelse, SPF evaluering, kryptografisk verifikation, rapportindtagelse eller test af modtagerlevering. Bevar den originale rapport og pålidelige meddelelsesbeviser, før du foretager en produktionsændring.