Sådan læser du en virksomheds DMARC-politik på ti sekunder (og hvad den ikke fortæller dig)

Ét DNS-opslag fortæller dig, hvad en virksomhed har anmodet verdens mailservere om at gøre med forfalskede e-mails sendt i dens navn. Posten er offentlig, og kommandoen er én linje: dig +short TXT _dmarc.example.com. Det der kommer tilbage, er en kort streng med indstillinger, og inden i den er der én instruktion — p=none, p=quarantine eller p=reject — som angiver domæneejerens præference, når en besked med det pågældende domæne fejler autentificering.

Den nuværende specifikation, RFC 9989, offentliggjort i maj 2026 som et IETF Standards Track-dokument, erstattede den ældre RFC 7489. Den definerer de tre værdier næsten kortfattet:

• p=none — "Domæneejerens giver ingen udtryk for præference."
• p=quarantine — "Domæneejerens betragter sådan mail som mistænkelig. Det er muligt, at mailen er gyldig, selvom fejlen skaber en betydelig bekymring."
• p=reject — "Domæneejerens betragter alle sådanne fejl som en klar indikation på, at brugen af domænenavnet ikke er gyldig."

Læs disse ord igen, for de er svagere end de fleste forklaringer på DMARC indrømmer. En politik er en præference, offentliggjort af afsenderen for modtagere at overveje. Det er ikke en instruktion, som en modtager er forpligtet til at udføre. RFC 9989 siger det på én sætning: "Den endelige håndtering af enhver besked er altid et spørgsmål om lokal politik og overlades tilMailModtagerens skøn." Det samme afsnit tilføjer begge dele af konsekvensen — modtagere "kan vælge at afvise eller sætte en besked i karantæne, selv hvis den består DMARC-valideringen," og de "bør IKKE afvise beskeder alene på grund af en offentliggjort politik om 'reject'," præcis så legitim mail sendt på måder, som DMARC ikke kan beskrive, og mailinglister ikke bliver ødelagt i processen.

Så hvad indrømmer p=none egentlig? Mindre end det normalt bliver anklaget for. I specifikationens egne termer er det Monitoring Mode: domæneejerens indsamler samlede rapporter og "udtrykker ingen håndteringspræference for beskeder, der fejler DMARC-validering," mens en modtager, der implementerer DMARC, "stadig kan" validere domænets brug. Det den gør ikke, er at slå noget fra ved modtagerenden. Din leverandørs spamfiltrering, omdømmevurdering, URL-kontrol og bilaganalyse er separat maskineri, der kører uanset hvad afsenderen offentliggjorde. En forfalske besked, der ankommer til et p=none-domæne, bliver ikke fremmet til din indbakke af posten; den bliver simpelthen overdraget til modtageren uden en erklæret præference, og modtageren beslutter.

Den anden halvdel af misforståelsen kører den anden vej. DMARC læser ikke den farlige del af en phishing-e-mail. Dens egen specifikation viser hvad der bevidst er uden for rammerne, og "content analysis" er på den liste, præcis sådan. Den angiver også, at DMARC "ikke behandler brugen af visuelt lignende domænenavne eller misbrug af RFC5322.From menneskelæseligt visningsnavn" — de to tricks, der bærer mest mærke-efterlignings-mail. Og på værdien af en pass: "en DMARC-pass alene garanterer ikke, at levering til modtagerens indbakke ville være sikker eller ønskelig." En korrekt autentificeret besked fra et engansdomæne passerer DMARC rent. DMARC svarer på, hvem der var autoriseret til at bruge domænet i From:-headeren. Intet mere.

Det er her, 2024-reglerne for bulkafsendere rutinemæssigt bliver fejlrapporteret, også i den første version af denne artikel. Googles afsenderretningslinjer kræver, at afsendere af 5.000 eller flere beskeder dagligt til Gmail-konti "Konfigurerer DMARC-e-mailautentificering for dit afsenderdomæne," og siger så i samme åndedræt: "Din DMARC-håndhævelsespolitik kan være indstillet til none." Yahoos eget Sender Hub, som skal læses separat i stedet for at blive antaget at kopiere Google, angiver kravet som "Publicer en gyldig DMARC-politik med mindst p=none - DMARC skal bestå," og offentliggør slet ingen numerisk volumengrænse. Begge sæt krav trådte i kraft fra februar 2024. Ingen tvinger nogen væk fra p=none. Hvad begge faktisk tvinger, er autentificering, der stemmer overens: Google kræver, at "domænet i afsenderens From:-header skal være tilpasset enten SPF-domænet eller DKIM-domænet," og Yahoo siger, at afslappet tilpassung er acceptabel. Tilpassung, ikke alvor, er grinden.

Hvilket efterlader den egentlige grund til, at domæner sidder på monitoring, og den er operativ snarere end modig. At flytte til quarantine eller reject betyder først at finde enhver service, der sender mail i dit navn — løn, billetter, marketing, en supportdesk, som ingen dokumenterede — og autentificerer hver enkelt, så den stemmer overens. Standarden selv indrømmer de farer, der gør det langsomt: tredjepartafsendere introduceres eller udelukkes hverken af DMARC, videresendelse og mailinglister kan bryde tilpassung uden skyld hos afsenderen, og specifikationen peger modtagere på RFC 7960 for præcist de fejltilstande. En organisation, der udgiver p=none og læser sine rapporter, udfører arbejdet i den rækkefølge, som specifikationen beskriver. En, der udgiver p=none og ignorerer rapporterne, gør det ikke. Fra udenfor kan posten alene ikke fortælle dig, hvilket af de to du ser.

Du behøver ikke en terminal til at se. Gratis opslingsværktøjer — dmarcians domænetjekker, MXToolbox's DMARC-tjekker — henter posten og udskriver politikken for dig. Gør det for din bank, din løntjenesteyder, det flyselskab, du flyver med. Læs bare svaret for hvad det er: en erklæring om hensigt fra domænets ejer, ét input blandt mange i en beslutning, som din mailprovider træffer på egen hånd, om én specifik type forfalskning. Det er en ægte brugbar ting at kunne læse på ti sekunder. Det er ikke en afgørelse om, hvorvidt næste besked, der hævder at være fra det mærke, er sikker.

Rettelse, 20. oktober 2026. En tidligere version af denne artikel beskrev p=none som at levere forfalskninger til indbakken og p=reject som den eneste indstilling, der blokerer en forfalsket besked, sagde, at 2024 Googles og Yahoos bulkafsenderregler tvang afsendere væk fra p=none, og citerede en tal på cirka én ud af tre domæner under håndhævelse. Politikbeskrivelserne er blevet rettet i forhold til RFC 9989; både Google og Yahoo accepterer faktisk p=none, citeret ovenfor fra deres egen dokumentation; og håndhævelsestallet er blevet fjernet, fordi den underliggende rapport ikke offentliggør sin prøve eller nævner. Artiklen angiver nu også hvad DMARC ikke undersøger.

@@END@@