9 DMARC-fejl, der ødelægger din e-maillevering

Når _dmarc.ditdomæne.tld mangler i DNS-zonen, overlader du helt bogstaveligt din identitet til fri afbenyttelse:

• Spoofing bliver trivielt - enhver kan sætte From:-feltet til @ditdomæne.tld, fordi modtagende mailservere ikke har en entydig politik at håndhæve.
• Spam- og phishingfiltre står på bar bund og må gætte, hvilket ofte ender med at både falske og legitime mails ryger i karantæne.
• Domænets omdømme slides; hvis blot én stor udbyder (Gmail, Outlook, iCloud …) mærker et mønster af misbrug, kan hele domænet havne på interne bloklister.

Sådan publicerer du en basis-dmarc

1. Log ind i dit DNS-kontrolpanel (typisk hos registraren eller din hostingudbyder).
2. Opret en ny TXT-record:

   Host / Name	Type	TTL	Value (indhold)
   _dmarc	TXT	3600	v=DMARC1; p=none; rua=mailto:dmarc@ditdomæne.tld;

   Bemærk: Nogle kontrolpaneler kræver det fulde hosts-navn _dmarc.ditdomæne.tld. - andre blot _dmarc.

3. Gem og udrul. Afvent DNS-udbredelse (typisk få minutter, men op til 24 t).
4. Verificér med et dig/nslookup:

   dig txt _dmarc.ditdomæne.tld +short

   Output skal returnere nøjagtig den streng, du indsatte.

Hvad betyder felterne?

Du kan tilføje flere rapport-modtagere ved at kommaseparere dem, f.eks. rua=mailto:dmarc@ditdomæne.tld,mailto:[email protected]. Sender du rapporter til andre domæner, kræver modtageren en TXT-autorisation på siden example.dk (en såkaldt v=DMARC1 rua-permission-record).

Typiske faldgruber

• Flere DMARC-records på samme host - resulterer i “permerror”. Der må kun være én.
• Fejlagtige citationstegn; gem hele strengen i én par af anførselstegn eller lad panelet gøre det automatisk.
• Forkert label (f.eks. placere posten på bare ditdomæne.tld uden _dmarc-prefikset).

Når posten ligger korrekt, har du taget det første - og vigtigste - skridt mod at beskytte både dine brugere og din brandværdi. I de næste faser kan du hæve politikken til quarantine og til sidst reject, men ingen fremskridt er mulige uden den allerførste, lille TXT-linje.

Du har fået DMARC på plads — v=DMARC1; p=none — og de første rapporter tikker ind. Det er en god start, men hvis p=none bliver en permanent tilstand, er effekten af DMARC tæt på nul. Nedenfor ser vi på, hvad det koster at blive i overvågningstilstand, og hvordan du sikkert bevæger dig fra none → quarantine → reject uden at miste legitim e-mailtrafik.

Hvorfor p=none ikke er nok

• Ingen håndhævelse. Mailservere må gerne levere spoofede beskeder, så længe de blot rapporterer dem. Angribere kan fortsat udgive sig for dit domæne.
• Faldende afsender-ry. Store udbydere som Gmail og Microsoft giver mindre tillid til domæner, der aldrig bevæger sig ud af none. Det kan føre til spamfolder eller soft-bounce på legitime udsendelser.
• BIMI og andre tillids­signaler udebliver. Vil du have dit logo vist i indbakken, kræves typisk p=quarantine eller p=reject med DKIM-alignment.
• Ledelses-blindhed. Når der ikke er en dato for fuld håndhævelse, mister projektet momentum, og rapporterne ender i en glemt mappe.

En trin-for-trin plan mod fuld håndhævelse

* Tidsrammerne er vejledende og afhænger af organisations­størrelse og kompleksitet.

Praktiske tips undervejs

1. Udnyt rua-data aktivt. Konverter XML-rapporterne til dashboards (f.eks. via open-source-værktøjer eller kommercielle analysetjenester).
2. Brug fo=1 midlertidigt for at få failure-eksempler (RUF), når enkelte mails fejler.
3. Hold øje med spf- og dkim-pass-rate separat. En høj samlet DMARC-pass kan skjule problemer i den ene mekanisme.
4. Whitelist testkonti. Opret interne konti på Gmail, Outlook.com mm. og overvåg om nyhedsbreve, fakturaer m.m. stadig lander i indbakken.
5. Kommunikér internt. Sørg for at marketing, CRM-ejere og IT-service­desk ved, at politikken strammes, så de kan reagere hurtigt på problemer.

