DMARC från p=none till p=reject, steg för steg

De flesta domäner som har en DMARC-post börjar med p=none, och påfallande många blir kvar där. Det är ett bra första steg, men det skyddar inte mot något. Den här guiden tar er från p=none till p=reject i flera steg, så att förfalskad e-post i ert namn stoppas medan er egen e-post fortsätter att komma fram.

Exemplen använder example.com. Byt ut den mot er egen domän.

Vad p=none gör, och vad det inte gör

Med DMARC (RFC 7489) publicerar ni en policy i DNS. Den talar om för mottagande e-postservrar vad de ska göra med ett meddelande som påstår sig komma från er domän men inte klarar autentiseringen. DMARC-posten ligger på _dmarc.example.com:

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

Taggen p kan ha tre värden:

p=none gör alltså en användbar sak: har ni angett en rua-adress, skickar mottagarna sammanställda rapporter om vem som skickar e-post i er domäns namn. Det ger insyn, men stoppar ingenting. En förfalskad faktura från ekonomi@example.com levereras precis som om ni inte hade någon DMARC-post alls.

Flera stora e-postleverantörer kräver i dag att den som skickar mycket e-post har en DMARC-post, och p=none räcker för det kravet (Googles riktlinjer för avsändare). Att klara ett leveranskrav är inte samma sak som att skydda domänen mot förfalskning.

När klarar ett meddelande DMARC?

Ett meddelande klarar DMARC när SPF eller DKIM, eller båda, godkänns och stämmer överens med domänen i det synliga Från-fältet. Det kallas att de är i linje (alignment).

• SPF (RFC 7208) kontrollerar kuvertavsändaren, adressen i MAIL FROM som också syns som Return-Path. SPF är i linje när den domänen stämmer med Från-domänen.
• DKIM (RFC 6376) kontrollerar en signatur. DKIM är i linje när den signerande domänen, värdet d=, stämmer med Från-domänen.

Som standard är kontrollen avslappnad: mail.example.com räknas som i linje med example.com eftersom de har samma organisationsdomän. Ni kan göra den strikt med aspf=s och adkim=s, men för de flesta räcker den avslappnade.

Det är därför externa tjänster brukar vara det som ställer till det. En nyhetsbrevstjänst kan klara SPF för sin egen returdomän och signera med sin egen DKIM-nyckel. Båda kontrollerna godkänns, ingen av dem är i linje med example.com, och DMARC fallerar.

Innan ni skärper: hitta alla som skickar i ert namn

Gör en lista innan ni rör policyn. Vanliga avsändare:

• er e-posttjänst (Microsoft 365, Google Workspace eller egna servrar)
• verktyg för nyhetsbrev och marknadsföring
• CRM-system, kundtjänst- och ärendesystem
• fakturering, lön och HR-system
• formulär på webbplatsen, e-handel och bokningssystem
• övervakningsverktyg, skrivare och skannrar som skickar notiser
• byråer och partner som skickar för er räkning

Fråga den som äger varje tjänst vad den skickar och från vilken adress. Jämför sedan listan med de sammanställda rapporterna, för där dyker det upp avsändare som ingen kom ihåg.

Sikta på DKIM i linje för varje legitim avsändare i första hand. DKIM klarar vidarebefordran bättre än SPF. De flesta tjänster låter er publicera en DKIM-nyckel under er egen domän, ofta som en CNAME som pekar på en nyckel de sköter:

s1._domainkey.example.com.  3600  IN  CNAME  s1.domainkey.sender.example.

Om tjänsten stöder det bör ni också ställa in en egen returdomän (return-path) under er domän, så att SPF hamnar i linje. Ha bara en SPF-post, och håll er inom gränsen på tio DNS-uppslag som RFC 7208 sätter:

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:spf.sender.example ~all"

Läs de sammanställda rapporterna

Se till att DMARC-posten har en rua-adress och samla rapporter i minst några veckor. Avsändare som bara skickar varje månad eller kvartal, till exempel lönebesked och årsbesked, kräver ett längre fönster.

Ska rapporterna till en adress på en annan domän, måste den domänen publicera en post som tar emot dem, annars skickar mottagarna inga rapporter (RFC 7489, avsnitt 7.1):

example.com._report._dmarc.reports.example.net.  3600  IN  TXT  "v=DMARC1"

Rapporterna är XML-filer, en per mottagare och dag. Ett verktyg eller en tjänst som tolkar dem sparar mycket tid. Titta på följande för varje avsändande IP-adress:

1. hur många meddelanden den skickade i er domäns namn
2. om SPF godkändes, och om det var i linje
3. om DKIM godkändes, och om det var i linje
4. vilket DMARC-resultat det blev

Sortera det ni hittar i tre grupper. Egna tjänster som klarar DMARC: klart. Egna tjänster som inte klarar det: rätta SPF eller DKIM och vänta in rena rapporter. Källor ni inte känner igen: oftast förfalskning, alltså precis det som en skarpare policy ska stoppa. Undersök ändå varje källa innan ni avfärdar den.

Ni är redo för nästa steg när all legitim e-post klarar DMARC med SPF eller DKIM i linje, och det som fortfarande fallerar antingen är förfalskat eller indirekt e-post som ni förstår (se vanliga problem nedan).

Gå till p=quarantine, gradvis

Taggen pct gör att policyn bara gäller en andel av den e-post som fallerar. Enligt RFC 7489 behandlas meddelanden utanför den andelen enligt nästa mildare policy, så p=quarantine; pct=10 sätter ungefär vart tionde underkänt meddelande i karantän och behandlar resten som p=none.

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-rapporter@example.com"

Höj pct i steg, till exempel 10, 25, 50 och 100, med en eller två veckors rapporter mellan varje steg. Håll utkik efter nya källor som fallerar och efter klagomål om e-post som inte kommit fram. Om något går sönder sänker ni pct eller går tillbaka till p=none medan ni rättar felet. Ändringen slår igenom så snabbt som TTL-värdet i er DNS tillåter.

Mottagare följer pct olika noggrant, och i den revidering av DMARC som IETF arbetar med (kallad DMARCbis) ersätts taggen av en enklare testflagga. Se pct som ett sätt att begränsa skadan om något går fel, inte som en exakt ratt.

Gå till p=reject

När karantän på 100 procent har fungerat utan problem i några veckor, byter ni till reject. Ni kan trappa upp på samma sätt: med p=reject; pct=50 hamnar meddelandena utanför urvalet i karantän i stället för att levereras.

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

Behåll rua-adressen. Arbetet är inte slut för att policyn är skarp. Nya tjänster tillkommer, nycklar byts ut och leverantörer byter plattform, och det är i rapporterna ni ser det.

Subdomäner och taggen sp

Utan taggen sp ärver subdomänerna organisationsdomänens p-policy. Det är oftast vad ni vill, eftersom en angripare kan förfalska faktura.example.com lika lätt som example.com.

Använd sp när subdomänerna behöver gå i en annan takt. Ni kan till exempel skärpa huvuddomänen medan en subdomän som används av ett äldre system fortfarande rättas:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc-rapporter@example.com"

En subdomän kan också ha en egen DMARC-post på _dmarc.faktura.example.com, som då har företräde framför den överordnade för just det namnet. När alla subdomäner är klara tar ni bort sp eller sätter den till reject.

Domäner som aldrig skickar e-post bör säga det. Parkerade domäner och domäner ni har registrerat för att skydda varumärket är lätta att förfalska och lika lätta att låsa:

example.org.         3600  IN  TXT  "v=spf1 -all"
_dmarc.example.org.  3600  IN  TXT  "v=DMARC1; p=reject"

Vanliga problem och hur ni löser dem

De flesta problem kommer från e-post som inte går direkt från avsändare till mottagare. RFC 7960 beskriver dem i detalj.

• Vidarebefordran. När en brevlåda vidarebefordrar ert meddelande blir den vidarebefordrande servern avsändare, och SPF fallerar. En oskadd DKIM-signatur godkänns fortfarande och är fortfarande i linje. Det är huvudskälet till att få DKIM i linje för varje avsändare, inte bara SPF.
• E-postlistor. Listor lägger ofta till en sidfot eller märker ämnesraden, vilket bryter DKIM-signaturen. Många listservrar skriver därför om Från-adressen till sin egen domän. Vissa mottagare använder ARC (RFC 8617) för att lita på det autentiseringsresultat listan såg, men det går inte att räkna med överallt.
• Externa tjänster. En tjänst som skickar med sin egen returdomän och sin egen DKIM-nyckel fallerar DMARC för er domän. Sätt upp DKIM under er domän för tjänsten, eller flytta den till en subdomän med egna poster.
• Bortglömda avsändare. Enheter och äldre system som skickar via en relay utan autentisering syns i rapporterna som underkända källor inifrån ert eget nät. Låt dem skicka via en tjänst med autentisering.
• För många SPF-uppslag. Lägger ni till en include för varje tjänst, kan SPF gå över tio uppslag, och då behandlar mottagarna posten som felaktig. Välj hellre DKIM i linje för mindre avsändare än ännu en include.

Så visar TrustSek varje steg

TrustSek läser den DMARC-post ni publicerar i DNS, tillsammans med SPF, DKIM-nycklar och övriga e-postposter i modulen e-postsäkerhet. Vi tar inte emot och läser inte era sammanställda rapporter, och en kontroll är en avläsning vid ett enda tillfälle.

Det här visar en kontroll i varje läge:

• Ingen DMARC-post. Ett fynd om att DMARC-posten saknas, med allvarlighetsgrad Hög.
• p=none. Fyndet om att DMARC-policyn är satt till none, med allvarlighetsgrad Medel. Det kopplas till skyddsåtgärd 9.5 i CIS Controls och till åtgärd A.8.9 i ISO/IEC 27001:2022.
• p=quarantine eller p=reject. Inget fynd om DMARC-policyn. Kontrollen tar inte hänsyn till pct, så en post med karantän och pct=10 räcker redan för att fyndet ska försvinna. Se inte det som att ni är i mål.

SPF-posten bedöms efter hur den slutar. En post som slutar med +all ger ett fynd med allvarlighetsgrad Hög, en post helt utan all-mekanism ger Medel, och ~all eller -all ger inget fynd. DKIM-nycklar som hittas genom att vi provar vanliga selektorer kontrolleras för sin nyckellängd.

Så här ser fyndet för p=none ut i en rapport:

Varje fynd har de fyra fälten som syns här: vad som testades, varför det spelar roll, vilken konsekvens det kan få och hur ni åtgärdar det. Hur allvarlighetsgraderna vägs in i poängen beskrivs i metoden. Begrepp som DMARC, SPF och DKIM förklaras i ordlistan.

Kontrollera er domäns DMARC och resten av e-postsäkerheten

Se vilken DMARC-policy er domän publicerar i dag, tillsammans med SPF, DKIM, MTA-STS och resten av bedömningen utifrån.

Er domän

Kontrollera er domän

Gratis, inget konto behövs. Tar ungefär 30 sekunder.