Med en gjeldende policy og en gjennomført evaluering, SPF og DKIM kan både passere mens DMARC feiler under RFC 9989 §5.3.5. Det skjer når domenene disse mekanismene som er autentisert ikke stemmer overens med domenet folk ser i Fra-adressen.
Hver mekanisme svarer på forskjellige spørsmål. SPF sjekker om tilkoblingskilden er autorisert for den evaluerte konvoluttidentiteten. DKIM verifiserer en signatur knyttet til et signeringsdomene. DMARC sjekker deretter om en bestått identitet har det nødvendige forholdet til det synlige From-domenet. Måten å diagnostisere dette problemet på er å sammenligne disse identitetene, ikke telle de grønne passetikettene.
Samle identitetene fra en mottatt melding
Få en original melding fra mottakersystemet, inkludert pålitelige autentiseringsresultater. En vilkårlig overskrift som sier pass kan leveres av en ikke-klarert avsender; identifisere mottaksgrensen som genererte bevisene under RFC 8601 §7.1.
Registrer disse feltene:
- Bevis: Synlig fra domene; Hva det etablerer: Forfatterdomenet, som betyr domenet i den synlige Fra-adressen
- Bevis: SPF resultat og evaluert POST FRA identitet; Hva den fastslår: Om den koblende kilden var autorisert for denne konvoluttidentiteten
- Bevis: Hvert DKIM -resultat og dets d=-domene; Hva den fastslår: Hvilket domenes signatur bekreftet
- Bevis: Gjeldende aspf- og adkim-moduser; Hva det fastslår: Hvorvidt eksakte eller avslappede domenerelasjoner kreves
- Bevis: Pålitelig DMARC resultat og diagnostisk kontekst; Hva den fastslår: Mottakerens observerte evaluering
Under RFC 5321 §4.4, for vanlige meldinger, den leverte Return-Path kan hjelpe med å identifisere konvoluttens returidentitet. Korreler det med pålitelige SPF resultater og rutebevis i stedet for å anta at et visningsfelt forteller hele SMTP historien.
Arbeidseksempel: to pasninger, ingen tilpasset identitet
Dette er en syntetisk illustrasjon som forutsetter en gjeldende gyldig policy og fullførte kontroller, ikke en fanget kundemelding:
- Felt: Fra; Observert verdi: accounts@example.com
- Felt: SPF ; Observert verdi: pass for bounce.example.net
- Felt: DKIM ; Observert verdi: bestått med d=example.org
- Felt: DMARC justering; Observert verdi: Ingen av de beståtte domenene stemmer overens med example.com
Begge mekanismene lyktes i sine egne jobber. Verken etablerer det nødvendige forholdet til example.com, så de gir ikke en DMARC passeringsbane for det synlige Fra-domenet.
En støttet rettelse kan konfigurere et kundedomene DKIM signatur. En annen mulighet er et støttet tilpasset konvoluttdomene som produserer en passerende justert SPF bane. Hvilket alternativ som er tilgjengelig avhenger av det faktiske sendeproduktet og ruten.
Ikke oppfinn DNS verdier. Skaff den støttede konfigurasjonen fra tjenesten, publiser den med de riktige eiernavnene, aktiver den relevante sendefunksjonen og send en ny test gjennom samme applikasjonsarbeidsflyt.
Påfør streng og avslappet justering riktig
Med streng justering må de relevante domenene samsvare nøyaktig under RFC 9989 §3.2.10.2, for begge mekanismene. De relevante DKIM og SPF identifikatorene er spesifisert i RFC 9989 §4.4.1 og RFC 9989 §4.4.2, henholdsvis. Med avslappet justering bruker DMARC gjeldende organisasjonsdomeneforhold og oppdagelsesregler i RFC 9989 §4.10.2.
For en enkel illustrativ sak, en forbigående konvoluttidentitet kl bounce.example.com kan samkjøre med et Fra-domene på example.com under avslappet SPF justering. Den tilfredsstiller ikke streng SPF justering fordi de to navnene er forskjellige.
Ikke generaliser oppdagelse av organisasjonsdomene til en regel som alltid tar de to siste etikettene. Domenegrenser og gjeldende DMARC oppdagelsesregler har betydning. Sjekk den faktiske policyen og implementeringen for mer komplekse domenestrukturer.
Når det finnes flere DKIM signaturer, inspiser alle relevante signaturer. Én ujustert bestått signatur ugyldiggjør ikke en separat justert bestått signatur. Omvendt skaper ikke tilstedeværelsen av domenet ditt i en mislykket signatur en forbigående bane.
Finn de støttede identitetsinnstillingene i sendetjenesten
Dette vises ofte etter at et team begynner å bruke et CRM, faktureringsverktøy eller kampanjetjeneste. Leverandøren sier at autentisering er aktivert, men noen mottakere avviser meldingene. Begge påstandene kan være sanne hvis plattformen autentiserer sitt eget domene mens virksomheten viser ditt.
Be operatøren vise én berørt melding og forklare den synlige avsenderen, konvoluttavsenderen og signeringsdomenet. En nyttig løsning viser at den faktiske arbeidsflyten sender gjennom en støttet justert identitet. Et skjermbilde som viser to grønne haker er utilstrekkelig.
Hold applikasjonseieren involvert. Den rette løsningen kan være en innstilling eller planspesifikk funksjon i den tjenesten, i stedet for en endring i e-postplattformen for ansatte.
Test korrigeringen gjennom den opprinnelige ruten
Send en kontrollert erstatningsmelding gjennom den berørte tjenesten. Sammenlign From-domenet, konvoluttidentiteten og alle relevante DKIM signaturer med den tidligere prøven. Hold det pålitelige mottakerresultatet og konfigurasjonsendringen sammen.
Hvis en enkel direkte test består, men forretningsruten fortsatt mislykkes, inspiser videresending, gatewayer og meldingsendringer. De kan endre hvilken autentiseringsbane som overlever. Skille også et DMARC pass fra innboksplassering; mottakeren kan bruke ekstra filtrering under RFC 9989 §5.4.
Bruk Microsoft 365 guide eller Google Workspace veiledning hvor disse systemene er de faktiske avsendere. Hvis meldingen bruker et annet program, undersøk programmets egen rute. Bruk samlede rapporter å se etter det samme mønsteret på tvers av observert trafikk.
Bestem deg for hva feilen forteller deg
En innrettingsfeil etablerer et teknisk resultat. Den fastslår ikke i seg selv om meldingen var legitim, en uautorisert tjeneste, en videresendingshavari eller et etterligningsforsøk.
Krev et eier- og forretningsformål for en avsender før du godkjenner ny tillit. Delt infrastruktur og et gjenkjennelig leverandørnavn er nyttige ledetråder, men de beviser ikke at organisasjonen din har godkjent kontoen eller arbeidsflyten.
Registrer det aksepterte omfanget av rettelsen. En justert signeringsidentitet kan tilfredsstille DMARC mens kontoen senere blir kompromittert eller applikasjonen genererer usikkert innhold. Fortsett kontokontroller, applikasjonsvalidering og uavhengig godkjenning av sensitive transaksjoner.
Den praktiske takeawayen
Lukk problemet når den berørte arbeidsflyten produserer en ny melding med et klarert bestått justert resultat. Hold identitetssammenligningen og konfigurasjonsendringen sammen. Dette forklarer både hvorfor den opprinnelige meldingen mislyktes og hvorfor korrigeringen fungerer.
Gjør neste avgjørelse eksplisitt
For to-pass-armaturen, noter "ingen justert passeringsbane" i stedet for " SPF ødelagt." Velg den tjenestestøttede identiteten som skal repareres, og la endringen vente til en ny melding om samme arbeidsflyt bekreftes. Hvis policyoppdagelse eller DNS behandling er ufullstendig, må du ikke tvinge observasjonen til en bestått/ikke bestått-etikett; RFC 9989 §5.3.6 behandler nødvendige DNS feil separat. Ingen kundekonfigurasjon eller leveringstest ble utført.