Afslutning

DMARC er et projekt, ikke en konfigurationslinje. Har du siddet fast på p=none i måneder eller år, er det tid til at lægge en tydelig køreplan og en deadline i kalenderen. Kun når politikken håndhæves, får du den fulde beskyttelse mod domænespoofing, bedre leveringsrate og de visuelle fordele som BIMI. Start småt med pct, lær af dine rapporter, og arbejd dig sikkert frem til p=reject.

Når en modtager-MTA verificerer din e-mail med DMARC, kigger den ikke kun på, om der er et gyldigt SPF- og/eller DKIM-pass, men også på hvilket domæne der består testen. Det er her begrebet identifier alignment kommer i spil.

Relaxed vs. Strict - Hvad er forskellen?

Hvorfor opstår misalignment?

1. Tredjeparts-platforme
   Marketing- eller nyhedsbrevs­systemer sætter ofte deres eget Return-Path, fx bounce.mailing-vendor.com, mens du har From: [email protected].
2. Forkerte DKIM-selectors
   En gateway eller signering i flere lag kan betyde, at den sidste DKIM-signatur kommer fra et andet domæne end det forventede.
3. Omdirigering/forward
   Ved klassisk e-mail-forward bevares From:, men Return-Path ændres, hvilket bryder SPF-alignment.
4. Fejlkonfigurerede underdomæner
   Mail fra [email protected] signeres måske med d=ditfirma.dk i stedet for d=info.ditfirma.dk.

Sådan får du alignment i orden

• Match domænerne bevidst
  Sørg for at Return-Path (ME-RFC5321.MailFrom) peger på det samme domæne som i From:. Er det ikke muligt (fx pga. tredjepart), så tillad kun relaxed alignment og lad underdomænerne være konsistente.
• Brug eget domæne hos leverandøren
  De fleste SaaS-platforme understøtter custom bounce-domæner. Opret fx bounce.ditfirma.dk og peg en CNAME til leverandøren, så både From: og Return-Path deler eTLD+1.
• Ensret DKIM-signering
  Konfigurer din MTA eller gateway til at signere med d= det samme (sub)domæne som i From:. Fjern eller overskriv gamle/eksterne signaturer, som kan skabe tvivl.
• Overvej strict hvor det giver mening
  Hvis du sender al trafik fra ét domæne og har fuld kontrol, kan aspf=s og adkim=s hæve sikkerheden - men test først!
• Monitorér via RUA-rapporter
  Hold øje med alignment-rate. Hvis legitime mails fejler pga. SPF eller DKIM-misalignment, er det tydeligt i rapporterne.

Eksempel på korrekt header-sæt

From: [email protected]: <[email protected]>DKIM-Signature: … d=ditfirma.dk; s=mail; …Received-SPF: Pass (ditfirma.dk: domain of [email protected] designates …)

Med både SPF og DKIM i pass og korrekt alignment vil DMARC-politikken kunne håndhæves uden risiko for at legitim mail bliver afvist.

En SPF-record bliver evalueret i real-time, hver gang en mailserver modtager en besked fra dit domæne. Reglen er enkel: højst 10 mekanismer, der kræver et eksternt DNS-opslag. Overskrider du grænsen, returnerer serveren resultatet permerror, og hele SPF-tjekket fejler - også selv om din afsender-IP egentlig er autoriseret.

Typiske syndere:

1. Dyb include-kæde: Hver include: kan gemme på nye include:, a og mx - summen tælles med.
2. Loop mellem domæner: Domæne A inkluderer B, som inkluderer A. Opslagene fortsætter, til grænsen (eller en time-out) rammes.
3. Legacy-poster ingen tør røre: Gamle marketingudbydere, som forlængst er udfaset, men stadig ligger i SPF-kæden.

~all vs. -all - Den evige spf-afslutning

Sidste mekanisme er altid all. Vælg mellem:

• ~all (SoftFail): Marker mailen som ”mistænkelig”, men tillad ofte levering til spam.
• -all (HardFail): Afvis eksplicit alt, der ikke matcher, hvis modtageren håndhæver SPF.

