DMARC explained: the policy that makes SPF and DKIM actually protect you
SPF and DKIM authenticate email, but on their own they protect almost nothing: neither one is required to match the From address your customers actually see. DMARC closes that loop — and tells you, in reports, about everyone in the world sending as your domain. Since 2024 it is effectively mandatory for anyone sending volume. This is the guide we wish every Danish SMB had read before their first spoofing incident.
Alignment: the idea that makes DMARC work
A phishing mail can pass SPF perfectly — for the phisher's own envelope domain — while showing your domain in the From header, because SPF never looks at the From header. Likewise a valid DKIM signature only proves that some domain signed the message, not that it matches the visible sender.
DMARC adds the missing rule, called alignment: a message passes DMARC only if it passes SPF or DKIM for a domain that matches the From header domain. Pass either one, aligned, and the mail is authenticated in the way that actually matters to the human reading it. Fail both, and your published DMARC policy tells the receiver what to do about it.
The record itself is one TXT entry at _dmarc.yourdomain.dk. The essential tags: p= (the policy), rua= (where to send aggregate reports), sp= (subdomain policy), pct= (what share of failing mail the policy applies to), and adkim=/aspf= (strict or relaxed alignment matching).
The three policies, honestly described
p=none is monitoring mode. Failing mail is delivered exactly as before; the only effect is that receivers send you reports. It provides zero protection, and it is the correct starting point for every domain — because you cannot set a stricter policy safely until the reports tell you who is legitimately sending as you.
p=quarantine tells receivers to treat failing mail as suspicious — in practice, deliver it to spam. Real protection, forgiving of mistakes: a misconfigured legitimate sender ends up in spam folders rather than bounced into nothing.
p=reject refuses failing mail at the door. This is the end state — the one that makes your domain useless for phishing — and the one Google requires for BIMI logos. It is also the one that punishes rollout mistakes hardest, which is why you climb to it in stages rather than start there.
Reports: the feature people skip
The rua= tag is where DMARC stops being a checkbox and becomes an instrument. Every major receiver — Google, Microsoft, Yahoo, and thousands of others — will send the address you list a daily XML summary of every message stream claiming your domain: which IPs, how many messages, whether SPF and DKIM passed and aligned.
The first week of reports is usually eye-opening. Companies discover newsletter tools someone signed up for in 2019, an old on-premise scanner still emailing PDFs, a subsidiary sending through an unauthorized relay — and, regularly, active spoofing from IPs in networks they have never heard of. None of this is visible any other way.
Raw XML does not scale past a handful of reports, which is what report analytics platforms are for — parsing, aggregating and trending them (this is MonitorBase's phase 2). But even a mailbox you glance at weekly beats no rua= tag at all, which is what we still find on most Danish domains that have DMARC.
A safe staged rollout
Week zero: publish v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.dk. Nothing can break; data starts flowing. Weeks one to four: read the reports, and fix every legitimate source that fails alignment — usually by enabling DKIM at that provider or adding its include to SPF.
When reports show your legitimate mail aligned, move to p=quarantine, optionally starting with pct=25 and stepping up. Give it a few weeks at pct=100. Then move to p=reject. Consider sp= for subdomains: if subdomains never send mail, sp=reject immediately is sensible even while the main domain is still at none.
Two traps to avoid: never park at p=none forever (roughly half of all DMARC records ever published have — it collects reports and prevents nothing), and never jump straight to p=reject on an old domain with an unknown sender landscape.
Keeping it enforced
A DMARC record is one unauthorized DNS edit away from p=none, and a policy downgrade produces no error anywhere — mail keeps flowing, just unprotected. Whoever weakened it (an attacker preparing a phishing run, a vendor "fixing" a delivery complaint, a colleague following a support article) will not tell you. Monitoring the record for changes and policy downgrades is the boring, essential last step: MonitorBase re-checks daily and alerts the moment the policy weakens, the record changes, or alignment starts failing on a source that used to pass.