SPF, DKIM og DMARC bidra med ulike bevis om en e-post. SPF vurderer en koblingskilde mot et evaluert domenes sendepolicy. DKIM verifiserer en domeneassosiert signatur over dekket meldingsmateriale. DMARC knytter en bestått autentisert identitet til domenet i From og bruker dets policyrammeverk.
De jobber sammen fordi intet enkelt grønt resultat svarer på alle identitetsspørsmål. En nyttig implementering følger meldingen gjennom avsendertjenesten, DNS avhengigheter og mottakssystem, og bevarer det hver sjekk faktisk har etablert.
Gi hver sjekke sitt eget spørsmål
- Mekanisme: SPF ; Spørsmål besvart: Tilfredsstiller denne koblingskilden sendepolicyen for den evaluerte identiteten?; Viktig grense: Denne identiteten trenger ikke være det synlige Fra-domenet
- Mekanisme: DKIM ; Spørsmål besvart: Verifiserer denne domenetilknyttede signaturen mot det dekkede meldingsmaterialet?; Viktig grense: Verifisering fastslår ikke at alle deler av meldingen eller forespørselen er trygge
- Mekanisme: DMARC ; Spørsmål besvart: Stemmer en kvalifiserende bestått identitet med From, og hvilken vurderingspolicy gjelder?; Viktig grense: Mottakerhåndtering inkluderer bevis utover DMARC
Kontrollene er relatert, men de er ikke tre kopier av samme prøve. Et system kan publisere alle tre typer DNS poster mens en applikasjon fortsatt sender uten den tiltenkte signaturen eller domenejustering.
Følg SPF fra sendeforbindelsen
For POST FRA sjekk av en vanlig melding med en ikke-tom konvolutt-returadresse, RFC 7208 §2.4 spesifiserer at SPF evaluerer sendekilden ved å bruke MAIL FROM-identiteten. Mottakeren konsulterer domenets publiserte policy, som kan referere til andre policydata.
Dette er grunnen til at identiteten er viktig før enhver DNS redigering. Legge til en tjeneste til example.com SPF rekord kan ikke reparere en SPF evaluering som faktisk bruker et tjenestekontrollert domene andre steder. Finn først hva meldingen og ruten bruker.
Under RFC 7208 §2.3 og RFC 7208 §2.4, SPF kan også evaluere HELO, og spesifikasjonen definerer håndtering for en null omvendt bane. Disse tilfellene rettferdiggjør ikke å erstatte et vilkårlig domene fra meldingens visningsfelt. Bevar den evaluerte identiteten med resultatet.
Et SPF pass lager ikke en signatur over meldingsinnhold. Dens bevis handler om den evaluerte kilden og identiteten på det mottakspunktet.
Følg DKIM fra signering til bekreftelse
Et sendesystem gjelder en DKIM signatur ved hjelp av en privat nøkkel. Under RFC 6376 §3.6.2.1, verifisering bruker offentlig materiale funnet gjennom signaturens signeringsdomene og velger. Den private nøkkelen hører hjemme i det autoriserte signeringssystemet, ikke offentlig DNS .
Både signering og publisering skal fungere. En offentlig nøkkel med riktig navn beviser ikke at applikasjonen signerte meldingene sine med den. Omvendt fastslår ikke en nåværende signatur at nøkkelen kan hentes eller at verifiseringen lykkes etter levering.
Under RFC 6376 §3.7, DKIM beskytter materialet som dekkes av sin definerte signaturberegning. En gateway som endrer relevant innhold etter signering kan påvirke bekreftelsen. De body-hash etterforskningsveiledning forklarer hvordan du sporer en bestemt feil uten å gjette at hver DKIM feil trenger en ny nøkkel.
Bruk DMARC for å koble bevis til Fra
DMARC evaluerer domenet i Fra-adressen ved å bruke gjeldende policy og justeringsrelasjoner. Under RFC 9989 §5.3.5, kan et pass på meldingsnivå med en gjeldende policy og fullførte kontroller komme fra enten en bestått justert SPF identitet eller en bestått justert DKIM signatur.
Denne godkjenningsbetingelsen er ikke en anbefaling om å konfigurere bare én mekanisme. RFC 9989 §8 krav til full deltakelse inkluderer tilpasset SPF og DKIM , rapportering og policypublisering. Under RFC 9989 §7.4, publisering av domener p=reject må ikke stole utelukkende på SPF og må bruke gyldige DKIM signaturer.
Postboksleverandører kan også stille egne avsenderkrav. Googles retningslinjer for masseavsender, for eksempel ring for SPF , DKIM og DMARC . Hold en protokolls meldingsnivå atskilt fra overholdelse av en leverandørs hele sendingspolicy.
Forstå hvorfor stiene kan overleve annerledes
Følgende er et syntetisk eksempel, ikke en kontotest. En varslingstjeneste produserer et passerende justert SPF resultat og en passerende justert DKIM signatur for sin direkte rute.
Vurder nå to endringer i den ruten:
- En videresendingstjeneste endrer tilkoblingskilden som den endelige mottakeren ser. Det tidligere SPF resultatet er ikke en garanti for den senere evalueringen. Hvis relevant signert innhold er bevart, kan den originale justerte DKIM signaturen fortsatt bekreftes.
- En gateway endrer signert innhold etter signeringsfasen. DKIM kan mislykkes ved neste mottaker, mens SPF avhenger av den endelige tilkoblingsruten og evaluert identitet.
Ingen av resultatene er uunngåelige for enhver mellommann. Inspiser den faktiske ruten, identiteter og verifiseringsresultater. Denne forskjellen forklarer hvorfor de to mekanismene tilbyr nyttige distinkte veier uten å gjøre verken universelt pålitelig gjennom all videresending eller modifikasjon.
Hold konfigurasjonsbevis atskilt fra meldingsbevis
En liten post på tjenestenivå er mer nyttig enn en uforklarlig domenestatus. Denne fiktive akseptmatrisen illustrerer skillet:
- Tjenesteobservasjon: Ansattpost har en offentlig DKIM nøkkel; Bevis fortsatt nødvendig: Bevis på at det valgte domenet signerer og verifiserer gjennom sin virkelige rute
- Tjenesteobservasjon: Faktureringspost passerer SPF for et leverandørdomene; Fortsatt behov for bevis: Forholdet til From og enhver justert DKIM bane
- Tjenesteobservasjon: Markedsføringspost har en gyldig DMARC policy; Bevis fortsatt nødvendig: Faktisk signering, autentisering og policy-kontekst bevis
- Tjenesteobservasjon: En mottatt melding består de relevante kontrollene; Fortsatt behov for bevis: Bedriftseier og godkjent bruk, vurdert separat
For hver tjeneste, behold den støttede konfigurasjonen, viktige identiteter og en representativ original mottatt melding. Under RFC 8601 §7.1, bruk pålitelige mottakssystemresultater; en pass-påstand satt inn av en ikke-klarert avsender kan ikke stå for mottakerens arbeid.
De avsenderens beholdning kobler disse postene til eiere. De DMARC rekordarbeidsflyt slår sammen publikasjon med meldings- og rapporteringsverifisering.
Bevar grensene for det kombinerte resultatet
Som signaturomfanget i RFC 6376 §3.7 og mottakerhåndtering inn RFC 9989 §5.4 Vis, krypterer disse sjekkene ikke meldingen for mottakeren, fastslår ikke sannheten av innholdet eller garanterer plassering av innboksen. Transportsikkerhet og beskyttelse av sensitivt meldingsinnhold er separate bekymringer.
En kompromittert autorisert tjeneste kan fortsatt sende autentisert e-post. På samme måte bekrefter ikke et gyldig teknisk resultat at organisasjonen har godkjent den aktuelle applikasjonskontoen eller forretningsforespørselen.
Det nyttige kombinerte resultatet er derfor presist: Mottakeren evaluerte den faktiske kilde- og signaturidentiteten, fant den nødvendige justerte passeringsveien for From, og vurderte den relevante policyen. Oppbevar bevisene med tjenesten og ruten som produserte det. Tre konfigurerte poster er en startavhengighet; verifisert, vedlikeholdt kommunikasjon er driftsresultatet.
Bevar en avgrenset konklusjon
I den fiktive akseptmatrisen lukker en offentlig nøkkel bare publiseringsbevis. Et leverandørdomene SPF pass trenger fortsatt forholdet til Fra avmerket. For ethvert krav om DMARC -pass, behold gjeldende retningslinjer og den spesifikke justerte passeringsbanen, og hold deretter kontogodkjenning og innholdssikkerhet atskilt. Ingen tjenestekonfigurasjon eller meldingstest ble utført her.