I en DMARC-kontekst er -all klart at foretrække, fordi kun HardFail medfører fail i DMARC-rapporterne. Har du endnu ikke overblik over alle afsendere, kan du midlertidigt blive på ~all - men sæt en intern deadline for at skifte.

Sådan tæmmer du spf-rekorden

1. Kortlæg alle afsendere. Brug DMARC-aggregate-rapporter eller logning på din mailgateway til at identificere reelle kilder.
2. Fjern døde entries. Hvis et mail-vendor ikke længere benyttes, fjern straks deres include:.
3. Flattening. Erstat include:-mekanismer med de konkrete IP-blokke, fx via scripts eller værktøjer som spf-flatten.py. Husk at gentage, når vendor-IP’er ændrer sig.
4. Central redirect. Anlæg en dedikeret _spf.ditdomæne.dk-record, der indeholder alle IP-adresser, og lad hoveddomænet blot pege derhen med redirect=_spf.ditdomæne.dk. Herved sparer du opslag for alle subdomæner - og har ét sted at vedligeholde.
5. Monitorér løbende. DMARC-rapporter viser, om ændringer skaber nye SPF-fejl. Sæt alerts op, når permerror stiger.

Når 10 bare ikke er nok

Arbejder du med mange tredjeparts-afsendere (f.eks. CRM, marketing automation og fakturasystemer), kan selv de bedste optimeringer være utilstrækkelige. Overvej da:

• Uddelegerede underdomæner: Lad hver vendor sende fra mail.vendor1.ditdomæne.dk, notify.vendor2.ditdomæne.dk osv. - med egen SPF-record.
• Sender-autentificering via CNAME: Nogle SaaS-løsninger tilbyder en enkelt CNAME, der rummer SPF, DKIM og hostnames i ét hug.
• Opdeling af trafik: Flyt nyhedsbreve til et helt separat domæne (ditbrand-email.com) for at holde corporate-domænets SPF slankt.

Går du systematisk til værks, kan du holde dig på den rigtige side af 10-barrieren, sikre en -all-afslutning og give DMARC det bedste grundlag for at beskytte dit domæne.

DKIM er limen, der binder din afsenderidentitet sammen med selve beskeden. Hvis signaturen fejler, kan SPF og alt andet være ligegyldigt - DMARC vil alligevel markere mailen som usikker. Her er de mest udbredte DKIM-snublesten og, vigtigere, hvordan du undgår dem:

1. For korte nøgler - eller nøgler, der er løbet tør for tid
   
   • 1024-bit RSA anses i dag for det absolutte minimum, men flere udbydere (bl.a. Google) foretrækker 2048-bit.
   • Gamle nøgler, der har ligget urørte i årevis, risikerer at blive kompromitteret eller havne på block-lister.

   Nøglelængde	Status	Anbefaling
   512-bit	Forbudt	Udskift straks
   1024-bit	Udgået	Migrér til 2048-bit ASAP
   2048-bit	Standard	God praksis
   4096-bit	Muligt	Kun hvis dit mailsystem understøtter det uden performance-hit

2. Ingen selector-rotation
   Selectoren er navnet på nøglen - f.eks. s2024._domainkey.ditdomæne.dk. Hvis du aldrig roterer, mister du muligheden for:
   • At tilbagekalde en kompromitteret nøgle uden at stoppe al mailtrafik.
   • At teste nye nøgler sideløbende (s2025) og udfase gamle (s2023) uden nedetid.

   Planlæg minimum årlig rotation; store brand-domæner gør det hvert halve år.

3. d=-mismatch mellem DKIM og From-domæne
   

   DMARC kræver alignment: Domænet i d=-tag’et skal være det samme (eller et subdomæne) som i synligt From-feltet.

   Misforhold opstår typisk når:

   • ESP’en signer med d=espprovider.com i stedet for d=ditdomæne.dk.
   • Du bruger onmicrosoft.com-signaturer i Microsoft 365 uden at aktivere DKIM custom domains.

   Løsningen er enkel: få din udbyder til at signe med dit domæne eller et dedikeret underdomæne, f.eks. mail.ditdomæne.dk.

