DMARC-övervakning: så läser du rapporterna och når p=reject säkert
Mer än hälften av alla domäner med DMARC-post samlar inte in några rapporter alls. Så fungerar DMARC-övervakning, så läser du en aggregerad rapport, vad RFC 9990 ändrade 2026 och hur du når p=reject utan att blockera din egen e-post.
Kör samma kontroll direkt – gratis
Ange din domän och få en 9-punkts audit – DNS, SPF/DKIM/DMARC, SSL, säkerhetsheaders, dark web-exponering – på 60 sekunder.
Ingen registrering · <60s · GDPR/EU-hantering
DMARC-övervakning innebär att du samlar in och läser de aggregerade rapporter som e-postmottagare skickar tillbaka till din domän varje dag, så att du ser exakt vem som skickar e-post i ditt namn innan du växlar din policy till quarantine eller reject. Du slår på det genom att lägga till en rua=mailto:-tagg i din DMARC-post. Inom 24 till 48 timmar börjar leverantörer som Google, Microsoft 365 och Yahoo skicka komprimerade XML-filer som sammanfattar varje meddelande som utgett sig för att komma från din domän. De filerna är det enda underlag du får, och utan dem blir övergången till skarp policy en gissningslek.
Vad DMARC-övervakning faktiskt är
DMARC (Domain-based Message Authentication, Reporting and Conformance) gör två saker. Policydelen talar om för mottagare vad de ska göra med e-post som inte klarar autentiseringen. Rapporteringsdelen talar om för dig vad mottagarna ser. Övervakning är den andra halvan, och det är den de flesta domänägare hoppar över.
Mekanismen är enkel. När en mottagande leverantör bedömer e-post som anger din From-domän räknar den resultaten. I slutet av varje UTC-dygn paketeras siffrorna i en XML-fil som mejlas till adressen i din rua=-tagg. RFC 9990 avsnitt 3.1.1.4 anger att rapportperioden omfattar ett enda UTC-dygn som börjar 00:00 UTC. Det är därför din första rapport dyker upp 24 till 48 timmar efter att du publicerat taggen, inte direkt.
Rapporterna är gzip-komprimerade och små. Uppmätta filstorlekar per leverantör låg mellan 3,6 kB och 4,8 kB (Google 3 962 byte, Yahoo 4 626, Fastmail 4 839) i datamängden som Ashiq med flera publicerade på USENIX Security 2023. Lagring är aldrig problemet. Volymen är det: en domän med mycket trafik kan få hundratals filer per dygn, vilket är skälet till att nästan ingen läser dem för hand.
Mer än hälften av alla DMARC-domäner flyger blint
DMARC-policyfördelning bland de 1 670 975 domäner som publicerar en post. Källa: DMARCguard, State of Email Authentication 2026, skanning av 5 499 028 Tranco-domäner, 27 februari 2026.
Samma skanning visade att bara 894 057 av dessa 1 670 975 domäner (53,5 %) publicerar en rua=-tagg. De övriga 776 918 har en policy men ingen telemetri alls.
Följden syns i policyfördelningen ovan. 57,9 % av DMARC-domänerna, 967 474 stycken, ligger kvar på p=none. Rent övervakningsläge är tänkt som en mellanstation, inte en slutdestination, och skälet till att så många aldrig lämnar det är enkelt: utan rapporter finns inget att grunda beslutet på.
Riskerna är inte teoretiska. FBI:s Internet Crime Complaint Center registrerade 2,77 miljarder dollar i förluster från Business Email Compromise fördelat på 21 442 anmälningar i sin årsrapport för 2024. På den andra sidan av vågskålen: efter att Google och Yahoo införde autentiseringskrav för massutskick i februari 2024 rapporterade Gmail 265 miljarder färre oautentiserade meddelanden under året (Neil Kumaran, Group Product Manager, Gmail Security and Trust, oktober 2024).
Så slår du på rapporteringen
Lägg till en rua=-tagg i TXT-posten på _dmarc.dindoman.se:
v=DMARC1; p=none; rua=mailto:dmarc-rapporter@dindoman.se; fo=1
Kontrollera vad som är publicerat med en DNS-uppslagning:
dig +short TXT _dmarc.dindoman.se
Tre regler värda att känna till innan du redigerar DNS:
- Endast en post. RFC 9989 kräver exakt en DMARC TXT-post per domän. Publicerar du två tillämpar mottagarna ingen policy alls, vilket i praktiken stänger av DMARC.
- Ingen
rua=betyder inga rapporter. Mottagare får inte generera aggregerad återkoppling utan taggen. Det finns ingen annan väg in. - Täckningen är ofullständig av design. Microsofts egen dokumentation, uppdaterad 14 maj 2026, anger att alla mottagare inte skickar rapporter och att täckningen typiskt ligger på 70 till 90 procent av den totala e-postvolymen. Apple iCloud och Proton är inte dokumenterade som rapportavsändare över huvud taget.
Att skicka rapporter till en annan domän
Om din rua=-adress ligger på en annan organisationsdomän än policyn måste den mottagande domänen godkänna det. RFC 9990 avsnitt 4 kräver en TXT-post på <din-domän>._report._dmarc.<rapportdomän> som innehåller v=DMARC1;. Utan den slutar mottagarna tyst att skicka. Det här är den enskilt vanligaste orsaken till att en korrekt skriven rua=-tagg inte ger några rapporter alls.
Aggregerade rapporter jämfört med felrapporter
| Aggregerade rapporter (RUA) | Felrapporter (RUF) | |
|---|---|---|
| Specifikation | RFC 9990 | RFC 9991 |
| Frekvens | En gång per UTC-dygn och leverantör | Nära realtid, per meddelande |
| Innehåll | Antal per käll-IP med SPF- och DKIM-justering samt tillämpad disposition | Detaljer om ett enskilt misslyckat meddelande, eventuellt med rubriker och brödtext |
| Integritet | Aggregerade siffror, inget meddelandeinnehåll | RFC 9991 anger att rapporter kan innehålla personuppgifter |
| Leverantörsstöd | Brett: Google, Microsoft 365, Yahoo, Mail.ru, Fastmail, Zoho | Ovanligt. Microsoft 365 skickar dem inte ens med giltig ruf= |
| Bäst för | Att bygga sändarinventeringen och avgöra när du kan skärpa policyn | Att felsöka ett specifikt fel du kan återskapa |
Börja med RUA. Nästan allt du behöver för att nå p=reject på ett säkert sätt finns i den aggregerade datan, och den saknar felrapporternas integritetsbagage.
Att läsa en rapport: de fyra utfall som spelar roll
Varje <record>-block i XML-filen kopplar ihop en käll-IP med ett meddelandeantal, de råa SPF- och DKIM-resultaten och en policy_evaluated-bedömning. Det som betyder något är justering (alignment), inte råautentisering. SPF eller DKIM måste både godkännas och matcha din From-domän för att DMARC ska godkännas.
| SPF justerad | DKIM justerad | Vad det betyder | Vad du gör |
|---|---|---|---|
| Godkänd | Godkänd | Friskt. Din egen infrastruktur, korrekt konfigurerad | Ingenting. Det här är målbilden för varje legitim avsändare |
| Godkänd | Underkänd | Avsändaren är auktoriserad men signerar inte, eller signerar med sin egen domän | Aktivera DKIM hos tjänsten och justera d=-domänen till din |
| Underkänd | Godkänd | Nästan alltid vidarebefordran eller en sändlista. DMARC godkänns ändå | Ofarligt. Lägg inte till vidarebefordraren i din SPF-post |
| Underkänd | Underkänd | Antingen en legitim avsändare du glömt, eller förfalskning | Identifiera IP-adressen. Auktorisera den, eller låt den blockeras vid skarp policy |
Tredje raden är den som oftast missförstås. Vidarebefordran bryter SPF av konstruktion, eftersom kuvertavsändaren byts ut vid vidarebefordringssteget. Det är precis därför DKIM behövs som reserv, och därför de 43,0 % av DMARC-domänerna som enbart förlitar sig på SPF-justering (DMARCguard, februari 2026) är sårbarare än de ser ut.
Vad som ändrades 2026: RFC 9989, 9990 och 9991
I maj 2026 publicerade IETF RFC 9989, RFC 9990 och RFC 9991. Tillsammans ersätter de RFC 7489 och flyttar DMARC till Standards Track som Proposed Standard för första gången sedan 2015, med rapporteringen utbruten i egna dokument.
| Detalj | RFC 7489 (2015) | RFC 9989 / 9990 (2026) | Vad du bör göra |
|---|---|---|---|
Taggen pct | Stöds, för gradvis utrullning | Borttagen | Sluta förlita dig på den. Använd nya testläget t=y |
Taggarna rf och ri | Definierade | Borttagna | Ta bort dem vid nästa DNS-ändring |
| Hitta organisationsdomänen | Public Suffix List | DNS tree walk | Ingenting. Det är en ändring på mottagarsidan |
| XML-namnrymd i rapporter | http://dmarc.org/dmarc-xml/0.1 | urn:ietf:params:xml:ns:dmarc-2.0 | Din parser måste acceptera båda |
DKIM-fältet selector | Valfritt | Obligatoriskt | Rätta generatorer eller parsrar som utelämnar fältet |
Värden för disposition | none, quarantine, reject | Lägger till pass | Hantera det nya värdet i stället för att avvisa filen |
| Okända element | Odefinierat | Ignorera och fortsätt (RFC 9990 avsnitt 5) | Avvisa aldrig en rapport du inte förstår fullt ut |
Din befintliga post fortsätter fungera. Taggarna v=, p=, sp=, rua=, ruf=, adkim=, aspf= och fo= behåller sin innebörd. I praktiken skickar alla stora leverantörer fortfarande XML i det gamla formatet, så räkna med ett blandat läge i flera år och tolka rapporterna tolerant snarare än strikt.
En säker utrullning i fyra steg till p=reject
- Vecka 1 till 2. Publicera
p=nonemedrua=. Ändra inget annat. Samla rapporter och bygg en lista över varje IP och tjänst som skickar i ditt namn. - Vecka 3 till 6. Åtgärda justeringen. Lägg till saknade avsändare i SPF, aktivera DKIM överallt och bekräfta att varje tredjepartstjänst signerar med din domän i stället för sin egen.
- Vecka 7 till 8. Gå till
p=quarantine, gärna först på en underdomän viasp=. Bevaka rapporterna i en hel vecka efter legitima avsändare du missat. - Vecka 9 och framåt. Gå till
p=rejectoch behållrua=permanent. Övervakning är ingen byggnadsställning du tar ner efteråt.
Att stressa igenom steg ett är det klassiska misstaget. En kvartalsvis fakturakörning eller en årlig kampanj syns inte i två veckors data, och den studsar den dag du skärper policyn.
Vanliga frågor
Hur ofta skickas DMARC-rapporter?
En gång per UTC-dygn och rapporterande leverantör, för ett fönster som börjar 00:00 UTC (RFC 9990 avsnitt 3.1.1.4). Din första rapport kommer normalt 24 till 48 timmar efter att du publicerat rua=.
Varför får jag inga rapporter?
Oftast ligger rua=-adressen på en annan domän och den obligatoriska godkännandeposten på <din-domän>._report._dmarc.<rapportdomän> saknas. Andra orsaker: syntaxfel i DMARC-posten, två publicerade DMARC-poster, eller helt enkelt ingen e-post som angett din domän under perioden.
Är DMARC-rapporten i min inkorg äkta?
Nästan säkert. Äkta rapporter använder ämnesmönstret Report Domain: <domän> Submitter: <rapportör> Report-ID: <id> och bifogar komprimerad XML med ett filnamn separerat av utropstecken. Äkta rapporter innehåller inga länkar att klicka på, inga betalningskrav och inga förfrågningar om inloggningsuppgifter.
Behöver jag övervakning även efter p=reject? Ja. Nya tjänster tillkommer, DNS redigeras, DKIM-nycklar roteras. Rapporterna är hur du upptäcker att något gått sönder innan kunderna gör det.
Kan jag bara radera rapporterna?
Du kan ta bort rua= för att stoppa dem, men då byter du en stökig inkorg mot noll insyn i vem som förfalskar din domän. Att peka rua= mot ett analysverktyg är ett bättre svar.
Kontrollera din konfiguration på 60 sekunder
Innan du rör DNS är det bra att veta exakt var du står. FortifyNets kostnadsfria skanning läser dina DMARC-, SPF- och DKIM-poster och visar om rapportering faktiskt är konfigurerad, om din policy är skarp och vad som saknas. Det tar ungefär en minut och kräver ingen registrering. Kör en gratis skanning hos FortifyNet.
Relaterade guider: Så konfigurerar du DMARC steg för steg · Vad är DKIM? · SPF-kontroll · DNS-säkerhetskonfiguration
