Your DMARC Is Set to p=none. Here's How to Actually Turn It On.

If your domain has a DMARC record set to p=none, here's the uncomfortable part: it isn't stopping anyone from spoofing you. It's a monitoring setting. Someone can still send email that looks like it came from your domain, and it will still land in inboxes.

That's not a bug in your setup. p=none is where everyone is supposed to start. The problem is that most domains never leave.

Why so many domains are stuck at p=none

In early 2024, Google and Yahoo began requiring bulk senders to publish a DMARC record. The minimum that satisfies the requirement is p=none.

So a lot of domains did exactly that — published a record, passed the check, and stopped. The requirement was met. The protection was not.

If that's you, nothing has gone wrong. You just haven't finished.

What the three policies actually do

DMARC tells receiving mail servers what to do with messages that claim to be from your domain but fail authentication. There are three answers:

p=none — watch and report. Failing mail is delivered normally. You get reports showing what's happening. This is your reconnaissance phase, and it's genuinely useful — but it blocks nothing.

p=quarantine — send failures to spam. Mail that fails authentication goes to the junk folder instead of the inbox. This is where spoofing stops being a practical problem, because forged mail stops reaching people.

p=reject — refuse failures outright. Failing mail is rejected at the door and never delivered anywhere. This is full protection, and it's the destination.

The record itself lives at _dmarc.yourdomain.com as a TXT record:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Why people are afraid to move up — and what's actually at risk

The fear is real and worth naming: if you turn on enforcement while a legitimate sender is failing authentication, that mail stops arriving.

Think about everything that sends email "as" your domain:

• Your mail provider (Google Workspace, Microsoft 365)
• Your invoicing or CRM tool
• Your marketing platform
• Your website's contact form
• Your booking or scheduling software
• A payroll or HR system

Every one of those needs to pass SPF or DKIM in a way that aligns with your domain. Miss one, jump straight to p=reject, and that system's mail quietly disappears. That's the actual risk — not spoofing, but your own invoices vanishing.

Which is exactly why you don't jump.

The safe path to enforcement

Step 1 — Turn on reporting and actually read it.

If you're at p=none without a rua= address, you're getting no information at all. Add one:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Reports arrive as XML. They're unpleasant to read raw — a free DMARC report reader will make them legible. Run this for two to four weeks and you'll see every service sending as your domain, including ones you forgot about.

Step 2 — Fix your legitimate senders.

For each real sender in those reports, make sure it passes SPF or DKIM in alignment with your domain. Most providers document exactly which records to add. This is the actual work, and it's where the time goes.

Step 3 — Move to quarantine gradually.

You don't have to flip everything at once. The pct tag applies your policy to a percentage of failing mail:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.com

That applies quarantine to a quarter of failing messages. Watch for a week. No complaints and clean reports? Raise it — 50, then 100.

Step 4 — Move to reject.

Once you've run at p=quarantine; pct=100 for a few weeks with nothing legitimate failing, you're ready:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com

The whole progression typically takes a few months. That's normal, and rushing it is how people break their own email.

Two settings worth knowing

Subdomains. By default, subdomains inherit your policy. If you want them handled differently, sp= sets their policy separately:

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@yourdomain.com

Alignment strictness. aspf and adkim control how exactly the sending domain must match yours. They default to relaxed, which is right for almost everyone. Leave them alone unless you have a specific reason.

One thing that trips people up

SPF has a hard limit of 10 DNS lookups. Every include: in your SPF record counts, and each of those can trigger more. Add enough services and you silently blow the limit — at which point SPF fails for everyone, and enforcement turns that failure into lost mail.

If you've accumulated several include: entries over the years, check that before you enforce anything.

Where to start

If you don't know your current policy, that's the first thing to find out — you can't plan a rollout without knowing whether you're at none, already at enforcement, or have no DMARC record at all.