4. Inkonsekvente signaturer - “sometimes pass, sometimes fail”
   

   Små afvigelser i header-rækkefølgen, automatisk gensignering af gateways, eller linjeskift der splittes anderledes undervejs, kan invalidere signaturen.

   • Deaktiver outbound content-filtering, der omskriver headers, efter DKIM-signering.
   • Sørg for én signeringskæde: hvis både din MTA og en downstream firewall signer, kan den første signatur blive brudt.
   • Hold øje med bh=-fejl i rapporterne - de indikerer body-mismatch.

Praktisk tjekliste før du klikker “send”:

• 2048-bit nøgle? ✔️
• Public key publiseret på korrekt selector? ✔️
• Selector ældre end 12 måneder? ➡️ Planlæg rotation.
• d= matcher From? ✔️
• Automatiske gateways eller signaturer der genskriver mailen? ➡️ Deaktiver eller flyt signering nedstrøms.

Når DKIM-fundamentet først er solidt, falder både SPF- og DMARC-pass-raten på plads - og dit domæne står markant stærkere mod spoofing.

Fejl i rapport-konfiguration er én af de hyppigste årsager til, at DMARC-projekter går i stå. Uden velfungerende rua og ruf mister du overblikket over spoofing-forsøg & alignment-problemer, og du opdager det først, når leveringen allerede bløder.

Syntaks: Sådan ser et korrekt rua/ruf-felt ud

v=DMARC1; p=none; rua=mailto:dmarc@ditdomæne.dk,mailto:[email protected];ruf=mailto:forensic@ditdomæne.dk; fo=1;

1. mailto: Feltet skal starte med protokol-præfikset mailto:. Glemmer du det, ignoreres hele adressen.
2. Kommaseparering uden mellemrum. Flere URI’er adskilles med komma (,) - ikke semikolon - og der må ikke være mellemrum før/efter kommaet.
3. Ingen linjeskift i midten af URI’en. DNS tillader maks. 255 tegn pr. streng; hvis din TXT-record brydes i flere strenge, skal bruddet placeres mellem to URI’er - aldrig midt i én.
4. Skalerbarhed. Hvis du har lange adresser eller mange rapport-modtagere, split DMARC-recorden i flere citerede substrenge:
   "v=DMARC1; p=none; rua=" "mailto:a@domæne.dk,mailto:b@domæne.dk"

Ekstern rapportering kræver godkendelse - Ellers bliver dine data aldrig sendt

Når en DMARC-record angiver rapportdestinations-domæner, der ikke er identiske med From-domænet, skal modtageren af rapporterne eksplicit give lov. Det gøres med en lille TXT-post:

• eksempel.dk = domænet der sender e-mails og har angivet analytix.io i sit rua.
• TXT-værdien behøver kun at indeholde v=DMARC1 (ingen politik).
• Mangler posten, vil Gmail, Microsoft m.fl. afvise at sende rapporterne - uden fejlmeddelelse til dig.

Tjeklisten: Undgå de klassiske rapporteringsfejl

• Valider, at rua/ruf starter med mailto: og er kommasepareret.
• Sørg for, at den samlede DMARC-TXT ikke overskrider 512 byte (brug multiple strenge).
• Bekræft, at alle eksterne destinationsdomæner har det nødvendige _report._dmarc-delegate-record.
• Brug værktøjer som DMARCian Inspector eller MXToolbox til syntakstjek.
• Monitorér, at RUA-rapporterne rent faktisk ankommer - intet dashboard = ingen data.

Når både syntaks og ekstern godkendelse er på plads, får du de daglige aggregerede rapporter, der gør det muligt at gå videre til næste trin i DMARC-modenhedskurven: fra monitorering til håndhævelse.

Uden et klart analyse- og handlingsspor bliver de daglige DMARC-aggregater blot endnu en støjende indbakke. Følg nedenstående metode for at omsætte rå XML-filer til konkret leveringsforbedring.

1. Saml og dekomprimér rapporterne
   Opret en dedikeret mailbox (dmarc@ditdomæne.tld) til rua=mailto:-adressen. Brug et skript eller et gratisværktøj som OpenDMARC Report Collector til automatisk at hente, udpakke og arkivere ZIP/GZIP-filerne.
2. Parse XML-filerne
   XML-strukturen indeholder bl.a. <record>, <row> (IP-adresse, antal) og <auth_results> (SPF/DKIM-resultater). Hvis du ikke vil kode selv, benyt SaaS-løsninger som DMARCian, Dmarcian, Postmark, Agari eller self-hostede parsedmarc. De konverterer XML til JSON/CSV og gemmer i Elasticsearch eller en SQL-database.
