Vad är DMARC? Justering, policy, RFC 9989 och utrullning

Vad är DMARC? Det är en DNS-post som säger till mottagande e-postservrar vad de ska göra när ett meddelande gör anspråk på din domän i From-headern men misslyckas autentisering, och var rapporter om det ska skickas. DMARC autentiserar ingenting i sig själv. Det kontrollerar att SPF eller DKIM passerade och att domänen de validerade överensstämmer med domänen läsaren ser.

Den överensstämmelsen kallas justering, och det är den delen de flesta team får fel på. Ett meddelande kan passa SPF, passa DKIM, och fortfarande misslyckas DMARC. Den här situationen är mer vanlig än många tror.

DMARC är ett policylager ovanpå SPF och DKIM

SPF listar vilka IP-adresser som får skicka för en domän. DKIM signerar meddelandet så en mottagare kan verifiera att det inte ändrades och att signeringdomänen godkände det. Ingen av dem tittar på From-adressen en människa läser.

DMARC fyller det gapet. Det ställer en fråga: överensstämmer domänen i synlig From-header med domänen som passerade SPF eller DKIM? Om ja, passerar meddelandet. Om nej, tillämpar mottagaren din policy.

Posten finns på _dmarc.dindomän.se som en TXT-post. En minimal, giltig sådan ser ut så här:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-rapporter@example.com"

Tre taggar gör det verkliga arbetet. p är policyn, rua är var aggregeringsrapporter går, och adkim / aspf ställer hur strikt justering är. Allt annat är frivilligt.

Justering är där bra inställningar misslyckas

SPF autentiserar kuvertavsändaren, Return-Path-domänen. DKIM autentiserar domänen i d=-taggen för signaturen. DMARC behöver åtminstone en av dessa för att matcha From-domänen, antingen exakt (strikt) eller på organisationsdomännivå (avslappnad, standard).

Här är misslyckandet vi ser oftast i spår. Ett team skickar genom en tredjepartsleverantör, leverantören signerar med sin egen domän (d=leverantör-e-post.se) och använder sin egen bouncdomän. SPF passerar, DKIM passerar, och DMARC misslyckas eftersom ingen domän matchar example.com.

Fixen är en anpassad skickningsdomän: en DKIM-nyckel publicerad under din domän, och helst en anpassad return-path på en underdomän. Varje seriös leverantör stöder det. Få aktiverar det som standard.

De tre policyerna: none, quarantine, reject

p-taggen har tre värden, och de är inte en stege du klättrar på ett schema.

• p=none: mottagaren levererar normalt och skickar rapporter till dig. Använd den första 2 till 4 veckorna medan du inventerar avsändare.

• p=quarantine: mottagaren dirigerar misslyckanden till skräp eller junk. Använd den när rapporter visar alla legitima källor justerade.

• p=reject: mottagaren vägrar misslyckanden i SMTP-stadiet. Använd den när quarantine har körts rent under en full sändningscykel.

p=none är övervakning, inte skydd. En domän som sitter på none i två år har ett checkboxmärke för efterlevnad och ingen spoofingförsvar. Hoppa över frestelsen att lämna den där eftersom "ingenting bröts".

p=reject är destinationen för varje domän som bara skickar e-post du kontrollerar. Domäner med tung e-postlisttrafik eller äldre vidarebefordrare behöver mer försiktighet, eftersom vidarebefordran ofta bryter SPF och kan bryta DKIM om mellanstationen redigerar kroppen.

Varför Gmails och Yahoos regler gjorde detta brådskande

Sen februari 2024 kräver Googles avsändarvägledning att alla som skickar mer än 5000 meddelanden per dag till Gmail-konton publicerar en DMARC-post, med SPF och DKIM på plats. Policyn kan vara none. Google ber också massavsändare att hålla den användarrapporterad skräpfrekvensen i Postmaster Tools under 0,30%, och rekommenderar att stanna under 0,10%.

Yahoos avsändarhub säger samma kärnkrav: en publicerad DMARC-policy på åtminstone p=none, med From-domänen justerad till antingen SPF- eller DKIM-domänen. Avslappnad justering är acceptabel.

Lägg märke till vad som är och inte är i dessa regler. Kravet är en publicerad post och passering i justering, inte tillämpning. Det är en botten. Det är inte en målsnöre.

Aggregeringsrapporter är produkten, policyn är växeln

rua-adressen tar emot dagliga XML-rapporter från varje mottagare som respekterar DMARC. Varje rapport listar källIP-adresser, meddelandeantal, SPF- och DKIM-resultat, och om justering höll. Så här hittar du den glömd avsändaren: det gamla CRM-exporten, faktureringsverktyget en kontraktor kopplade upp 2022, marknadsföringsformuläret på en underdomän ingen äger.

Rå XML är oläsligt vid volym. Dirigera rua till en brevlåda en parser kan smälta, eller till en värdbaserad DMARC-rapporttjänst, och titta på data grupperad efter källa. Vad du vill se är varje legitim källa visar 100% justerad, och allt annat är klart okänt.

En praktisk utrullning löper i denna ordning:

1. Publicera p=none med en rua-adress.

2. Samla två till fyra veckors rapporter. Bygg avsändarinventeringen.

3. Fixa varje legitim ojusterad källa med en anpassad DKIM-domän eller return-path.

4. Gå till p=quarantine. Håll utkik efter supportbiljetter om saknad e-post.

5. Gå till p=reject när quarantine visar inga legitima misslyckanden.

Skicka varje steg separat. Att ändra policyn och lägga till en ny skickningsleverantör samma vecka gör någon regression omöjlig att tilldela.

DMARCbis ändrar taggarna, inte din post

