Tre domenefelt kan se utskiftbare i et dashbord mens de beskriver ulike deler av en melding. Overskrift fra identifiserer forfatterdomenet som brukes av DMARC. Konvolutt fra beskriver SMTP avsenderidentiteten som er relevant for SPF. Konvolutt Til beskriver SMTP mottakerdomenet, når det følger med. Begynn med å merke disse rollene i stedet for å velge hvilket domene som ser kjent ut.
Bygg en feltordbok
Referanser: RFC 9990 §3.1.1.10, RFC 9989 §3.2.4, RFC 7208 §2.4.
RFC 9990 avsnitt 3.1.1.10 krever header_from og gjør envelope_from og envelope_to valgfrie. Disse feltene inneholder domener, ikke en fullstendig liste over postboksadresser. Et manglende valgfritt felt betyr at rapporten ikke ga det. det beviser ikke at SMTP transaksjonen manglet denne identiteten.
Envelope_from-elementet kan eksistere, men er tomt for en null omvendt bane. Bevar forskjellen mellom manglende og tom i parseren din. Ikke fyll ut en tom verdi fra Header From eller anta at en gjettet returadresse ble evaluert. RFC 9989 seksjon 3.2.4 er avhengig av SPF validering av MAIL FROM-identiteten og refererer eksplisitt til RFC 7208 seksjon 2.4 for en null omvendt sti: SPF konstruerer denne identiteten som postmester ved HELO domene. Et bestått SPF resultat for denne konstruerte MAIL FROM-identiteten kan bidra til DMARC når domenet er på linje med Author Domain. Dette er forskjellig fra å erstatte et uavhengig evaluert HELO -resultat med en ikke-tom MAIL FROM-identitet. Bevar den evaluerte identiteten og resultatet før du tegner en justering konklusjon.
Les også de autentiserte identifikatorene
Referanser: RFC 9990 §3.1.1.12, RFC 9990 §3.1.1.13.
Sammenlign identifikatorer med auth_results, som rapporterer domenet som faktisk ble brukt under SPF validering og d- og s-verdiene som brukes for DKIM validering. Det synlige forfatterdomenet er ikke i seg selv bevis på at SPF har autentisert det. På samme måte kan et DKIM d-domene avvike fra begge konvoluttdomenene.
Konvolutt til er nyttig mottaker-domene kontekst. Det er ikke domenet DMARC justerer med SPF eller DKIM , og det skal ikke behandles som meldingens synlige Til-felt. Videresending, aliaser og blinde kopier kan gjøre synlige overskrifter til en dårlig konto for SMTP mottakerbanen.
Gjengi et syntetisk resultat
Referanser: RFC 9989 §5.3.5.
Anta en gjeldende gyldig policy, fullførte kontroller og urelaterte brand.example / vendor.example organisasjonsdomener. Tenk på header_from= brand.example , envelope_from= bounces.vendor.example og envelope_to= recipient.example . Anta at SPF passerer for bounces.vendor.example og a DKIM signatur bestått med d=brand.example. SPF stemmer ikke overens med brand.example fordi domenene er urelaterte. DKIM justeres nøyaktig, slik at DMARC kan passere gjennom DKIM til tross for det ujusterte SPF resultatet.
Hvis du bare endrer envelope_to til et annet mottakerdomene, endres ikke den justeringsberegningen. Hvis du endrer DKIM d-verdien til vendor.example , fjernes den justerte DKIM banen i dette eksemplet. Dette er antatte innganger for en øvelse på feltnivå, ikke en ekte mottakertest eller en fullstendig XML-rapport.
Bevar usikkerhet i en etterforskning
Registrer verdier for reporter, periode, kilde-IP, radantall og råfeltverdier ved siden av tolkningen. Hvis et dashbord utelater konvoluttfeltene, inspiser den originale rapporten før du konkluderer med at de var fraværende. Hvis selve rapporten utelater dem, få en autorisert kontrollert melding fra den aktuelle ruten i stedet for å produsere en verdi.
Et nyttig regneark har separate kolonner for forfatter, SMTP avsender, SMTP mottaker, autentisert SPF domene, hvert DKIM domene og DMARC-relaterte resultater. Avstem motsetninger før du endrer DNS . Målet er en reproduserbar identitetssammenligning, ikke å få hver kolonne til å inneholde merkenavnet ditt.
Sjekk fem reproduserbare identitetssaker
Referanser: RFC 9989 §3.2.10.2, RFC 9989 §5.3.5.
Bruk streng justering for begge mekanismene i denne øvelsen. Den syntetiske basisraden har header_from= brand.example , envelope_from= bounces.vendor.example , envelope_to= recipient.example , raw SPF pass for bounces.vendor.example , og raw DKIM pass for brand.example med velger faktura 1. Kilde-IP-en er 192.0.2.40 og antallet er 12. Kryptografiske og SPF utfall er antatte innganger; øvelsen sjekker identitetssammenligningen, ikke ekte autentisering.
- Variasjon fra grunnraden: Ingen; Justert SPF : Nei; Justert DKIM : Ja; DMARC : Bestått
- Variasjon fra grunnraden: Bare envelope_to blir another.example ; Justert SPF : Nei; Justert DKIM : Ja; DMARC : Bestått
- Variasjon fra basisraden: Bare DKIM domenet blir vendor.example ; Justert SPF : Nei; Justert DKIM : Nei; DMARC : Mislykket
- Variasjon fra grunnraden: envelope_from utelatt; originalt rå SPF resultat beholdt; Justert SPF : Nei; Justert DKIM : Ja; DMARC : Bestått
- Variasjon fra grunnraden: envelope_from tom; rå SPF identitet og resultat er ikke levert; Justert SPF : Ikke etablert uten null-path SPF identitet og resultat; Justert DKIM : Ja; DMARC : Bestått
Den medfølgende lokale strenge likhetsøvelsen gjengir fem utfall med justert DKIM tilgjengelig i tilfeller av manglende og tomme felt. Det etablerte ikke SPF -resultatet for hver null revers-bane. Saken med manglende felt beholder bevisst et urelatert rå SPF domene; et utelatt envelope_from-felt gjør ikke i seg selv at SPF mislykkes. Saken med tomme felt fjerner eksplisitt de originale rå SPF inndataene i stedet for å finne opp en null-baneidentitet. I så fall, skaff den SPF-validerte konstruerte MAIL FROM-identiteten beskrevet i RFC 9989 avsnitt 3.2.4 og RFC 7208 avsnitt 2.4 før du evaluerer justeringen. Bordets DMARC pass forblir levert av DKIM . For eksempel, forutsatt en gjeldende DMARC policy og streng justering, kan et bestått SPF -resultat for postmaster@brand.example levere en justert SPF bane for header_from= brand.example selv uten justert DKIM . Et bestått resultat for postmaster@other.example kan ikke. Disse to ekstra eksemplene er antatte utfall, ikke nylig utførte inventar. Ingen faktisk mottatt melding er representert.
Hold øvelsen innenfor rekkevidde
Eksemplene er partielle feltprojeksjoner, ikke skjemavalide rapporter eller målt trafikk. Lokale sjekker bruker eksplisitt oppgitte autentiseringsresultater og organisatoriske relasjoner; de utfører ikke DNS oppdagelse, SPF evaluering, kryptografisk verifisering, rapportinntak eller tester for mottakerlevering. Ta vare på den originale rapporten og pålitelige meldingsbevis før du gjør en produksjonsendring.