Så läser du ett företags DMARC-policy på tio sekunder (och vad den inte säger dig)

En DNS-sökning säger dig vad ett företag har bett världens e-postservrar att göra med förfalskad post som skickas i dess namn. Posten är publik, och kommandot är en rad: dig +short TXT _dmarc.example.com. Det som kommer tillbaka är en kort sträng med inställningar, och inuti den finns ett instruktioner — p=none, p=quarantine eller p=reject — som anger domänägarens önskemål när ett meddelande som använder den domänen misslyckas med autentisering.

Den aktuella specifikationen, RFC 9989, publicerad i maj 2026 som ett IETF Standards Track-dokument, ersatte den äldre RFC 7489. Den definierar de tre värdena nästan lakoniskt:

• p=none — "Domänägaren uttrycker ingen preferens."
• p=quarantine — "Domänägaren anser att sådan post är misstänkt. Det är möjligt att posten är giltig, även om misslyckandet skapar en betydande oro."
• p=reject — "Domänägaren anser att alla sådana misslyckanden är en tydlig indikation på att användningen av domännamnet inte är giltig."

Läs dessa ord igen, för de är svagare än vad de flesta förklaringar av DMARC medger. En policy är ett önskemål, publicerat av avsändaren för mottagare att överväga. Det är inte en instruktion som en mottagare är skyldig att följa. RFC 9989 säger det i en mening: "Den slutliga hanteringen av något meddelande är alltid en fråga om lokal policy och lämnas till e-postmottagarens bedömning." Samma avsnitt lägger till båda sidorna av konsekvensen — mottagare "FÅR välja att avvisa eller karantänisera ett meddelande även om det klarar DMARC-valideringen," och de "BÖR INTE avvisa meddelanden enbart på grund av en publicerad policy om 'reject'," just för att legitim post som skickas på sätt som DMARC inte kan beskriva, och distributionslistor, inte ska förstöras i processen.

Så vad bekänner p=none egentligen? Mindre än vad det vanligtvis anklagas för. I specens egna termer är det övervakningsläge: domänägaren samlar in aggregerade rapporter och "uttrycker ingen hanteringspreferens för meddelanden som misslyckas med DMARC-validering," medan en mottagare som implementerar DMARC fortfarande "kan" validera domänens användning. Det som det inte gör är att stänga av något i mottagarens ände. Din leverantörs skräppostfiltrering, anseenderäkning, URL-kontroller och bilageanalys är separat maskineri som körs oavsett vad avsändaren publicerade. Ett förfalskad meddelande som anländer till en p=none-domän blir inte befordrat till din inkorg av posten; det handas helt enkelt över till mottagaren utan ett uttalat önskemål, och mottagaren beslutar.

Den andra hälften av missförståelsen går åt andra vägen. DMARC läser inte den farliga delen av ett phishing-e-postmeddelande. Dess egen specifikation listar vad som är avsiktligt utanför räckvidden, och "innehållsanalys" finns på den listan, med dessa ord. Det säger också att DMARC "inte tar upp användningen av visuellt liknande domännamn eller missbruk av RFC5322.From-visningsnamnet läsbar för människor" — de två tricken som bär mest varumärkesförfalskningspost. Och om värdet av ett pass: "ett DMARC-pass i sig garanterar inte att leverans till mottagarens inkorg skulle vara säker eller önskvärd." Ett korrekt autentiserat meddelande från en engångsdomän klarar DMARC rent. DMARC svarar vem som auktoriserades att använda domänen i From:-huvudet. Ingenting mer.

Det är här reglerna för bulkavsändare från 2024 rutinmässigt misrapporteras, inklusive i den första versionen av denna artikel. Googles avsändarriktlinjer kräver att avsändare av 5 000 eller fler meddelanden per dag till Gmail-konton "Ställer upp DMARC-e-postautentisering för din avsändardomän," och säger sedan, i samma andetag: "Din DMARC-tvingande policy kan ställas in på none." Yahoos egen Sender Hub, som måste läsas separat snarare än antas kopiera Google, anger kravet som "Publicera en giltig DMARC-policy med minst p=none - DMARC måste passera," och publicerar ingen numerisk volymtröskel alls. Båda uppsättningarna av krav trädde i kraft från februari 2024. Ingen tvingar någon bort från p=none. Det som båda faktiskt tvingar är autentisering som stämmer: Google kräver att "domänen i avsändarens From:-huvudet måste vara anpassad till antingen SPF-domänen eller DKIM-domänen," och Yahoo säger att avslappnad anpassning är acceptabel. Anpassning, inte allvarlighetsgrad, är grinden.

Vilket lämnar den verkliga anledningen till varför domäner sitter på övervakning, och det är operativt snarare än fegt. Flytta till quarantine eller reject betyder först att hitta alla tjänster som skickar post i ditt namn — löner, biljetter, marknadsföring, ett supportskrivbord som ingen dokumenterade — och autentisera var och en så att den anpassas. Standarden själv erkänner de faror som gör detta långsamt: tredjepartsavsändare varken introduceras eller utesluts av DMARC, vidarebefordring och distributionslistor kan bryta anpassningen utan avsändarens fel, och specen pekar mottagare på RFC 7960 för exakt dessa fellägen. En organisation som publicerar p=none och läser sina rapporter gör arbetet i den ordning som specen beskriver. En som publicerar p=none och ignorerar rapporterna gör det inte. Från utsidan kan posten ensamt inte säga dig vilken av de två du tittar på.

Du behöver ingen terminal för att titta. Kostnadsfria uppslagsverktyg — dmarcians domänkontroll, MXToolbox:s DMARC-kontroll — hämtar posten och skriver ut policyn för dig. Gör det för din bank, din löneleverantör, flygbolaget du flyger med. Läs bara svaret för vad det är: ett intentionsuttalande från domänens ägare, en ingång bland många in i ett beslut som din e-postleverantör fattar på egen hand, om en specifik typ av förfalskning. Det är en genuint användbar sak att kunna läsa på tio sekunder. Det är inte en dom över huruvida nästa meddelande som säger sig vara från det varumärket är säkert.

Rättelse, 20 oktober 2026. En tidigare version av denna artikel beskrev p=none som leverering av förfalskningar till inkorgen och p=reject som den enda inställningen som blockerar ett falskt meddelande, sa att reglerna för Google och Yahoo bulkavsändare från 2024 tvingade avsändare bort från p=none, och citerade en siffra på ungefär en av tre domäner vid tvingande. Policybeskrivningarna har korrigerats mot RFC 9989; både Google och Yahoo accepterar i själva verket p=none, citerat ovan från deras egen dokumentation; och tvingandesiffer har tagits bort eftersom den underliggande rapporten inte publicerar sitt urval eller nämnare. Artikeln säger nu också vad DMARC inte granskar.