DMARC i Microsoft 365: börja med rapporter

För en egen domän i Microsoft 365 är ordningen att inventera avsändarna, kontrollera SPF och DKIM och publicera DMARC med p=none och en adress för rapporter. Höj policyn först när legitima utskick klarar DMARC; Microsofts införandeplan går från rapportering via p=quarantine till p=reject för att minska risken att riktig post avvisas.

Kontrollen omfattar också nyhetsbrev, ärendesystem och andra tjänster som skickar med organisationens domän i det synliga From-fältet. Ett godkänt SPF- eller DKIM-resultat räcker bara om den autentiserade domänen också matchar From-domänen enligt DMARC:s regler. Därför behöver varje avsändare granskas innan mottagarna ombeds sätta misslyckade meddelanden i karantän eller avvisa dem.

Inventera domäner och avsändare

Lista de domäner och underdomäner som används i From-fältet och ange vilket system som skickar från var och en. Ta med användarpost från Microsoft 365, egna system, webbplatser och externa utskickstjänster. Markera också registrerade domäner som inte används för e-post; de ska inte behandlas som aktiva avsändardomäner.

Samla ett mottaget exempel från varje legitimt utskick, helst hos en extern mottagare. I meddelandehuvudet jämför du header.from med smtp.mailfrom och DKIM-signaturens d=, samt läser resultaten för SPF, DKIM och DMARC. DMARC.orgs översikt beskriver hur domänmatchningen och mottagarnas rapporter gör det möjligt att upptäcka avsändare som behöver rättas före en skarpare policy.

Inventeringen ger en kontrollpunkt för senare ändringar: en källa som syns i rapporterna kan jämföras med listan över godkända system. En okänd källa kan vara ett glömt legitimt utskick eller någon som använder domänens namn utan tillstånd. Rapportens autentiseringsutfall behöver därför vägas mot vad organisationen faktiskt skickar.

Kontrollera SPF och DKIM i Microsoft 365

Kontrollera SPF-posten i DNS för varje domän som används vid utskick. När Microsoft 365 skickar för domänen ingår normalt include:spf.protection.outlook.com; andra godkända källor läggs till enligt respektive tjänsts anvisningar. Det ska finnas en SPF-post per domän, inte flera konkurrerande poster. En underdomän som används för utskick behöver sin egen SPF-konfiguration.

Aktivera därefter DKIM-signering för den egna domänen i Microsoft Defender-portalen. Hämta domänens CNAME-värden därifrån och publicera dem i DNS i stället för att konstruera adresserna själv. Microsofts DKIM-anvisningar anger att värdena ska hämtas för den aktuella domänen och att formatet för nya domäner kan skilja sig från äldre konfigurationer.

Skicka sedan ett testmeddelande från domänen till ett annat e-postsystem och läs mottagarens autentiseringsresultat. För DMARC måste antingen SPF godkännas för en MAIL FROM-domän som matchar From, eller DKIM godkännas med en matchande d=-domän. Standardläget för matchning tillåter underdomäner inom samma organisationsdomän; strikt matchning kräver samma fullständiga domännamn. Ett godkänt resultat för en annan organisations domän uppfyller inte kravet.

Rätta externa utskick som saknar domänmatchning

Ett externt utskick misslyckas med DMARC när dess autentiserade domäner inte matchar avsändardomänen.

En utskickstjänst kan få godkänt SPF för sin egen returadress och godkänt DKIM för sin egen domän, medan mottagaren ser er domän i From. Då kan DMARC ändå misslyckas: ingen av de godkända domänerna matchar den synliga avsändaren. Att lägga tjänsten i SPF-posten för er huvuddomän hjälper inte om SPF i meddelandet kontrolleras mot tjänstens MAIL FROM-domän.

I ett fiktivt exempel skickas nyhetsbrev från [email protected]. Tjänsten kan då konfigurera DKIM-signering med d=marketing.example.com, eller använda en MAIL FROM-domän under example.com som får ett godkänt SPF-resultat. Kontrollera det mottagna meddelandet efter ändringen; en inställning hos leverantören visar inte ensam vilket resultat mottagaren faktiskt får.

En särskild underdomän för externa utskick gör avsändaren lättare att följa och ger utrymme för en egen DMARC-policy under införandet. Om leverantören inte kan ge utskicket en SPF- eller DKIM-domän som matchar den valda From-domänen behöver utskicket ändras innan policyn skärps. Gå också igenom mer sällsynta utskick, till exempel meddelanden från ett ärendesystem som bara skickar vid en viss händelse; ett lyckat nyhetsbrevstest täcker inte dem.

Publicera rapportadress och skärp policyn stegvis

Skapa en adress som kan ta emot aggregerade rapporter och publicera en DMARC TXT-post under _dmarc för den aktuella domänen. För den fiktiva domänen example.com kan postens värde vara v=DMARC1; p=none; rua=mailto:[email protected]. Kontrollera att DNS-posten går att slå upp och att adressen fungerar. Om rapportadressen ligger i en annan organisations domän behöver den mottagande domänen också tillåta rapporteringen i DNS.

Med p=none begär domänägaren ingen DMARC-specifik blockering, men mottagarens övriga filter kan fortfarande påverka leveransen. Aggregerade rapporter visar sändande källor och autentiseringsutfall, ofta som XML-bilagor. Alla mottagare skickar inte rapporter, så jämför dem med inventeringen och med egna testmeddelanden. Rätta kända legitima källor som fortfarande misslyckas innan nästa policyändring.

Byt till p=quarantine när de identifierade utskicken klarar DMARC och följ rapporter och leveransproblem efter ändringen. Värdet pct kan användas för att låta policyn omfatta en del av de meddelanden som misslyckas medan effekten följs upp. Gå vidare till p=reject när också mindre vanliga legitima utskick har kontrollerats. Den faktiska hanteringen beror på mottagarens e-postsystem, vilket gör fortsatt uppföljning relevant även efter att policyn har skärpts.

Skilj aktiva underdomäner från parkerade domäner

En aktiv underdomän följs med DMARC-rapporter medan en parkerad domän har policyn p=reject.

En underdomän utan egen DMARC-post omfattas av huvuddomänens policy. Inventera därför underdomänerna innan huvuddomänen får p=reject. En aktiv marketing.example.com kan under arbetet ha en egen post med p=none medan dess externa avsändare rättas, även om example.com redan har en strängare policy. Först när utskicken från underdomänen klarar kontrollen är den redo för samma skärpning.

För en helt parkerad domän gäller en annan kontrollpunkt: fastställ att varken domänen eller dess underdomäner används för legitima utskick. För en fiktiv unused.example.net kan SPF-posten då vara v=spf1 -all och DMARC-posten v=DMARC1; p=reject. Publicera inga DKIM-nycklar för en domän som inte ska signera post. Om domänen senare tas i bruk måste avsändarna och autentiseringen ordnas före det första utskicket.

Läs också: