En besked kan passere DMARC og stadig mislykkes en postkasseudbyders afsenderkrav. Det er ikke nødvendigvis en selvmodsigelse. DMARC besvarer et specifikt identitetsspørgsmål; en modtager kan også kræve fungerende mekanismer, sikker transport, passende meddelelseskonstruktion og ansvarlig afsendelsesadfærd.
Start med protokolbeslutningen
Referencer: RFC 9989 §4.1, RFC 9989 §4.4, RFC 9989 §4.10, RFC 9989 §5.3.5.
RFC 9989, udgivet i maj 2026, forælder ældre RFC'er 7489 og 9091. I henhold til afsnit 4.1 godkendes DMARC , når der eksisterer en politikrecord for forfatterdomænet, og det domæne stemmer overens med en autentificeret identifikator fra meddelelsen. Det aligned-pass princip forbliver: mindst én understøttet godkendelsesmekanisme skal passere med justering til det synlige Fra-domæne. For SPF inden for DMARC er den relevante identitet SMTP MAIL FRA domæne under RFC 9989 §4.4.2; et selvstændigt HELO-baseret SPF resultat er ikke en erstatning for denne DMARC identitet. For DKIM, det er d=-domænet for en gyldig signatur. En vellykket mekanisme uden den nødvendige justering bidrager ikke til et DMARC beløb. RFC 9989 afsnit 3.2.10 og 4.1-4.3.
Alignment har strenge og afslappede tilstande. Strict sammenligner de gældende domæner nøjagtigt; afslappet bruger deres organisation-domæne forhold. RFC 9989 afsnit 4.10 definerer DNS Tree Walk opdagelse snarere end den gamle offentlige-suffiks-liste tilgang. Bekræft modtagerens eller evaluatorens implementerede version, før du antager dens opdagelsesadfærd. Implementer ikke afslappet justering ved at kontrollere, om en domænestreng kun ender med en anden. Et vildledende suffiks eller en forkert beregning af organisationsdomæne kan give det forkerte resultat.
Tilføj udbyderkravene som et separat lag
Microsofts supportvejledning for store mængder forbrugere kræver, at både SPF og DKIM beståes, plus DMARC . Yahoo bulkkrav kræver både mekanismer og bestået DMARC . Disse er operationelle porte ud over protokollens enten-alignede mekanisme-logik. Gennemgå den aktuelle kilde for destinationen i stedet for at udlede en universel regel fra én udbyder. Microsoft support og Yahoo krav.
Opret én kolonne til DMARC -resultatet og separate kolonner til påkrævet godkendelse, DNS , transport, formatering og afmeldingskontroller. En overordnet grøn indikator uden disse kolonner gør det svært at sige, om softwaren evaluerer protokollen, en udbydercheckliste eller kun offentliggjort DNS syntaks.
Brug en sandhedstabel til at afsløre forskellen
Referencer: RFC 9989 §5.3.5.
Den private anmeldelsespakke inkluderer et syntetisk armatur med to kabinetter. For det første består både SPF og DKIM , men ingen af dem stemmer overens: DMARC mislykkes. For det andet fejler SPF , mens DKIM godkender og justerer: DMARC passerer. Det andet tilfælde kan stadig svigte en udbyderport, der uafhængigt kræver SPF succes.
Disse input er bevidst simple booleaner, ikke en implementering af DNS Tree Walk-opdagelse, legacy public-suffiks-baseret opdagelse, SPF evaluering eller DKIM kryptering. Begge tilfælde forudsætter, at der findes en relevant DMARC -politikpost. De gør den logiske skelnen reproducerbar uden at foregive at teste en udbyder. I en rigtig undersøgelse skal du erstatte hver boolean med et pålideligt observeret resultat og dets evaluerede identitet.
Forveksle ikke publikation med evaluering
Referencer: RFC 9989 §5.4.
Forlagsvirksomhed p=none etablerer en anmodet overvågningspolitik, ikke et vellykket meddelelsesgodkendelsesresultat. Udgivelse af en offentlig DKIM nøgle signerer ikke udgående post. Tilføjelse af en SPF rekord beviser ikke, at den faktiske forbindelse brugte en autoriseret adresse. Hver konfigurationsartefakt har brug for en tilsvarende observation fra den påtænkte senderute.
Tilsvarende går fra p=none til p=reject reparerer ikke justering. Det ændrer domæneejerens anmodede håndtering af fejl. Inventar legitime ruter, før du ændrer håndhævelse, bevar en tilbagerulningsplan og evaluer effekten på indirekte strømme. Modtageren anvender stadig sin egen lokale dispositionspolitik; en anmodet DMARC handling er ikke en leveringsgaranti.
Opbyg en nyttig afslutningsrekord
Referencer: RFC 8601 §5.
For hver undersøgt prøve skal du beholde From, konvolutafsender, tilsluttende IP, DKIM underskriver og vælger, mekanisme resultater, alignment mode og endelig modtagende respons. Identificer den pålidelige kilde til disse resultater. Accepter ikke vilkårlige kopierede overskrifter som autoritative, blot fordi de indeholder ordet "bestå".
Luk protokolfundet og udbyderoverholdelsesresultatet separat. Dette gør det muligt at sige præcist, at DMARC bestod, mens et andet krav forblev uløst, og at tildele rettelsen til den rigtige ejer uden at svække ikke-relaterede kontroller.