En besked kan vise et velkendt firmanavn, mens du bruger en helt anden e-mailadresse. Den kan også vise din virksomheds adresse, mens afsendertjenesten kun autentificerer sit eget domæne. Forståelse DMARC starter med at adskille disse identiteter.
DMARC står for Domain-based Message Authentication, Reporting and Conformance. Den evaluerer den autentificerede brug af domænet i meddelelsens Fra-adresse og forbinder dette resultat med domæneejerens offentliggjorte politik. Det er en vurdering på domæneniveau, ikke en dom om personen, anmodningen eller bilaget.
Find adressen bag afsendernavnet
Antag, at et mailprogram viser denne fiktive afsender:
Eksempelkonti < notices@shop.example.com >Eksempelkonti er det viste navn. opslag er delen før ved-tegnet. shop.example.com er domænet i Fra-adressen, kaldet Author Domain i DMARC .
Mailapplikationens kompakte visning viser muligvis kun visningsnavnet. Åbn afsenderoplysningerne eller den originale besked for at identificere den faktiske adresse. Et logo, et navn og en genkendelig emnelinje etablerer ikke dette domæneforhold.
Eksemplerne i denne vejledning antager en almindelig, velformet besked med ét forfatterdomæne. Misdannede eller tvetydige From-felter kræver deres eget meddelelsesformathåndtering; opfind ikke én foretrukken identitet ud fra, hvad en mail-applikation tilfældigvis viser.
Hold de andre adresser i deres rigtige roller
En e-mail har en SMTP -leveringssamtale samt de overskrifter og brødtekst, folk læser. Kuvertretur-identiteten understøtter leveringsstatushåndtering og er normalt den identitet, der vurderes af SPF til almindelig post. Det kan afvige fra From.
A DKIM signatur leverer et andet domæne i dets d= værdi. En besked kan have flere signaturer, hver med sit eget domæne og resultat. Reply-To er anderledes igen: det påvirker, hvor et svar adresseres, ikke hvilket Author Domain DMARC evaluerer.
| Punkt | Spørgsmål det hjælper med at besvare |
|---|---|
| Fra domæne | Hvilket påstået forfatterdomæne vurderes? |
| Konvolut identitet | Hvilket domæne vurderes for almindelig SPF autorisation? |
| DKIM d= domain | Hvilket domæne er knyttet til denne signatur? |
| Svar-Til | Hvor er et svar rettet? |
| Vist navn | Hvilket navn bliver præsenteret for læseren? |
Disse felter kan legitimt afvige. Opgaven er at forstå deres forhold i stedet for at kræve, at hver viste adresse er identisk.
Forstå forholdet kaldet alignment
SPF kan passere for en afsendende tjenestes konvolutdomæne. DKIM kan verificere en signatur fra den pågældende tjenestes signeringsdomæne. DMARC spørger derefter, om en passerende autentificeret identitet stemmer overens med forfatterdomænet.
Streng justering kræver et nøjagtigt domænematch. Afslappet tilpasning bruger den relevante organisation-domæne-relation. Bestem ikke denne grænse ved blot at tage de sidste to etiketter, og behandl ikke to mærker, der ligner hinanden, som tilpassede domæner.
For et DMARC -pas på meddelelsesniveau skal mindst én kvalificerende SPF eller DKIM sti både bestå og justere. En videregående signatur fra et ikke-relateret domæne kan ikke give denne sti, blot fordi virksomheden ejer en konto hos tjenesten.
Følg to fiktive beskeder
Det følgende er et syntetisk undervisningseksempel, ikke en fanget eller redigeret kundemeddelelse. Antag, at den gældende DMARC -politik er fundet, og at de angivne resultater kommer fra et pålideligt modtagende system.
Begge beskeder har Fra på shop.example.com . Deres identiteter adskiller sig som følger:
| Observation | Besked A | Besked B |
|---|---|---|
| SPF | Pass for returns.example.net | Pass for returns.example.net |
| DKIM | Bestå med d=shop.example.com | Bestå med d=dispatch.example.org |
| Afstemt forbikørselssti | DKIM matcher Fra nøjagtigt | Hverken forbipasserende identitet stemmer overens |
| DMARC validering | Passere | Svigte |
Meddelelse A har en nøjagtig matchende DKIM sti. Dens separate SPF identitet behøver ikke at blive omdøbt, for at dette DMARC -resultat på meddelelsesniveau kan bestå.
Meddelelse B godkender domæner, der ikke er relateret til dets Fra-domæne. To rå gennemløb frembringer derfor ingen justeret sti. Hvis dette er en autoriseret afsender, der skal repareres, skal du følge anvisningerne vejledning til fejlfinding af justering. Denne undersøgelse er anderledes end at beslutte, at hver besked med dette mønster er ondsindet.
Adskil resultatet fra det, modtageren gør
En domæneejer udgiver DMARC politik i DNS under et relevant _dmarc navn. Politikken udtrykker ejerens vurdering af svigtende brug. Den konfigurerer ikke en applikations signeringsidentitet eller bestemmer hver modtagers endelige handling.
Modtagere vurderer også information uden for DMARC . Følgelig lover et pass ikke indbakkeplacering, og en fejl etablerer ikke selvstændigt et blokeret angreb. De guide til valg af politik forklarer, hvordan et domænes faktiske brug påvirker ejerens beslutning.
Rapportering kan hjælpe ejeren med at undersøge, hvordan dets domæne vises i observeret mail. Rapporter er feedback fra deltagende modtagere, ikke en komplet hovedbog for hver meddelelse, der sendes. Hold rapporterede observationer adskilt fra virksomhedsgodkendelse og endelige leveringsresultater.
Læs et bestået resultat uden at overlæse det
Brug godkendelsesresultater produceret af den relevante betroede modtagegrænse. En afsender kan indsætte en header, der gør krav på et bestået; eksistensen af den tekst gør den ikke troværdig.
Selv et ægte tilpasset pas har grænser. En kompromitteret autoriseret konto kan sende autentificeret mail. Et ikke-relateret domæne kan godkende sine egne meddelelser, mens det præsenterer et vildledende visningsnavn. DMARC undersøger ikke sandheden af en faktura eller godkender en betalingsinstruktion.
Den nyttige forklaring er specifik: denne modtagne meddelelse havde et passerende autentificeret domæne, der opfyldte det påkrævede forhold til dets From-domæne. Det er et værdifuldt identitetssignal. Hold kontobeskyttelse, indholdsvurdering og uafhængig verifikation af følsomme anmodninger ved siden af.
For implementering, fortsæt med oprettelse og verificering af en DMARC post. For ejerskab på tværs af applikationer skal du bruge afsenderens opgørelse. Begge bliver nemmere, når det faktiske domæne, der vurderes, er klart.
Spor et resultat i fem linjer
Brug dette korte arbejdsark, når en meddelelse beskrives som "godkendt". Start med adressen, ikke firmanavnet, der vises ved siden af.
- Fra: skriv domænet ned efter @ i den faktiske Fra-adresse.
- Beviser: brug det modtagende systems betroede resultater. Registrer SPF domænet og hvert passerende DKIM d=-domæne separat.
- Forhold: sammenlign hver forbipasserende identitet med From under den gældende strenge eller afslappede tilstand. Et udbyderkontonavn er ikke et domænematch.
- Resultat: med en gældende politik og ingen uløst DNS fejl er én tilpasset gennemgangssti nok. Hvis der ikke er nogen, mislykkes meddelelsen DMARC . Ingen opdaget politik betyder, at DMARC ikke gælder; en påkrævet DNS-forespørgselsfejl er ikke blot en bestået eller fiasko.
- Betydning: Registrer identitetsresultatet separat fra levering, og om anmodningen er sikker at reagere på.
For meddelelse A ovenfor er forklaringen: " DKIM bestået for shop.example.com , som nøjagtigt matcher Fra; dette giver et DMARC -pas." Det er ikke: "Fakturaen er godkendt."
Tjek DMARC -behandlingstrin og den Authentication-Results tillidsgrænse for disse udmærkelser.