Your DMARC record is set — and doing nothing

You did the responsible thing. When the deliverability guides all said “set up DMARC,” someone on your side added the record, the checker went green, and the box got ticked. As far as anyone has thought about it since, your domain is protected against spoofing.

It very likely isn’t. The most common DMARC record in the world is one that watches quietly and enforces nothing — it publishes a policy of p=none, which tells receiving mail servers, in effect, notice this, but do nothing about it. Someone forging mail from your domain meets no resistance, and a genuine message that fails the check is delivered anyway. The record exists, the tools report it as present, and it is holding no door shut.

That’s the quiet failure: not a missing record, but a record that looks like protection and provides none.

Why it stays invisible

DMARC sits on top of two older checks — SPF, which lists the servers allowed to send as your domain, and DKIM, which signs your mail so it can’t be tampered with in flight. DMARC’s job is to say what a receiver should do when a message fails both, and to make sure the address the reader sees actually matches the domain that passed the checks. That matching is called alignment, and it’s the part almost nobody realises is missing.

The trouble is that DMARC has three enforcement settings, and the safe-looking one is the weakest. p=none is monitor-only: it asks receivers to send you reports but to deliver everything regardless. p=quarantine sends failing mail to spam. p=reject turns it away at the door. Almost every guide, sensibly, tells you to start at p=none so you can watch your legitimate mail for a while before you clamp down — and that’s correct. The failure is that the record never moves past it. The monitoring phase that was meant to last a fortnight quietly becomes permanent, because nothing breaks to remind you, and reading the reports was never anyone’s job.

Meanwhile the ground has shifted underneath. The large mailbox providers have spent the last couple of years tightening what they accept from bulk senders, and the polite phase is over: Google, Yahoo and Microsoft now all turn unauthenticated bulk mail away outright, with a permanent “550” bounce rather than a quiet detour to the spam folder. The standard itself has firmed up too — in May 2026 the internet’s standards body published a revised DMARC specification (RFC 9989), promoting it from an informational document to a full Proposed Standard.

So a p=none record leaves you exposed at both ends: anyone can still send mail that looks like it came from you, and you have no visibility into how much of your own mail is failing alignment right up until the day a provider stops being polite about it.

Find it yourself

You can read your own policy in about ten minutes. Nothing to install.

1. Look up the record. On a Mac or Linux machine, open Terminal and run dig +short txt _dmarc.yourdomain.com. On Windows, run nslookup -type=txt _dmarc.yourdomain.com. If you’d rather not touch a command line, an online checker such as MxToolbox does the same job — search “DMARC record lookup”.
2. Read the policy word. Find the part that says p=. If it reads p=none, you are monitoring only — enforcing nothing. p=quarantine and p=reject are the settings that actually act. If there’s no record at all, you have neither monitoring nor enforcement.
3. Check you’re collecting reports. Look for a rua= tag with an email address (for example rua=mailto:[email protected]). No rua, and even your monitoring is going nowhere — the daily reports that tell you what’s failing have nowhere to land.
4. Confirm the foundations. DMARC only works if SPF and DKIM are in place and aligned. Check your SPF record too (dig +short txt yourdomain.com, look for v=spf1) — if that’s shaky, DMARC enforcement will bounce your own mail. Our companion issue on SPF walks through this.

The usual reaction to step 2 is a slightly deflated “oh” — the record everyone assumed was doing something turns out to say none.

The fix

Getting from a record that watches to a record that acts is a deliberate, staged move — never a flip of the switch.

Start collecting, if you aren’t. Add a rua= address so the daily reports start arriving. They’re XML and unlovely to read raw, so point them at a free DMARC report reader — this is the one place a tool genuinely earns its keep, because a fortnight of reports tells you exactly which of your services are sending mail and whether they pass.

Fix alignment before you tighten. The reports will show you legitimate senders that currently fail — your invoicing tool, your CRM, your mailing platform. Get each one authenticated (usually a DKIM key they give you to add to DNS) so it passes before you start rejecting. Tighten first and you’ll bin your own newsletters.

Move up one step at a time. Once your genuine mail is passing cleanly, change p=none to p=quarantine, watch for a week or two, then to p=reject. Each step is reversible; there’s no need to rush, only to actually make the move.

Then leave it enforcing. Once you’re at p=reject with everything aligned, a spoofer meets a closed door instead of a shrug — and you’ll see it happen in the reports rather than hear about it from a customer.

None of this needs a deliverability consultant. It needs someone to decide, once, that a record that says none is worth turning into a record that says no.

Reading DMARC reports by hand, week after week, is exactly the sort of thing that falls off the edge of a busy week. DomainOps turns them into plain English and warns you before a change would drop your own mail — but the ten-minute check above costs nothing, so do that first, today, whether or not you ever automate it.