Et mailsystem kan rapportere SPF bestå og DKIM passere mens DMARC stadig fejler. Det resultat er ikke selvmodsigende. Hver mekanisme begynder med en anden identitet, og DMARC tilføjer en relationstest mellem en bestået identitet og domænet i meddelelsens Fra-adresse.
Den pålidelige måde at undersøge en besked på er at registrere identitetskæden, før du ændrer DNS . Start med det domæne, modtageren ser i Fra. Registrer derefter det domæne, der bruges til SPF og hvert domæne, der findes i en DKIM signatur. Først derefter skal du vurdere justering og DMARC -resultatet på meddelelsesniveau.
Nævn de tre identiteter, før du læser resultaterne
Overvej denne fiktive besked:
Fra: Billing Team < statements@billing.example.com > Return-Path : < bounce+739@mailer.example.net > DKIM-Signature : ... d=billing.example.com; s=outbound1; ...Fra domænet er billing.example.com. DMARC kalder det Author Domain. De konvolutafsender er her repræsenteret ved Return-Path domæne mailer.example.net; for MAIL FROM-kontrollen af denne almindelige besked, det er den identitet, SPF evaluerer under RFC 7208 §2.4. En separat HELO tjek kan også forekomme under RFC 7208 §2.3; Return-Path håndtering er specificeret i RFC 5321 §4.4. DKIM signeringsdomænet er værdien af d=, hvilket er billing.example.com i dette eksempel.
Et vist navn såsom Billing Team er ikke en godkendelsesidentitet. Reply-To er heller ikke forfatterdomænet. Disse felter kan have betydning for en svindelundersøgelse, men de erstatter ikke de domæner, som DMARC sammenligner.
Registrer resultater og justering separat
Et rå SPF pas betyder, at forbindelseskilden blev godkendt til den SPF identitet, der blev evalueret. Et råt DKIM pas betyder en signatur, der er verificeret for dens d= domæne og det dækkede meddelelsesmateriale. Ingen af resultaterne siger i sig selv, at dets domæne har det nødvendige forhold til From.
DMARC har derfor brug for to kolonner for hver sti:
- Sti: SPF ; Godkendelsesspørgsmål: Bestod SPF for den evaluerede kuvertidentitet?; Justeringsspørgsmål: Stemmer denne identitet med forfatterdomænet?
- Sti: DKIM ; Godkendelsesspørgsmål: Bestod denne signatur for sit d=-domæne?; Justeringsspørgsmål: Er det d=-domæne på linje med Author Domain?
Under RFC 9989 §3.2.10.2, streng justering kræver nøjagtig domænelighed. Under RFC 9989 §4.10.2, afslappet justering bruger det relevante organisations-domæne opdagelsesforhold. Undlad at tilnærme den grænse ved at tage de sidste to etiketter, fordi offentlige suffiksregler kan gøre den genvej forkert.
Arbejd igennem en aflevering og en vildledende råpas
Det følgende er et syntetisk undervisningseksempel, ikke et kundebudskab. Antag en gældende gyldig politik, gennemførte kontroller, pålidelige modtageresultater og kendte justeringsmetoder; RFC 9989 §5.3.5 definerer den resulterende regel for bestået/ikke bestået.
- Observation: Fra; Besked A: alerts@example.com ; Besked B: alerts@example.com
- Observation: SPF resultat; Besked A: Pass for bounce.vendor.example.net ; Besked B: Pass for bounce.vendor.example.net
- Observation: SPF justeret?; Meddelelse A: Nej; Meddelelse B: Nej
- Observation: DKIM resultat; Besked A: Bestå med d=example.com; Besked B: Bestå med d=vendor.example.net
- Observation: DKIM justeret?; Meddelelse A: Ja; Meddelelse B: Nej
- Observation: DMARC på meddelelsesniveau ; Besked A: Gå gennem DKIM ; Meddelelse B: Mislykkedes
Meddelelse A passerer DMARC , fordi én DKIM signatur både verificerer og justerer. Dets ujusterede SPF resultat annullerer ikke den gyldige sti. Meddelelse B har to rå godkendelsesgennemgange, men ingen af de godkendte domæner stemmer overens med forfatterdomænet, så der er ingen forbigående DMARC sti.
Denne tabel er også en nyttig ændringspost. Den viser, om reparationen hører hjemme i kuvertidentiteten, signeringskonfigurationen eller det synlige From-domæne. Et grønt ikon uden disse domæner er ikke nok bevis til at godkende en DNS ændring.
Undersøg hver DKIM -signatur
En besked kan bære mere end én DKIM signatur. En udgående tjeneste, en gateway og en mellemmand kan hver tilføje en. Evaluer hver signatur uafhængigt. Én justeret forbigående signatur kan give DKIM -stien, selv når en anden signatur er ujusteret eller fejler.
Udled ikke vælger fra et udbydernavn. Læs s= værdi fra den faktiske DKIM-Signature header, kombiner den med signaturens d= domæne, og forespørg det resulterende DNS -navn under RFC 6376 §3.6.2.1. Udgivelse af en nøgle gør kun verifikationsmateriale tilgængeligt. Afsendersystemet skal stadig oprette en gyldig signatur med den tilhørende private nøgle.
Indirekte post kan ændre signeret indhold eller kuvertstien. Videresendelse kan derfor påvirke SPF , mens listeændringer kan påvirke DKIM . Behandl den observerede sti som bevis for at undersøge, ikke bevis på, at den oprindelige afsender eller mellemmand var ondsindet.
Brug pålideligt modtagende bevis
Authentication-Results kan opsummere identiteter og resultater, men tillid afhænger af, hvor overskriften blev tilføjet. En afsender kan indsætte en header, der hævder succes. Under RFC 8601 §7.1, brug resultatet produceret af det modtagende system, du administrerer, eller en anden grænse, hvis håndtering du forstår.
Når beskeden blev afvist før levering, eksisterer der muligvis ikke en leveret kopi. Brug afvisningssvaret, udbyderlogfiler og eventuel modtagende telemetri. Opfind ikke manglende identiteter fra en fejlkode alene.
Gør identitetskæden til en operationel post
For hver materialeafsender skal du beholde:
- virksomhedsejeren og applikationen;
- de From-domæner, det er autoriseret til at bruge;
- den observerede kuvertidentitet;
- hver observeret DKIM d= domæne og vælger;
- godkendelsesresultatet for hver sti;
- tilpasningstilstanden og konklusionen;
- en repræsentativ testdato og meddelelsesidentifikation.
Denne registrering adskiller virksomhedsgodkendelse fra protokolbevis. Det forhindrer også en almindelig fejl: at ændre organisationens rod SPF rekord at løse et DKIM justeringsproblem eller ændre DMARC -politik, når afsenderkonfigurationen er den reelle defekt.
Når identitetskæden er klar, skal du bruge vejledning til fejlfinding af justering at reparere en svigtende sti og afsenderens opgørelse at tildele ejerskab.
Hold konklusionen inden for beviserne
For besked A skal du skrive SPF bestået/ujusteret og DKIM bestået/justeret som separate fakta. For B skal du ikke konvertere to ikke-relaterede råpas til et DMARC -pas. Behold hver signatur uafhængigt og udled ikke SMTP identiteten udelukkende ud fra visningsnavnet. Disse sager og den forkortede signatur er undervisningseksempler, ikke gyldigt signaturmateriale eller udført verifikation.