Missing DMARC: What Actually Happens to Your Email

Email was designed without authentication. The From: address a recipient sees is, by default, whatever the sender typed — which means anyone can send mail claiming to be your domain, and unless you have published instructions to the contrary, receiving servers have no basis to refuse it. DMARC is those instructions. Missing it does not mean your email is insecure in the abstract; it means your domain is impersonable in a specific, testable way.

That last column is why DMARC is the record that matters most: without it, a message that fails SPF and has no DKIM signature is suspicious, and each receiver decides for itself what suspicious means. With it, you decide.

• p — the policy: none (monitor only), quarantine (spam folder), reject (refuse outright).
• rua — where aggregate reports go. This is the whole value of p=none: reports tell you who is sending as you before you enforce anything.
• pct — what percentage of failing mail the policy applies to, for gradual enforcement.
• adkim / aspf — alignment strictness, relaxed (r) or strict (s). Relaxed permits subdomains, which is almost always what you want.

The reason to stage this is that almost every organisation sends legitimate mail from more services than it remembers — a helpdesk, a billing provider, a marketing platform, an old server nobody decommissioned. Going straight to p=reject blocks whichever of those you forgot, and the symptom is invoices silently not arriving.

This is the failure we walked into on our own domain, and it is worth more space than most guides give it — which is usually none. If a receiver finds more than one DMARC record at _dmarc.yourdomain.com, RFC 7489 tells it to ignore DMARC for that domain entirely. Not to pick the stricter one. Not to pick the first. To behave as though you had published nothing at all.

The way people arrive here is completely reasonable: your registrar or mail host quietly published a default DMARC record when you set up email, you later add your own — correctly — and now there are two. Adding a security control made the domain less protected than it was five minutes earlier, and nothing warns you. The registrar's control panel happily shows both.

If the count is two, decide which to keep by asking where the reports go. A default record from a registrar usually sends rua to the registrar's own address — reports you will never read, from a policy you therefore cannot safely advance. Keep the record whose rua is a mailbox you own, delete the other, and re-run the count.

Check the root domain even if you only send from a subdomain. A root with no SPF and no DMARC is impersonable regardless of how well mail. is configured, and attackers spoof the address people recognise.

These records live in DNS, which means they change outside your deploy pipeline — a registrar migration, a new sending provider, an expired record nobody noticed. A free scan reads all three from outside and reports what a receiving server would conclude; monitoring re-checks them daily, so a record that disappears is a notification rather than a discovery.