Indfør DMARC med rapporter før afvisning

Indfør DMARC i etaper: Kortlæg alle systemer, der sender med dit domæne i den synlige Fra-adresse, sørg for korrekt SPF eller DKIM, og publicér en DMARC-post med p=none og en adresse til samlede rapporter. Brug rapporterne til at finde legitime afsendere med fejl, før du beder modtagere om at sætte mail i karantæne eller afvise den.

Med p=none anmoder DMARC ikke om særskilt håndtering af mail, der fejler kontrollen. Det giver plads til at opdage en glemt fakturatjeneste eller nyhedsbrevsleverandør, mens rapporteringen er i gang. Andre filtre hos modtageren kan stadig sortere mail fra, så observationsfasen er ingen leveringsgaranti.

Lav en inventarliste over alle afsendere

Begynd med hvert domæne og underdomæne, som virksomheden bruger i synlige Fra-adresser. Medtag medarbejdermail, webformularer, faktura- og bookingsystemer, CRM, support og nyhedsbreve. Skriv for hver afsender, hvem der ejer opsætningen, hvilken tjeneste der sender, hvilket Fra-domæne modtageren ser, hvilket domæne returadressen bruger, og hvilket domæne der står i en eventuel DKIM-signatur. Listen skal også omfatte sjældne udsendelser, som ikke nødvendigvis optræder i de første rapporter.

Kontrollér derefter, at SPF godkender de relevante afsenderservere, og at DKIM-signering virker, hvor den bruges. Det er ikke nok, at en leverandør består kontrollen med sine egne domæner: Mindst én godkendt vej skal senere kunne justeres med domænet i den synlige Fra-adresse. Googles DMARC-vejledning anbefaler SPF og/eller DKIM før DMARC, 48 timers ventetid efter opsætningen og kontrol af mail fra tredjepartstjenester.

Brug den enkelte leverandørs værdier til SPF og DKIM. En TXT-værdi fra én mailplatform er ikke en universel opskrift for andre tjenester, og ændringer i leverandørens afsendelse kan kræve senere vedligeholdelse. Gem også et eksempel på en faktisk udsendt besked fra hver tjeneste; dens mailheadere bliver nyttige, hvis rapporterne viser en fejl.

Publicér en DNS-post, der samler rapporter

Opret en postkasse eller rapporttjeneste, der kan modtage samlede DMARC-rapporter. For det betingede domæne example.com kan posten ligge på _dmarc.example.com med værdien v=DMARC1; p=none; rua=mailto:[email protected]. Udskift domæne og adresse med jeres egne, og kontrollér den offentliggjorte TXT-post i DNS. Hvis der allerede findes en DMARC-post på navnet, skal den ændres frem for at blive suppleret med en ekstra.

Rapportadressen skal kunne modtage mail og håndtere de rapporter, der kommer. Skal rapporter sendes til en tjeneste på et andet domæne, skal ejeren af modtagerdomænet normalt godkende ekstern rapportmodtagelse med en særskilt DNS-post. Aftal den præcise opsætning med tjenesten, og kontrollér, at rapporterne ankommer, før de bruges som grundlag for at stramme politikken.

Gennemgå samtidig underdomænerne. En politik på hoveddomænet kan også gælde underdomæner uden egen DMARC-post. Et underdomæne med en særskilt leverandør eller mailstrøm kan få sin egen post, så dets fejl og politik kan håndteres særskilt. Det giver især mening, når hoveddomænet har mange afsendere, mens et bestemt underdomæne har få og velkendte.

Find forskellen mellem godkendelse og domænejustering

Sammenhold rapporternes afsendende IP-adresser, antal beskeder og SPF- og DKIM-resultater med inventarlisten. Microsofts DMARC-vejledning viser, at en samlet rapport kan afsløre SPF-godkendelse, mens SPF-domænet stadig ikke er justeret med Fra-domænet. En kendt leverandør med DMARC-fejl skal derfor undersøges, før dens trafik behandles som uønsket; en ukendt kilde skal identificeres, før den får adgang til at sende på domænets vegne.

DMARC består, hvis SPF består og returadressens domæne er justeret med det synlige Fra-domæne, eller hvis DKIM består og signaturens d-domæne er justeret med Fra-domænet. Ved den almindelige løse justering kan et relevant underdomæne høre til samme organisatoriske domæne; streng justering kræver et præcist match. En tredjepart kan derfor bestå både SPF og DKIM med sine egne domæner og alligevel fejle DMARC for virksomhedens synlige Fra-adresse.

Se på Authentication-Results i en virkelig prøvebesked fra den berørte tjeneste. Sammenlign header.from med smtp.mailfrom og header.d, og se både på kontrollens resultat og på domænerne bag resultatet. Hvis leverandøren understøtter en returadresse under jeres domæne, kan den rette SPF-vejen; signering med jeres domæne kan rette DKIM-vejen. Test den ændrede udsendelse fra samme tjeneste, før fejlen markeres som løst.

Rapporter er sammendrag fra de modtagere, der sender dem, ikke en komplet liste over alle leverede beskeder. Hold dem derfor op mod egne afsendelseslogge og udsendelser på forskellige dage. Videresendelse og mailinglister kan desuden ændre den vej, en besked tager, så en rapporteret fejl bør vurderes sammen med beskedens faktiske forløb.

Stram politikken, når de kendte strømme består

Gå først videre, når de legitime afsendere i inventarlisten er undersøgt og består DMARC i faktiske udsendelser. Behold rapportadressen gennem alle faser. Et afgrænset underdomæne med få afsendere kan bruges til at følge virkningen af en strengere politik, før samme ændring foretages på et domæne med flere tjenester.

Observation: v=DMARC1; p=none; rua=mailto:[email protected]
Karantæne: v=DMARC1; p=quarantine; rua=mailto:[email protected]
Afvisning: v=DMARC1; p=reject; rua=mailto:[email protected]

Værdierne er betingede eksempler for example.com, ikke DNS-poster, der kan kopieres uændret. Karantæne beder modtagere behandle mail, som fejler DMARC, som mistænkelig. Afvisning udtrykker en stærkere præference for at afvise den. Modtagerens øvrige regler kan påvirke den endelige håndtering, så sammenlign rapporter og konkrete leveringsfejl efter hvert skift.

Nogle platformvejledninger viser stadig pct som metode til at indføre håndhævelse for en andel af beskederne. RFC 9989 har fjernet pct-tagget, fordi delvis anvendelse ikke virkede pålideligt på tværs af modtagere. Basér derfor ikke planen på, at en bestemt procentdel bliver håndteret ens overalt; vælg i stedet et afgrænset domæne eller underdomæne, og følg dets reelle mailstrømme.

Gør tilbageføring til en del af ændringen

Gem den senest fungerende TXT-værdi og navnet på den person, der kan ændre den hos DNS-udbyderen. Hvis en legitim afsender rammes efter en stramning, sættes politikken tilbage til den senest fungerende værdi, mens fejlen undersøges. Fra p=reject kan det betyde p=quarantine eller p=none. Kontrollér derefter den offentliggjorte post; DNS-cacher kan betyde, at ændringen ikke får virkning samtidig hos alle modtagere.

Lad rapporteringen fortsætte under tilbageføringen. Find den berørte tjeneste, ret dens SPF- eller DKIM-justering, og send en ny prøvebesked gennem dens sædvanlige udsendelsesvej. Når prøven består, og efterfølgende rapporter ikke viser samme fejl for den kendte mailstrøm, kan den strengere politik indføres igen.

Læs også: