DMARC utrullning: från none till reject

Modul 4: Leveransbarhet: SPF, DKIM och DMARC i praktiken · Lästid: 12 minuter

Lärandemål: Efter den här lektionen kan du förklara hur uppriktning fungerar, planera en DMARC-utrullning i faser från p=none till p=reject, välja rätt taggar (rua, sp, np, t) och hantera de kända fallgroparna vid vidarebefordran och e-postlistor.

Nyckelbegrepp: DMARC (RFC 9989), Author Domain (domänen i Från), uppriktning (alignment), relaxed och strict (adkim, aspf), organisationsdomän, DNS tree walk, p=none, p=quarantine, p=reject, rua, sp, np, t=y (testläge), utgångna taggar pct, rf, ri, e-postlistor, omskrivning av Från, ARC

Vad DMARC egentligen kontrollerar

DMARC besvarar en enda fråga för varje inkommande mejl: har SPF eller DKIM lyckats för en domän som hör till Från-adressen? Domänen i Från-adressen kallas i standarden Author Domain. Grunderna för posten finns i DNS-kursen, lektion 4.5. I maj 2026 publicerades den reviderade standarden: RFC 9989, med RFC 9990 för aggregerade rapporter och RFC 9991 för felrapporter. Befintliga poster med v=DMARC1 fortsätter att gälla.

Uppriktning i praktiken

"Hör till" kallas uppriktning (alignment). Det finns två lägen:

• relaxed (standard): domänerna har samma organisationsdomän. nieuws.example.com och example.com är uppriktade; example.com och example.net är det inte.
• strict (adkim=s eller aspf=s): domänerna måste vara exakt lika.

För SPF jämför DMARC domänen i Return-Path med Från-domänen. För DKIM jämförs d=-domänen i en giltig signatur. Några exempel för ett mejl med Från: info@example.com:

Låt alltså adkim och aspf stå kvar på relaxed, om du inte har en god anledning att ändra.

Hur vet en mottagare vad som är organisationsdomän? Förr användes Public Suffix List, en lista med domäner som .nl, .co.uk och github.io. RFC 9989 ersätter det med en DNS tree walk: mottagaren slår upp _dmarc-poster för domänen och alla överliggande domäner. För en vanlig användare förändras ingenting; du märker det bara om du arbetar med poster på subdomäner.

Utrullningen i fyra faser

Målet är p=reject: då nekar mottagare mejl som utger sig för att vara du, och det är det bästa skyddet mot falska fakturor och phishing i ditt namn. Men den som går direkt till reject utan att känna till sina avsändare kommer att neka sina egna fakturor. Därför den här ordningen (rekommendationen i den här kursen):

Fas 0: förbereda

• Gör en inventering av alla dina avsändare (lektion 4.2).
• Se till att varje avsändare har SPF eller DKIM uppriktat; helst DKIM, eftersom det överlever vidarebefordran.
• Skapa en separat adress för rapporter, till exempel dmarc@example.com, eller använd en rapporttjänst. Du får snabbt flera rapporter per dag.

Fas 1: mäta med p=none

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

p=none gör ingenting med själva mejlet. Mottagare levererar allt som vanligt, men skickar dig dagligen en aggregerad rapport (aggregate report) med varje server som mejlade å din domäns vägnar och om SPF, DKIM och DMARC lyckades. Därmed uppfyller du även minimikravet från Gmail, Yahoo och Microsoft för massavsändare (lektion 5.3).

Låt det här stå i minst två till fyra veckor, och längre om du har tjänster som bara mejlar ibland (en årlig påminnelse, en kvartalsvis faktura). Läs rapporterna (lektion 4.5) och åtgärda varje egen källa som misslyckas.

Fas 2: p=quarantine

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

Mejl som inte klarar DMARC hamnar hos mottagaren i skräppostmappen. Glömmer du ändå en källa är mejlet inte borta, men svårt att hitta. Vill du vara försiktig, lägg då först till t=y (testläge): mottagare tillämpar då en nivå mildare policy (vid quarantine alltså none), men du ser i rapporterna vad som skulle hända. Det här är i RFC 9989 ersättaren för den gamla taggen pct=.

Titta igen på rapporterna under några veckor.

Fas 3: p=reject

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