3. Visualisér i dashboards
   Et simpelt setup er parsedmarc → Elasticsearch → Kibana/Grafana. Du får:
   • Heat-maps over hvilke IP’er der sender på dine vegne
   • Tidsserier for DMARC-pass, SPF-align og DKIM-align
   • Top-failures pr. kilde, underdomæne eller “Header-From”
4. Mål de rigtige KPI’er
   

   KPI	Formel	Måltal
   DMARC-pass rate	aligned_pass / total	> 98 %
   SPF-align rate	spf_aligned / total	> 99 %
   DKIM-align rate	dkim_aligned / total	> 97 %
   Unknown kilder	unknown_src / total	< 1 %

   Hold øje med udsving fra én dag til den næste - et pludseligt dyk kan indikere spoofing eller en fejl i en ny integration.
5. Prioritér rettelser - 80/20-reglen
   Sortér records efter volume × fail. Fire IP-adresser fra et marketing-system, der tegner sig for 70 % af alle DMARC-failures, har langt højere ROI end fem “stray” IoT-enheder med hver 10 beskeder.
6. Skab et fast forbedringsloop
   
   • Ugentligt møde: Review graf/rapport, vælg “top 3” fejl.
   • Ejerskab: Tildel opgaven til SysOps, Marketing, SaaS-leverandør osv.
   • Validering: Når kilden er fikset, send testmails og bekræft DMARC=pass.
   • Dokumentér: Hav et delt ark over godkendte IP’er, SPF-includes og DKIM-selectors.

Når dine dashboards viser stabile pass-rater (≥ 98 %) uge efter uge, kan du skrue pct-parametret ned (f.eks. pct=10 → pct=100) eller skifte fra p=quarantine til p=reject med ro i maven. Det, der måles, bliver forbedret - men kun hvis nogen rent faktisk handler på tallene.

Dit domæne kan være 100 % DMARC-klar på root-niveau, men alt arbejde er spildt, hvis udsendelser fra eksterne platforme eller underdomæner stadig strander i spamfilteret. De mest udbredte syndere er SaaS-tjenester som nyhedsbrevssystemer, CRM’er og helpdesk-løsninger, der udsender mail “på vegne af” dit brand uden korrekt SPF- eller DKIM-alignment.

Typiske faldgruber

1. Marketing­systemet bruger eget domæne i Return-Path
   ⇒ SPF passerer, men alignment fejler, fordi Return-Path ≠ From:.
2. DKIM signeres af tredjepartens domæne
   ⇒ DKIM-hashen er fin, men d=sendgrid.net matcher ikke dit From:-domæne.
3. Underdomænemail overses
   ⇒ Du har DMARC på example.dk, men promo.example.dk udsender uden egen post - og arver derfor ikke nødvendigvis politikken, hvis sp-parameteren mangler.

Sådan sikrer du alignment - Uden at blokere for marketing

Konfigurationseksempel

; SPF for nyhedsbreve på news.example.dknews.example.dk. 3600 IN TXT "v=spf1 include:sendgrid.net -all"; DKIM ved hjælp af CNAME-delegerings1._domainkey.news.example.dk. 3600 IN CNAME s1.domainkey.u12345.wl123.sendgrid.net.; DMARC-politik for underdomænet_dmarc.news.example.dk. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

Husk sp-parameteren

Hvis du ikke vil definere individuelle DMARC-poster for hvert underdomæne, kan du nøjes med at udvide root-politikken med sp (subdomain policy). Den bestemmer, hvordan alle underdomæner håndteres:

; Root-DMARC med særskilt underdomænepolitik_dmarc.example.dk. 3600 IN TXT "v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected]"

• Hoveddomænet (example.dk) afviser (p=reject).
• Underdomæner (*.example.dk) lander i karantæne (sp=quarantine), indtil de er valideret.

Tjekliste før du skruer op til p=reject

• Lav en fuld kortlægning af alle e-mailstrømme - også “glemte” kampagneværktøjer og billetsystemer.
• Sørg for, at hver platform kan sende med både SPF- og DKIM-alignment.
• Opsæt en separat DMARC-post for hvert underdomæne eller brug sp.
• Test fra flere mailbox-udbydere (Gmail, Outlook, Apple) og overvåg RUA-rapporter for misalignment.