År 2026 publicerade IETF RFC 9989, RFC 9990 och RFC 9991, som föråldrar RFC 7489. RFC 9989 är kärn-DMARC-specifikationen. Aggregeringsrapportering och misslyckanderapportering gick till sina egna dokument.

De praktiska ändringarna för en postägare är små:

• pct, rf och ri är borttagna.

• t (testningsläge) ersätter pct som en allt-eller-inget-växel: t=y rapporterar utan att tillämpa.

• np ställer en policy för icke-existerande underdomäner, vilket blockerar spoofing av adresser som abc123.example.com.

• psd markerar offentliga suffixdomäner, och en DNS-trädpromenad ersätter den gamla Public Suffix List-sökningen.

Existerande v=DMARC1-poster förblir giltiga. Ingenting bryter om du inte ändrar något idag. Leverantörstödet för de nya taggarna kommer att rulla ut ojämnt, så en ny tagg som verkar göra ingenting brukar innebära att mottagaren inte har implementerat den ännu.

Taggen np är värd att anta tidigt. Om du ställer np=reject medan p fortfarande är none stänger du misslyckandebanan för falsk-underdomän utan att låsa in resten av e-posten i tillämpning.

Underdomäner, och varför standardarvet är

En DMARC-post på organisationsdomänen gäller även underdomäner, såvida du inte åsidosätter den med sp. Det arvet är användbart och även en fälla.

Om marknadsföring skickar från news.example.com genom en separat leverantör, ärver den överordnad policy. Flytta föräldern till p=reject innan den leverantören har justerad DKIM och nyhetsbrevet går på golvet. Publicera en separat _dmarc.news.example.com-post när en underdomän har sin egen avsändarflotta och sin egen utrullningshastighet.

En renare arkitektur separerar strömmar efter underdomän från början. Transaktionell e-post på en, livscykelsamtal på en annan, mänsklig e-post på roten. Var och en får sin egen DKIM-nycklar, sitt eget rykte och sin egen DMARC-post.

Läs Authentication-Results-headern innan du gissar

När ett meddelande misslyckas, registrerar mottagarservern varför. I Gmail exponerar "Visa original" Authentication-Results-headern, och den säger dig mer än någon instrumentpanel.

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=bounce.leverantör-e-post.se;
  dkim=pass header.d=leverantör-e-post.se;
  dmarc=fail (p=NONE) header.from=example.com

Läs den från vänster till höger. SPF passerade för bounce.leverantör-e-post.se. DKIM passerade för leverantör-e-post.se. DMARC misslyckades eftersom From-headern säger example.com och ingen passerad domän matchar det.

(p=NONE)-noten visar policyn mottagaren såg. Vid none levererades detta meddelande ändå. Vid reject skulle det ha studsade med ett 5.7.x-fel, och avsändaren hade fått reda på det från en kund.

Två checks fångar de flesta av dessa fall. Bekräfta header.d-värdet i DKIM-resultatet är din domän. Bekräfta sedan att smtp.mailfrom-domänen är din domän eller en underdomän till den.

SPF har en söklimitering som DMARC exponerar

SPF tillåter tio DNS-sökningar per utvärdering. Varje include: för en leverantör använder några av dem, och kapslade includes använder mer. Över tio och SPF returnerar ett permanent fel, vilket räknas som ett misslyckande.

Team med fem eller sex skickningsverktyg träffar detta utan att märka det, eftersom SPF-misslyckanden var osynliga innan DMARC-rapportering. När rua-rapporter kommer in är mönstret tydligt: en källa plötsligt misslyckas SPF över alla mottagare på dagen någon lade till en annan include:.

Det här är en anledning till att förlita sig på DKIM-justering som den primära vägen. DKIM överlever mest vidarebefordran, har ingen söklimitering, och är bunden till meddelandet snarare än den anslutande IP-adressen. Håll SPF giltigt, men bygg inte din DMARC-passage på det ensamt.

Vad DMARC inte gör

DMARC förhindrar exakt-domän-spoofing. Det stoppar inte lookalike-domäner (examp1e.com), det dömer inte innehåll, och det fixar inte ett dåligt avsändarrykte. En perfekt justerad domän som skickar till köpta listor hamnar fortfarande i skräp.

Det ersätter inte heller övervakning. Justering kan brytas tyst: en DNS-ändring tar bort en DKIM-väljare, en leverantör roterar nycklar, ett nytt verktyg börjar skicka utan din vetskap. Rapporter är hur du tar reda på det innan dina användare gör det.

Behandla DMARC-posten som vilken annan produktionskonfiguration som helst. Den hör hemma i versionsöversikt, ändringar går genom granskning, och rua-brevlådan behöver en ägare.

Innan du publicerar posten

Gå igenom detta en gång. Det tar under en timme för en enda domän.

• Lista varje system som skickar e-post som din domän: produkt, fakturering, supportdesk, CRM, marknadsföring, kalenderinbjudningar.

• Bekräfta att varje signerar DKIM med din domän, inte leverantörens.

• Ställ in en anpassad return-path där leverantören tillåter det.

• Välj en rua-destination någon kommer att läsa.

• Börja med p=none, och sätt datumet du planerar att granska det i kalendern.

• Kontrollera skräpfrekvensen i Google Postmaster Tools varje vecka under utrullningen.

Vart du går härifrån

Om du aldrig har tittat på dina rapporter, publicera p=none med en rua-adress idag och läs vad som kommer tillbaka om två veckor. Den första rapporten namnger nästan alltid åtminstone en avsändare ingen mindes. Nästa konkreta steg är att besluta vilka av dem du håller och implementera ändringar.