Mejl som inte klarar DMARC avvisas. Avsändaren får en bounce, hos Microsoft till exempel med koden 5.7.509 och hos Gmail med en hänvisning till DMARC-policyn (modul 6). Fortsätt följa rapporterna: nya tjänster tillkommer alltid.

När kan det gå snabbare?

Går all din mejl via en enda leverantör som sköter SPF och DKIM åt dig, och skickas inget annat i din domäns namn? Då kan en sträng policy sättas direkt. Vissa webbhotell sätter därför p=reject som standard. Börjar du senare använda en nyhetsbrevstjänst eller ett bokföringsprogram, sätt då tillfälligt tillbaka till p=none med en rapportadress, tills den tjänsten fungerar korrekt.

De andra taggarna

En rapportadress på en annan domän (till exempel en rapporttjänst) fungerar bara om den domänen ger tillstånd med en post som example.com._report._dmarc.rapportdienst.example. Tjänsten ordnar oftast det själv (RFC 9990, kapitel 4).

Fallgropar

E-postlistor

En klassisk e-postlista vidarebefordrar ditt mejl till alla medlemmar, från sin egen server, och lägger ofta till [lista] i ämnesraden eller en sidfot. Då misslyckas SPF (annan server) och DKIM (mejlet ändrat). Med p=reject nekar mottagarna ditt meddelande till listan. Modern listprogramvara löser det genom att skriva om Från-adressen till listans adress ("Jan via Medlemmar"), eller genom att vidarebefordra mejlet oförändrat. Använder du en lista som inte gör det, ser du det i dina rapporter.

Vidarebefordran

Se lektion 3.3: SPF går sönder, DKIM överlever oftast. En mottagare kan med ARC besluta att lita på en känd vidarebefordrare. I rapporterna känner du igen detta som mejl från en okänd server med DKIM pass och SPF fail; det är ingen anledning att göra din policy mildare.

Två poster eller ett skrivfel

Två DMARC-poster på _dmarc gör policyn ogiltig, och ett skrivfel i p= likaså (p=rejected finns inte). Kontrollera efter varje ändring.

I praktiken: så ser det ut i en panel

I ett webbhotellpaket från WebOké är v=DMARC1;p=reject standard, utan rapportadress. Det är säkert om all din mejl går via de servrarna. Mejlar du även via andra tjänster, sätt det då till p=none med en rua-adress och arbeta igenom faserna. I DirectAdmin gör du det under DNS-administration med pennan bakom _dmarc-posten (fälten Domänpolicytyp och Aggregerad e-post (RUA)); i Mitt WebOké med DMARC-hjälpen under fliken DNS. Hos andra leverantörer skapar du en TXT-post på namnet _dmarc och skriver texten själv; resultatet blir detsamma.

Sammanfattning

• DMARC lyckas om SPF eller DKIM lyckas för en domän som är uppriktad med Från-domänen; relaxed uppriktning accepterar subdomäner.
• Utrullning: inventering, p=none med rua och läsning av rapporter, p=quarantine (eventuellt med t=y), och sedan p=reject.
• Använd np=reject för subdomäner som inte finns så fort huvudpolicyn är sträng. pct, rf och ri är utgångna.
• E-postlistor och vidarebefordran ger förväntade fel; DKIM och ARC fångar upp en del av dem.
• Exakt en post på _dmarc, utan skrivfel.

Quiz

Uppgift

Uppgift Z4.4: Kontrollera DMARC för din domän och välj nästa steg. Fyll i din egen domän (eller internet.nl). Fyll i DMARC-posten som du hittade den, värdet på p= och om det finns en rua-adress i den. Välj sedan vilken fas av utrullningen du tycker är nästa steg, och varför. Programmet hämtar posten live, kontrollerar syntaxen enligt RFC 9989 (en post, giltig p, kända taggar, utgångna taggar som varning), och ställer dina svar bredvid.

Läs mer

Stegen i de här artiklarna gäller för panelerna hos WebOké; hos andra leverantörer fungerar det på liknande sätt.

• Gratis DNS-kurs 4.5: DMARC: vad mottagare ska göra med falsk e-post
• DirectAdmin-guide 5.9: DMARC ställa in
• Vad är DMARC? Förklaring i vanligt språk
• Skapa DMARC-post i DirectAdmin
• RFC 9989 (DMARC), särskilt 4.7 (taggar) och bilaga C (ändringar sedan RFC 7489)