You set up DMARC. Your business is still fully exposed.

You set up DMARC. Your business is still fully exposed.
Email Security

You set up DMARC. Your business is still fully exposed.

Thousands of businesses rushed to add a DMARC record when Google and Yahoo demanded it. Most set it to p=none , and now they think they're protected. They're not.

Email Infrastructure  ·  8 min read

In early 2024, Google and Yahoo dropped a bombshell on the email world: if you're sending bulk email, you need SPF, DKIM, and DMARC or your messages go straight to spam. Overnight, "DMARC" went from an obscure DNS record to a household name in every marketing department and IT office.

What followed was a gold rush. Hosting providers, domain registrars, and web agencies all started offering to "set up your DMARC record." IT teams scrambled to get something, anything, in place before the deadline.

And in the rush, almost everyone made the same critical mistake.

72%
of DMARC records found in the wild are set to p=none
$2.9B
lost to business email compromise (BEC) in 2023 alone (FBI IC3 report)
~3.4B
spoofed/phishing emails sent every single day

What is DMARC, and what is it actually supposed to do?

DMARC stands for Domain-based Message Authentication, Reporting & Conformance. It's a DNS record that tells receiving mail servers what to do when an email claiming to be from your domain fails authentication checks (i.e., when it's likely a fake).

DMARC works alongside two other records: SPF (which lists servers allowed to send from your domain) and DKIM (which digitally signs your emails). Together, they create a chain of trust. DMARC is the enforcement layer: the piece that says "if this message fails, do something about it."

The key word there is enforcement. And that's exactly what most people skipped.

The p=none problem: a false sense of security

The DMARC p= tag is the policy tag. It controls what happens to email that fails authentication. There are three options:

The problem setting
p=none
Do nothing. Monitor only. Unauthenticated emails are delivered just fine. Zero enforcement.
Partial protection
p=quarantine
Suspicious email is moved to spam/junk. Better, but attackers can still reach inboxes.
Full protection
p=reject
Unauthenticated emails are blocked outright. This is what actually protects your domain.

When someone told you to "add a DMARC record," they were right. When they handed you a record with p=none and called it done, they left you exposed in exactly the same way you were before. You just can't see it happening now.

Here's the blunt truth: p=none does not stop a single phishing email. It does not protect your customers. It does not protect your brand. It tells receiving mail servers to deliver suspicious email anyway, and just send you a report. That's it.

The only legitimate use of p=none is as a temporary first step : a monitoring phase before you've audited all your legitimate sending sources. It should never be where you stay.

What a real (bad) DMARC record looks like

_dmarc.yourdomain.com  IN  TXT  "v=DMARC1; p=none ; rua=mailto:dmarc@yourdomain.com"

Millions of businesses have exactly this record. The rua tag means you'll get reports (that probably nobody reads). The p=none means none of it matters. This record technically satisfies Google and Yahoo's requirements, but it does nothing to prevent spoofing of your domain.

Here's what a properly configured, enforcing record looks like:

_dmarc.yourdomain.com  IN  TXT  "v=DMARC1; p=reject ; pct=100; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; aspf=s; adkim=s"

The difference? Everything. p=reject means servers receiving spoofed emails from your domain will silently discard them. Attackers can't impersonate your business. Your customers are protected.

The real risks of staying at p=none

✉
Phishing attacks on your customers
Anyone can send email that appears to come from your domain. Criminals use this to steal credentials, redirect payments, and impersonate your support team.
⚠
Business email compromise (BEC)
The FBI's top cybercrime category by financial loss. Attackers spoof your executives to trick employees or suppliers into transferring funds.
↓
Brand & reputation damage
When your domain is used to send spam or phishing emails, your sending reputation suffers and your legitimate emails start landing in spam too.
⚡
Supplier & partner fraud
Attackers spoof your domain to target your supply chain, sending fake invoices or payment redirect requests to companies that trust your name.
"We had a DMARC record. I checked. But our domain was still being used to phish our clients. Turns out p=none means nothing is enforced. We had the record and zero protection."

Why did everyone end up at p=none?

There's a legitimate technical reason p=none exists: before you enforce DMARC, you should audit what's sending email on behalf of your domain. Marketing platforms, CRMs, helpdesk software, transactional email services: all of these may send email as your domain, and you need to make sure they're properly authenticated (via SPF/DKIM) before you start rejecting failures.

The problem is that this audit phase became the permanent state. Tools that auto-generate DMARC records default to p=none because it's "safe." Agencies set it and forget it. Nobody schedules the follow-up to move to enforcement. And so businesses sit indefinitely in monitoring mode, accumulating DMARC reports that nobody reads, while their domain remains wide open.

How to actually fix this

1
Audit your sending sources
Identify every service sending email on behalf of your domain: your email provider, CRM, marketing platform, helpdesk, transactional email service. Each one needs to be authenticated with SPF and/or DKIM before you enforce.
2
Start monitoring with p=none (briefly)
If you haven't done this, set p=none with reporting tags and use a DMARC reporting tool (Postmark, Dmarcian, Valimail, etc.) to read the aggregate reports. You'll see what's passing and failing authentication.
3
Fix authentication gaps
For any legitimate sending source that's failing authentication, get it properly configured. Add SPF includes, set up DKIM signing, align your From domain. This is the real work, but it's a one-time job.
4
Move to p=quarantine, then p=reject
Once your legitimate email is passing cleanly, escalate your policy. Start with p=quarantine; pct=25 to test with a fraction of traffic, increase gradually, then move to p=reject; pct=100 for full enforcement.
5
Keep monitoring
Don't set it and forget it. DMARC reports tell you if something new is sending as your domain, both legitimate new tools you've added and attackers actively trying to spoof you. Review reports regularly.

The bottom line

DMARC is not a checkbox. Adding a record with p=none is like installing a home alarm system that monitors for break-ins but has no siren and doesn't call the police. You'll know after the fact that something happened. Nothing is actually prevented.

The good news? Getting to p=reject is achievable for nearly every business. It requires some upfront work: auditing your senders, fixing authentication. But once it's done, your domain is genuinely protected. Attackers can't impersonate you. Your customers can trust that email from your domain really came from you.

That's what DMARC was designed to do. That's what it does when it's set up properly.

If your DMARC record says p=none right now, you haven't finished the job.

Not sure where your DMARC stands?

We'll audit your email authentication setup and build a clear path to full enforcement, without breaking your deliverability.

Book a free consultation