Når tredjepartsafsendere og underdomæner håndteres korrekt, kan du trygt eskalere DMARC-politikken uden at smide marketingbudgettet i Outlooks Junk-mappe.

At sætte p=reject fra den ene dag til den anden kan virke tillokkende - det er jo den stærkeste beskyttelse mod spoofing. Men uden et solidt datagrundlag og en kontrolleret indfasning risikerer du at afskære helt legitim mail: nyhedsbreve fra dit marketing-system, fakturaer fra ERP-platformen eller automatiske notifikationer fra tredjeparts-services, som hele organisationen er afhængig af.

Problemet er, at DMARC er binært: alt der ikke både passer SPF/DKIM og er alignet med From:-domænet, bliver kastet i skraldespanden, så snart politikken står til reject. Derfor skal håndhævelsen ske trinvis og datadrevet.

Sådan ruller du håndhævelsen ud uden at brænde broer

1. Start i observation (p=none)
   Indsaml minimum 2-4 ugers RUA-rapporter for at dokumentere:
   • Hvor stor en andel af trafikken der passer SPF og DKIM
   • Hvilke kilder/domæner der fejler alignment
   • Om enkelte mailbox-udbydere allerede afviser noget (pga. lokale politikker)
2. Sæt mål for acceptabel pass-rate
   Mange organisationer sigter efter >97-98 % DMARC-pass før de skruer op. Lav en to-do-liste for de resterende procent:
   • Udvid SPF-record eller undgå 10-lookup-loftet via flattening
   • Tilføj/roter DKIM-selectors på legacy-systemer
   • Implementér dedikerede underdomæner til tredjeparts-udsendelser
3. Gradvis skærpelse med pct=
   I stedet for ét stort hop kan du bruge DMARC-parametret pct til at prøve quarantine eller reject på en brøkdel af trafikken:

   Fase	DMARC-record	Hvad sker der?
   Fase 1	v=DMARC1; p=quarantine; pct=10;	10 % af fejl placeret i spamfolder
   Fase 2	v=DMARC1; p=quarantine; pct=100;	Alle fejl i karantæne
   Fase 3	v=DMARC1; p=reject; pct=25;	25 % hård afvisning
   Fase 4	v=DMARC1; p=reject; pct=100;	Fuld håndhævelse

   Inkrementér pct-værdien hver uge eller efterhånden som rapporterne viser, at fejlvolumen falder.
4. Brug testlister og seed-konti
   Opret en liste over interne og eksterne test-mailadresser hos:
   • Gmail, Microsoft 365, Yahoo, iCloud m.fl.
   • Lokale danske udbydere (fx Mail.dk, TDC, One.com)
   Send regelmæssige prøvemails og verificér: Inbox-placering, spam-folder, afvisnings-NDR’er og Authentication-Results-headers.
5. Overvågning i realtid
   Kombinér RUA (aggregerede) og RUF (forensic/failure) rapporter med dashboards (Elastic, Grafana, DMARC-analyseværktøjer) for at fange nye kilder, der bryder alignment, før de ryger i afvisning.
6. Iterér - politikken er ikke “sæt og glem”
   Nye SaaS-systemer, domæne-aliaser og kampagneværktøjer dukker op hele tiden. Indfør en on-boarding-proces hvor IT/marketing skal dokumentere SPF- & DKIM-alignment, før de får lov at sende fra virksomhedens domæne.

Tommelfingerregler for en sikker udrulning

• Skift maks én variabel ad gangen (fx pct eller p) - så ved du, hvad der forårsager ændringer i leveringen.
• Hold øje med “Unknown Sources” i rapporterne; hvis de stiger, er noget gået i stykker.
• Vent minimum én fuld forretningscyklus (månedsluk, løn, kvartalsrapporter) mellem hver fase, så alle systemtyper har haft lejlighed til at sende.
• Dokumentér konfigurationen - især hvis du ændrer sp=-politikken for underdomæner separat.

Med en kontrolleret overgang fra none til reject undgår du, at DMARC går fra at være en beskyttelse til at blive en forretningskritisk stopklods. Håndhævelse er målet, men turen derhen skal være datadrevet og trinvis.