Defaults.Exposed › Åtgärder › Guides
DMARC p=none till p=reject utan att förlora legitim e-post: Den stegvisa utrullningen (2026)
Publicerad 2026-07-08
Siffror från 2026-06-29 · metodik v7. Aggregerade censusdata över 261 miljoner graderade domäner. Se hur vi graderar.
Flytta DMARC från p=none till p=reject i fyra steg: övervaka rua-rapporter i 2–4 veckor, åtgärda varje legitim avsändare, trappa upp p=quarantine med pct, sedan avvisa — hoppa aldrig direkt till reject. 70,368,600 av 261,086,232 graderade domäner sitter fast vid mjuk SPF utan DMARC-tillämpning, enligt Defaults.Exposed-censuset.
Det här är den operativa manualen: en stagstabell med exitkriterier, posten för varje steg, RFC 7489 pct-subtiliteten som ändrar vad “50%” betyder vid avvisning, och sp=-taggen för underdomäner. Om du bestämmer om du ska tillämpa, läs de 6 stegen i DMARC-mognad först — det är ramverket; och om policynivåerna i sig är nya för dig, vad p=none, p=quarantine och p=reject faktiskt betyder är introduktionen. Den här sidan handlar om utförandet.
Varför kan du inte hoppa direkt till p=reject?
Eftersom p=reject ber varje mottagare som följer DMARC att studsa e-post som misslyckas med DMARC — och tills du har tittat på dina rapporter vet du inte vad som misslyckas. Nästan varje domän som slår på övervakning upptäcker legitima avsändare den glömde: CRM:et, faktureringsvektyget, ett kontaktformulär. Hoppa till reject dag ett och den e-posten hamnar inte i skräppost; den försvinner vid SMTP-tidpunkten. Att förlora ett faktureringsutskick lär en organisation att frukta DMARC, och posten rullas tillbaka till p=none permanent — av 261,086,232 graderade domäner är 37,312,637 parkerade exakt där, och bara 10.59% (27,640,987) når någonsin en tillämpad policy.
Den andra anledningen är anpassning. DMARC godkänns bara när SPF eller DKIM godkänns och anpassas till den synliga From-domänen — SPF mot Return-Path (RFC5321.MailFrom)-domänen, DKIM mot signaturens d=. Tredjepartsleverantörer godkänns vanligtvis med SPF på deras domän, inte din, vilket är varför steget att åtgärda alla källor mest handlar om att aktivera varje leverantörs anpassade domän-DKIM — förklarat i DMARC misslyckas men SPF och DKIM godkänns.
Vilka är de fyra utrullningsstegen?
| Steg | Policypost | pct | Vad händer med e-post som misslyckas | Exitkriterier |
|---|---|---|---|---|
| 1. Övervaka | p=none; rua=mailto:… | — | Levereras normalt; du tar emot aggregerade rapporter | 2–4 veckors rapporter; varje avsändare i dem identifierad som legitim eller inte |
| 2. Åtgärda källor | p=none (oförändrad) | — | Levereras fortfarande normalt | Varje legitim källa godkänns med DMARC anpassad (anpassad domän-DKIM per avsändare); kvarstående misslyckanden är bara okänd/förfalskad trafik |
| 3. Karantän-upptrappning | p=quarantine | 10 → 25 → 50 → 100 | Provtagd andel hamnar i skräppostmappar; den ej provtagna andelen behandlas som p=none (levereras) | 1–2 veckor vid pct=100 utan att legitim e-post hamnar i karantän |
| 4. Avvisa | p=reject | 100 | Studsar vid SMTP-tidpunkten; avsändaren får ett studsmeddelande, mottagaren ser ingenting | Fortlöpande — behåll rua på för alltid för att fånga nya avsändare |
Data per 2026-06-29; policybeteende per RFC 7489.
Steg 3 är där domäner stannar eller panikerar. Skräppostsortering är återställbar — användare hittar e-posten, du sänker pct, du åtgärdar källan. Avvisning är inte återställbar, vilket är varför karantän vid pct=100 som körs rent är inträdesbiljetten till steg 4.
Hur kör du utrullningen, steg för steg?
- Kör den kostnadsfria sökningen på defaults.exposed innan du rör DNS. Den bekräftar din nuvarande policy och om SPF och DKIM finns på plats underneath — de två ben tillämpning vilar på.
- Aktivera övervakning om du inte har gjort det. Att publicera
p=nonemedrua=är femminuterssteget i “DMARC-policy inte aktiverad”. Samla in 2–4 veckors rapporter — tillräckligt för att fånga månadsvisa avsändare som faktureringsutskick. - Inventera varje källa i rapporterna. Sortera avsändare i dina, dina leverantörers och okända. Rårapporter anländer som XML — ett rapportbearbetningsverktyg (eller din leverantörs instrumentpanel) omvandlar dem till en läsbar avsändarinventering.
- Gör varje legitim källa till en godkänd anpassning. Aktivera varje leverantörs anpassade domän-DKIM (vanligtvis två CNAME-poster i deras instrumentpanel) så att signaturer bär din domän, inte deras. Föredra DKIM för anpassning: det överlever vidarebefordring, SPF gör det inte.
- Vänta på en ren fjortondagarsperiod. Lämna steg 2 bara när rapporterade misslyckanden uteslutande är trafik du inte känner igen — de förfalskningar du vill blockera.
- Flytta till
p=quarantine; pct=10— redigera den befintliga_dmarcTXT-posten (genomarbetat exempel: IONOS DMARC-konfiguration), och var uppmärksam på syntaxen: ett stavfel i policytaggen kan ogiltigförklara hela posten. Trappa upp pct till 25, 50, 100 under 2–4 veckor, titta på rapporter och supportärenden. Något legitimt i skräppost: sänk pct, åtgärda källan, fortsätt. - Flytta till
p=rejectefter 1–2 rena veckor vidpct=100. Behållrua=på permanent — varje nytt verktyg ditt företag tar i bruk är en framtida misslyckad avsändare.
Vad gör pct faktiskt? RFC 7489-subtiliteten
pct ber mottagare att tillämpa din policy på den procentandelen av e-post som misslyckas. Subtiliteten, från RFC 7489 §6.6.4: e-post som inte provtas faller inte tillbaka till “levereras normalt” — den får den näst-mindre-stränga policyn. Under p=quarantine; pct=25 behandlas de andra 75% som p=none och levereras. Men under p=reject; pct=50 sätts de andra 50% i karantän, inte levereras. Det finns ingen mjuk avvisning: det ögonblick din post säger reject, är varje misslyckat meddelande minst skräppostsorterat hos honoring-mottagare.
Använt med avsikt är det en funktion — p=reject; pct=1 beter sig som “sätt nästan allt i karantän, avvisa en liten ström”, en legitim slutlig uppkörningsfas. Två varningar: mottagare implementerar inte alla sampling identiskt, så behandla pct som en ungefärlig ratt; och ta bort taggen (eller sätt pct=100) när steg 4 är stabilt, så att din post säger vad du menar.
Vad sägs om underdomäner — sp=-taggen?
Som standard ärver underdomäner organisationsdomänens policy: p=reject på yourdomain.com täcker mail.yourdomain.com också. sp=-taggen låter dem avvika, i både användbara och farliga riktningar. Användbart: p=quarantine; sp=reject låser ner underdomäner du aldrig skickar från medan apex fortfarande är mitt i upptrappningen — bedragare riktar sig med avsikt mot underdomäner av övervakade domäner. Farligt: ett bortglömt sp=none undantar tyst varje underdomän från avvisningspolicyn du tillbringade sex veckor med att förtjäna. Kontrollera det i steg 4; om en underdomän genuint behöver en lösare policy, publicera en _dmarc-post på den underdomänen istället för att lätta upp alla av dem.
Innebär NIS2 att EU-företag måste göra detta?
DMARC fungerar identiskt överallt — ingenting i den här manualen förändras vid en EU-gräns. Vad som förändras är efterlevnadstrycket. NIS2 Artikel 21(2)(j) kräver att enheter i scope säkrar sina kommunikationer, och Kommissionens genomförandeförordning (EU) 2024/2690 specificerar de tekniska kraven för de digitala infrastrukturenheter den täcker — dess bilaga (punkt 6.7.2(k)) kräver en implementeringsplan för att driftsätta internationellt erkända moderna e-postsäkerhetsstandarder, och punkt 6.7.2(l) kräver DNS-säkerhetsbästa praxis. En tillämpad DMARC-policy, med SPF och DKIM underneath, är den erkända revisionsbara kontrollen för spoofing; p=none demonstrerar tydligt övervakning, inte säkring. Om dina kunder är i scope frågar deras leverantörsenkäter alltmer efter exakt detta.
Vanliga frågor
Hur lång tid tar hela utrullningen? Sex till tio veckor är typiskt: 2–4 veckor övervakning, 1–3 veckor åtgärdande av källor, 2–4 veckor upptrappning av karantän, sedan avvisning. Det är kalendertid, inte ansträngning — mest väntan på att rapporter ska bekräfta varje ändring. De 89.41% av 261,086,232 graderade domäner utan en tillämpad policy (data per 2026-06-29) är mestadels inte mitt i en utrullning; de startade aldrig klockan.
Kan jag hoppa över karantän och använda p=reject med ett lågt pct istället?
Du kan — per RFC 7489 §6.6.4 betyder p=reject; pct=10 att 10% avvisas och 90% sätts i karantän, ungefär sent steg 3. Men p=quarantine först är lättare att resonera om, och mottagare varierar i hur troget de samplar. Hur som helst är steg 1–2 icke förhandlingsbara: ingen tillämpningsvariant är säker medan legitima avsändare fortfarande misslyckas.
Vad sägs om e-post jag inte kan åtgärda — vidarebefordrare och e-postlistor? Vidarebefordring bryter SPF med avsikt, och vissa e-postlistor skriver om innehåll, vilket också bryter DKIM. Anpassad DKIM överlever vanlig vidarebefordring, vilket hanterar de flesta fallen; den lilla återstoden är varför karantänsteget finns — skräppostsortering är återställbar medan du bedömer. Detaljer i vidarebefordrad e-post misslyckas med SPF.
Är det tillräckligt att stanna vid p=quarantine?
Det är det mesta av värdet, och långt bättre än de 37,312,637 domänerna parkerade vid p=none (av 261,086,232 graderade, data per 2026-06-29) — men förfalskad e-post når fortfarande skräppostmappar, där folk fiskar upp den. Avvisning är slutpunkten: bara 10.59% av graderade domäner tillämpar överhuvudtaget, och att avsluta är vad kontrollanter, försäkringsbolag och enkäter krediterar.
Skicka ägaren rapporten
Om du kör den här utrullningen för en kund eller arbetsgivare är mållinjen visningsbar. Kör om den kostnadsfria sökningen efter att p=reject löser sig och vidarebefordra den graderade rapporten: domänen som rör sig till en tillämpad policy, tidsstämplad och på klarspråk. Den sidan svarar på e-postsäkerhetsraden vid förnyelse av cyberförsäkring och NIS2-drivna leverantörsenkäter bättre än en skärmdump av en DNS-panel — och den gör sex veckors noga, osynligt arbete synligt för den som betalar för det.
Kontrollera din DMARC-policy kostnadsfritt
Se vad din policy för närvarande är — och om SPF och DKIM kan bära tillämpning — privat och enbart för ägaren.
Kontrollera din domän → · Åtgärda DMARC → · “DMARC-policy inte aktiverad” — det ärliga första steget → · Enbart aggregerade data. Data lagras och behandlas inom EU.