En melding kan passere DMARC og fortsatt mislykkes i en postboksleverandørs avsenderkrav. Det er ikke nødvendigvis en selvmotsigelse. DMARC svarer på et spesifikt identitetsspørsmål; en mottaker kan også kreve fungerende mekanismer, sikker transport, passende meldingskonstruksjon og ansvarlig sendingsatferd.
Start med protokollavgjørelsen
Referanser: RFC 9989 §4.1, RFC 9989 §4.4, RFC 9989 §4.10, RFC 9989 §5.3.5.
RFC 9989, publisert i mai 2026, forelder eldre RFC-er 7489 og 9091. I henhold til seksjon 4.1 passerer DMARC når det eksisterer en policypost for forfatterdomenet og det domenet er på linje med en autentisert identifikator fra meldingen. Justert-pass-prinsippet består: minst én støttet autentiseringsmekanisme må passere med justering til det synlige Fra-domenet. Til SPF innenfor DMARC er den relevante identiteten SMTP POST FRA domene under RFC 9989 §4.4.2; et frittstående HELO-basert SPF resultat er ikke en erstatning for den DMARC identiteten. Til DKIM, er det d=-domenet til en gyldig signatur. En vellykket mekanisme uten den nødvendige justeringen bidrar ikke til et DMARC pass. RFC 9989 avsnitt 3.2.10 og 4.1–4.3.
Justering har strenge og avslappede moduser. Strict sammenligner de aktuelle domenene nøyaktig; avslappet bruker deres organisasjon-domene-forhold. RFC 9989 avsnitt 4.10 definerer DNS Tree Walk oppdagelse i stedet for den gamle tilnærmingen til offentlig suffiksliste. Bekreft mottakerens eller evaluatorens implementerte versjon før du antar dens oppdagelsesadferd. Ikke implementer avslappet justering ved å sjekke om en domenestreng bare slutter med en annen. Et villedende suffiks eller en feil organisasjonsdomeneberegning kan gi feil resultat.
Legg til leverandørkravene som et eget lag
Microsofts veiledning for brukerstøtte for høyt volum krever både SPF og DKIM for å bestå, pluss DMARC . Yahoo bulkkrav krever både mekanismer og bestått DMARC . Dette er operasjonsporter i tillegg til protokollens logikk for enten-justerte mekanismer. Se gjennom gjeldende kilde for destinasjonen i stedet for å utlede en universell regel fra én leverandør. Microsoft-støtte og Yahoo krav.
Opprett én kolonne for DMARC -resultatet og separate kolonner for nødvendige kontroller for autentisering, DNS , transport, formatering og avmelding. En samlet grønn indikator uten disse kolonnene gjør det vanskelig å si om programvaren evaluerer protokollen, en leverandørsjekkliste eller bare publisert DNS syntaks.
Bruk en sannhetstabell for å avsløre forskjellen
Referanser: RFC 9989 §5.3.5.
Den private vurderingspakken inkluderer en to-etui syntetisk armatur. For det første passerer begge SPF og DKIM , men ingen av dem stemmer overens: DMARC mislykkes. For det andre svikter SPF mens DKIM passerer og justerer: DMARC passerer. Det andre tilfellet kan fortsatt feile en leverandørport som uavhengig krever SPF suksess.
Disse inngangene er bevisst enkle booleaner, ikke en implementering av DNS Tree Walk-oppdagelse, eldre offentlig suffiksbasert oppdagelse, SPF evaluering eller DKIM kryptering. Begge tilfeller forutsetter at det finnes en gjeldende DMARC -policypost. De gjør det logiske skillet reproduserbart uten å late som om de tester en leverandør. I en ekte undersøkelse, bytt ut hver boolean med et pålitelig observert resultat og dens evaluerte identitet.
Ikke forveksle publisering med evaluering
Referanser: RFC 9989 §5.4.
Publisering p=none etablerer en forespurt overvåkingspolicy, ikke et vellykket resultat for meldingsautentisering. Å publisere en offentlig DKIM nøkkel signerer ikke utgående e-post. Legger til en SPF rekord beviser ikke at den faktiske tilkoblingen brukte en autorisert adresse. Hver konfigurasjonsartefakt trenger en tilsvarende observasjon fra den tiltenkte senderruten.
På samme måte går fra p=none til p=reject reparerer ikke justering. Det endrer domeneeierens forespurte håndtering for feil. Lagre legitime ruter før du endrer håndhevelse, bevar en tilbakeføringsplan og evaluer effekten på indirekte strømmer. Mottakeren bruker fortsatt sin egen lokale disposisjonspolicy; en forespurt DMARC handling er ikke en leveringsgaranti.
Bygg en nyttig avslutningsrekord
Referanser: RFC 8601 §5.
For hver undersøkte prøve, behold From, konvoluttavsender, koblende IP, DKIM underskriver og velger, mekanismeresultater, justeringsmodus og endelig mottaksrespons. Identifiser den pålitelige kilden til disse resultatene. Ikke aksepter vilkårlige kopierte overskrifter som autoritative bare fordi de inneholder ordet "pass."
Lukk protokollfunnet og leverandøroverholdelsesfunnet separat. Dette gjør det mulig å si nøyaktig at DMARC bestod mens et annet krav forble uløst, og å tildele rettelsen til rett eier uten å svekke urelaterte kontroller.