DMARC uden mailnedbrud: Gå fra p=none til p=reject i trin

Indfør DMARC ved først at sikre, at legitim mail består SPF eller DKIM med et domæne, der stemmer overens med domænet i Fra-feltet. Publicér derefter en DNS-post med p=none og en adresse til rapporter. Når du har fundet og rettet de kendte afsendere, der fejler kontrollen, kan du gå videre til p=quarantine og til sidst p=reject. DMARC.orgs udrulningsmodel angiver den rækkefølge.

Det afgørende er at kontrollere mail fra Microsoft 365, Google Workspace og hver ekstern tjeneste, der bruger dit domæne i Fra-feltet. En bestået SPF-kontrol er ikke tilstrækkelig, hvis den gælder tjenestens eget returdomæne, mens modtageren ser dit domæne som afsender. Behold derfor p=none, indtil sådanne legitime mailstrømme er identificeret og rettet.

Få afsendere og domæner på plads

Lav en liste over systemer, der sender med dit domæne i Fra-feltet. Medtag medarbejdermail, nyhedsbreve, ordrebekræftelser, fakturaer, formularer og automatiske beskeder samt de tjenester, der sender på virksomhedens vegne. Notér også, om en tjeneste bruger et underdomæne; det får betydning, når politikken skærpes.

DMARC består, når mindst én godkendelsesvej virker: SPF består, og domænet i den tekniske returadresse er afstemt med Fra-domænet; eller DKIM-signaturen består og bruger et afstemt domæne. Standardindstillingen tillader afstemning inden for samme organisationsdomæne, så navnene behøver ikke altid være helt ens. For en ekstern tjeneste kan løsningen være DKIM-signering med dit domæne eller en tilpasset returadresse. At føje tjenesten til SPF løser ikke problemet alene, hvis dens returdomæne fortsat ikke er afstemt.

Googles opsætningsvejledning anbefaler at aktivere SPF eller DKIM før DMARC og vente 48 timer, før DMARC-posten oprettes. Den fremhæver også mail fra tredjepartstjenester. Se i prøvebeskeders mailheadere efter Fra-domænet, returadressens domæne og DKIM-signaturens d-værdi. En kendt afsender, som ikke består nogen af de afstemte veje, skal rettes før håndhævelse.

Publicér en post til rapportering

Opret en TXT-post hos den udbyder, der håndterer domænets DNS. Et illustrativt eksempel for example.com er værtsnavnet _dmarc.example.com med værdien v=DMARC1; p=none; rua=mailto:[email protected]; pct=100. Erstat både domænet og rapportadressen med dine egne værdier, og opret postkassen, før du publicerer posten. Eksemplet angiver ingen strengere krav til domæneafstemning end standardindstillingen.

Hos nogle DNS-udbydere skal værtsnavnet indtastes som blot _dmarc, fordi udbyderen selv tilføjer domænenavnet. Slå den færdige TXT-post op udefra, og kontrollér, at den ligger under det tilsigtede navn, har den forventede værdi og ikke er blevet oprettet ved siden af en eksisterende DMARC-post. Findes posten allerede, skal du redigere den i stedet for at oprette endnu en.

Med p=none beder domænet ikke modtageren om at sætte beskeder i karantæne eller afvise dem på grund af DMARC-politikken. Modtagerens øvrige spamfiltre kan stadig gribe ind. Feltet rua angiver, hvor samlede rapporter skal sendes; en særskilt postkasse eller rapporttjeneste gør dem lettere at følge end en almindelig medarbejderindbakke.

Brug rapporterne til at finde den manglende afsender

Gennemgå rapporterne efter de første udsendelser og igen, når periodiske beskeder er blevet sendt. Sammenhold afsendernes IP-adresser og godkendelsesresultater med din liste over mailsystemer. Rapporterne kan afsløre en legitim tjeneste, som ikke var med på listen, men en ukendt IP-adresse er ikke i sig selv bevis for misbrug. Undersøg, hvilken mailstrøm den repræsenterer.

Et tænkt eksempel er en nyhedsbrevstjeneste, der består SPF for sit eget returdomæne, mens Fra-feltet viser virksomhedens domæne. Hvis dens DKIM-signatur heller ikke er afstemt, fejler beskeden DMARC. Ret tjenestens DKIM-opsætning eller returadresse, send en ny prøvebesked, og kontrollér både resultatet i mailheaderen og de efterfølgende rapporter.

Vent med at skærpe politikken, hvis en kendt afsender fortsat fejler, eller hvis en sjælden udsendelse endnu ikke er blevet kontrolleret. Fravær af rapporter er heller ikke en godkendelse: rapporteringen afhænger af, hvilke modtagere der sender rapporter, og hvilken trafik domænet faktisk har haft. Brug derfor både rapportmønstre og konkrete testbeskeder fra de tjenester, du kender.

Skærp først politikken, når mailstrømmene består

Skift til p=quarantine, når de kendte legitime mailstrømme består DMARC, og behold rua-adressen. Microsofts DMARC-vejledning beskriver en gradvis udrulning med pct=10, pct=25, pct=50, pct=75 og pct=100. Den advarer samtidig om, at udgående Microsoft 365-mail, der fejler DMARC hos modtageren under p=quarantine eller p=reject, sendes gennem en særskilt højrisikopulje uden mulighed for at slå den håndtering fra.

For det illustrerende domæne kan første håndhævede trin være v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]. pct angiver andelen af beskeder, der fejler DMARC, som den valgte politik skal gælde for; det er ikke en andel af al udgående mail. Undersøg rapporterne og konkrete leveringsproblemer ved hvert trin, før du øger andelen. En lav pct-værdi erstatter ikke kontrollen af legitime afsendere.

Når p=quarantine med pct=100 har fungeret uden uafklarede fejl fra legitime afsendere, kan du skifte til p=reject og igen øge pct trinvist. Den endelige eksempelværdi er v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]. Gennemgå også underdomæner, der sender mail: de kan arve hoveddomænets politik, hvis de ikke har deres egen DMARC-post. Et underdomæne med egne afsendere kan derfor kræve sin egen kontrol og udrulning.

Rul tilbage, hvis legitim mail rammes

Stop en skærpelse, hvis en kendt afsender begynder at fejle DMARC, eller hvis modtagere melder om legitime beskeder i spam eller afviste beskeder. Sæt pct tilbage til det senest fungerende niveau, eller gå fra p=reject til p=quarantine eller p=none, mens årsagen bliver rettet. Kontrollér den publicerede DNS-værdi efter ændringen, og gentag en reel udsendelse fra den berørte tjeneste.

Behold rapporteringen under tilbagerulningen. Sammenlign nye rapporter og prøvebeskeder med den fejl, der udløste stoppet, før politikken skærpes igen. På den måde bliver p=reject resultatet af en kontrolleret udrulning for domænets faktiske afsendere frem for blot en streng værdi i DNS.

Læs også:

• n8n, Make eller Zapier: 10 trin kan ændre hele AI-regningen
• AI kan løfte opgaven uden at forbedre læringen, advarer to EU-rapporter
• Brug Copilot i Teams uden referat – men Purview kan stadig gemme spor