Defaults.Exposed › Åtgärder › Guides

"DMARC-policy inte aktiverad": Vad verktyg menar, och det ärliga 5-minuterssteget (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.

“DMARC-policy inte aktiverad” betyder en av två olika saker: din domän har ingen DMARC-post alls, eller den har en inställd på p=none. Bara 10.59% av domäner — 27,640,987 av 261,086,232 — tillämpar en DMARC-policy, enligt Defaults.Exposed-censuset. Att publicera en övervaknings­post tar fem minuter; tillämpning är ett projekt.

Den här guiden avkodar varningen, ger dig den exakta TXT-posten att publicera och exakt var den ska placeras, går igenom syntaxfelen som gör första försök att misslyckas, och sätter ärliga förväntningar på hur din första vecka med DMARC-rapporter ser ut. Det är medvetet inte en “åtgärda DMARC på 5 minuter”-guide — de fem minuterna ger dig synlighet, inte skydd.

Vad betyder “DMARC-policy inte aktiverad” egentligen?

Verktyg som MXToolbox slår ihop två olika fynd till en orange varning, och lösningsvägen beror på vilken du har:

Data per 2026-06-29.

Den första raden är där det mesta av internet befinner sig: 75.11% av graderade domäner publicerar ingen DMARC-post alls, och ytterligare 14.29% stannar vid p=none. Inversen av den sista raden är det tal som spelar roll: 89.41% av domänerna saknar en tillämpad DMARC-policy — av 261,086,232 graderade domäner i censuset. Om ditt verktyg visar varningen befinner du dig i den överväldigande majoriteten. Det är inte tröst; det är anledningen till att spoofing förblir billigt.

En klarläggning som sparar förvirring senare: DMARC är policylayret ovanpå SPF och DKIM, kontrollerat mot From-rubriken som din mottagare faktiskt ser. “Inte aktiverad” innebär att du ännu inte har berättat för mottagare att göra något. Om de tre policyvärdena är nya för dig, är förklaringen på klarspråk vad är DMARC: none, quarantine, reject.

Vad kan du ärligt åtgärda på fem minuter?

Att publicera en post. Det är hela det ärliga påståendet.

v=DMARC1; p=none; rua=mailto:[email protected]

Fem minuter efter att den här TXT-posten är aktiv börjar mottagare som kontrollerar DMARC att sammanställa dagliga rapporter om vem som skickar e-post som din domän — legitima servrar och bedragare lika. Den synligheten är genuint värdefull och genuint omedelbar.

Vad den inte gör: p=none skyddar ingenting. Förfalskad e-post levereras precis som igår, och ett verktyg som skannar på nytt imorgon kan fortfarande säga “policy inte aktiverad” — korrekt, för den gröna bocken är reserverad för quarantine eller reject. Vi har skrivit om varför i p=none är inte skydd; den graderade vägen till en policy som faktiskt blockerar spoofing är från p=none till p=reject. Femminuterssteget nedan är hur du börjar; den guiden är hur du avslutar.

Hur publicerar du din första DMARC-post?

1. Kör den kostnadsfria sökningen innan du rör DNS. Den talar om vilket av de två fynden du faktiskt har — ingen post kontra p=none — och om SPF och DKIM finns på plats underneath, vilket avgör hur snabbt du kan gå till tillämpning senare.
2. Välj en adress att ta emot rapporter. En dedikerad postlåda som dmarc-reports@yourdomain fungerar bra att börja med. Om du använder en rapportanalystjänst istället, se FAQ nedan — tredjepartsadresser har en tyst fallgrop.
3. Lägg till en TXT-post vid hosten _dmarc. I de flesta DNS-kontrollpaneler (se IONOS DMARC-konfigurationsguiden för ett genomarbetat exempel) skriver du in _dmarc i host/name-fältet — panelen lägger till din domän automatiskt och ger _dmarc.yourdomain.com. Värde: v=DMARC1; p=none; rua=mailto:[email protected]
4. Verifiera att den löste sig. dig TXT _dmarc.yourdomain.com (eller valfri nätbaserad kontrollant) bör returnera exakt en post som börjar med v=DMARC1. De flesta DNS-ändringar är synliga inom minuter; en låg TTL hjälper.
5. Scanna igen. Din rapport visar DMARC i övervaknings­läge — en ärlig bild av var du är: rapportering på, tillämpning väntande.

En post täcker dina underdomäner också: mottagare som inte hittar en post på mail.yourdomain.com faller tillbaka på organisationsdomänens policy, så du behöver inte en post per underdomän för att börja övervaka.

Vad är de vanligaste misstagen när man lägger till posten?

Nästan varje misslyckat första försök är ett av dessa — och de spelar roll, för en post som inte kan tolkas behandlas som ingen post. Censuset räknar 48,648 publicerade DMARC-poster som inte kan tolkas; stavfelen som folk faktiskt publicerar är katalogiserade i DMARC-stavfels-censuset.

• Fel host. Posten måste ligga på _dmarc.yourdomain.com, inte på toppdomänen. På den bara domänen gör den ingenting, och verktyg fortsätter rapportera “ingen DMARC-post hittades”.
• Dubbel domänbilaga. Att skriva _dmarc.yourdomain.com i en panel som lägger till automatiskt ger dig _dmarc.yourdomain.com.yourdomain.com. Skriv bara _dmarc.
• Kommatecken istället för semikolon. Taggar separeras med ;. En post som inte kan tolkas behandlas som ingen post.
• Saknad eller felplacerad v=DMARC1. Det måste vara den första taggen, stavad exakt; poster som börjar med p= misslyckas med tolkning.
• mailto: saknas från rua. rua=dmarc@yourdomain är ogiltigt; det måste vara rua=mailto:[email protected].
• Två DMARC-poster. Mottagare som hittar mer än en v=DMARC1-post ignorerar dem alla — samma felfamilj som SPF med flera poster.
• Typografiska citationstecken från klipp-och-klistra. Kursiva citationstecken eller hårda blanksteg som smugit in från ett dokument bryter tolkning. Skriv om posten om ett verktyg säger att den är felformaterad men ser rätt ut.

Hur ser rua-rapporterna ut i vecka ett?

Sätt förväntningarna nu så att du inte drar slutsatsen att det är trasigt:

• De anländer ungefär dagligen, per mottagare. Google skickar vanligtvis en aggregerad rapport var 24:e timme; Microsoft, Yahoo och andra på sina egna cykler. För en liten domän innebär vecka ett vanligtvis en handfull e-postmeddelanden, mestadels från [email protected].
• De är komprimerade XML-bilagor, inte en instrumentpanel. I råformat är de nästan oläsliga; ett gratis tolkningsverktyg omvandlar dem till en avsändaröversikt.
• Volymen spårar din e-postvolym. Om du skickar lite e-post, eller mestadels till leverantörer som inte rapporterar, räkna med glesa data. Två lugna veckor är normalt för en domän med liten volym — verifiera posten med dig snarare än att anta att den misslyckades.
• Räkna med överraskningar. De flesta domäner upptäcker avsändare de glömde — CRM:et, faktureringsverktyget, kontaktformuläret. Var och en behöver SPF eller DKIM anpassat innan du kan tillämpa. Om rapporter visar att DMARC misslyckas medan SPF och DKIM individuellt godkänns, är det ett anpassningsproblem — se DMARC misslyckas men SPF och DKIM godkänns.

Och be faktiskt om rapporterna: 64.3% av domäner med en DMARC-post publicerar ingen rua=-adress, så de får inga rapporter från den — censusuppdelningen på det finns i DMARC publicerat blint. Allt du lär dig här matar in i tillämpningslanseringen — övervakning är vecka ett av det projektet, inte ett mål i sig. Att parkera vid p=none på obestämd tid är det vanligaste sättet domäner hamnar i 89.41%.

Vanliga frågor

Kommer publicering av p=none att skada min e-postleveransbarhet? Nej. p=none ändrar ingenting om hur mottagare behandlar din e-post — det begär bara rapporter. Det kan hjälpa: Googles och Yahoos krav på bulk-avsändare kräver minst en p=none DMARC-post från storskaliga avsändare, så att publicera en är en efterlevnadsnivå, inte en risk.

Jag publicerade posten — varför säger verktyget fortfarande “policy inte aktiverad”? Eftersom det talar sanning: din policy är none, och verktyg reserverar godkännandet för quarantine eller reject. Du har anslutit dig till domänerna som övervakar men inte tillämpar — per 2026-06-29 tillämpar bara 10.59% av 261,086,232 graderade domäner. Varningen försvinner när du slutför utfasningen till tillämpning.

Behöver jag ha SPF och DKIM konfigurerat innan jag lägger till DMARC? Du behöver minst en av dem, anpassad, för att din e-post ska godkännas med DMARC — men du behöver inte ha dem perfekta innan du publicerar p=none. Övervakning är exakt hur du hittar vad som är trasigt: 70,368,600 av 261,086,232 graderade domäner (per 2026-06-29) har mjuk SPF och ingen DMARC-tillämpning, och rapporter är hur de skulle lära sig vad som fördröjer dem.

Kan jag skicka rapporter till en tredjepartsanalysator istället för min egen postlåda? Ja — men en rua-adress på en annan domän kräver att leverantören publicerar en auktoriseringspost (yourdomain._report._dmarc.vendor.com), annars håller mottagare rapporter tillbaka i tysthet. Välrenommerade tjänster gör detta automatiskt; om rapporter aldrig anländer, kontrollera detta först.

Skicka ägaren rapporten

Om du åtgärdar detta för en kund eller arbetsgivare, låt inte arbetet vara osynligt. Kör den kostnadsfria sökningen efter att posten löser sig och vidarebefordra den graderade rapporten: den visar DMARC som rör sig från frånvarandetill övervakat, tidsstämplad och på klarspråk — och den visar vad som är nästa steg på vägen till tillämpning. Ägare behöver alltmer exakt detta bevis vid förnyelse av cyberförsäkring och leverantörers säkerhetsenkäter, och en ensides graderad rapport svarar på de frågorna bättre än en skärmdump av en DNS-panel någonsin kommer att göra.

Kontrollera din domän kostnadsfritt

Se vilket av de två fynden du har — ingen post eller p=none — och vad som finns underneath, privat och enbart för ägaren.

Kontrollera din domän → · Åtgärda DMARC → · Från p=none till p=reject → · Hur vi graderar → · Enbart aggregerade data. Data lagras och behandlas inom EU.