Does Your DMARC Record Actually Do Anything?

Your domain has a DMARC record. That sounds like a security statement. Here is the uncomfortable follow-up: what does it actually do?

The answer depends entirely on what your DMARC policy is set to. And in practice, most organizations have set theirs to do nothing at all.

What DMARC Policy Levels Mean

DMARC has three policy settings. They go in the p= field of your DNS record:

• p=none -- no action taken. Mail that fails DMARC checks is delivered normally. You receive reports about what is happening with your domain, but nothing changes.
• p=quarantine -- suspicious mail gets soft-landed, usually routed to spam. Your mail system decides what happens.
• p=reject -- mail that fails DMARC is refused at the MTA level. The sending server gets a permanent failure. Nothing gets through.

p=none is monitoring mode. p=quarantine and p=reject are enforcement modes. The difference is not cosmetic.

Why p=none Is Not a Security Control

A DMARC record set to p=none does not stop attackers from spoofing your domain. It tells you who is trying. That visibility has real value. But it does not block anything.

When an attacker sends phishing emails from your domain, p=none lets those emails through. Your recipients see your domain in the From field. They have no way to know the mail failed DMARC. The protection only kicks in when you set p=quarantine or p=reject.

This matters because many email security scoring tools give partial credit for any published DMARC record. A domain with p=none scores points. A domain with p=reject scores more. But the gap between "published" and "protected" is not a small one.

The Published-Versus-Effective Gap in Email Security Scoring

A security grade is only useful if you can add the components back up.

Some graders weight DMARC at 25 points out of 100. They give full marks for p=none because the record exists. They subtract points for missing SPF, missing DKIM, or no MTA-STS. But the underlying assumption is that "DMARC present" means something close to "DMARC working."

It does not.

p=none tells you what is happening. p=reject stops what is happening. One is a mirror. The other is a lock.

If you are running an internal security assessment and you count p=none as full compliance, you are not measuring protection. You are measuring documentation.

How to Tell If Your DMARC Is Working

Three questions to ask right now:

1. What is your p= value? Look at your DNS. If it says p=none, your DMARC is not enforcing anything.
2. What do your aggregate reports show? DMARC reports arrive daily from participating receivers. They tell you which sources are sending mail from your domain, which ones pass alignment, and which ones fail. If you are not reading them, you do not know your actual exposure.
3. Are your SPF and DKIM aligned? DMARC requires at least one of SPF or DKIM to align with the From domain. A record that passes authentication but fails alignment provides no protection.

If you do not have a way to read DMARC reports automatically, you are probably running blind. Most teams that set up DMARC once and never look at the reports have no idea how many failed messages are being sent from their domain every day. Tools like DMARCFlow parse these reports automatically, flag alignment failures, and track whether your policy is still set to monitoring mode or has moved toward enforcement.

Moving from Monitoring Mode to Enforcement

If you are on p=none and ready to move forward, quarantine is the practical first step. It gives you enforcement without the hard break. Legitimately misconfigured sources get soft-blocked rather than refused outright, which gives you time to fix them before flipping to p=reject.

Before you change anything, fix your alignment issues. Every legitimate sending source must pass SPF or DKIM alignment. If you migrate mail services, change ESPs, or add new sending infrastructure, recheck alignment after each change.

Common mistakes that cause alignment failures after moving to enforcement:

• Adding new sending infrastructure without updating DMARC


• Using a third-party email service that signs with a different domain


• Letting SPF records exceed the 10-lookup limit, causing soft failures

Move to p=reject only after you have run p=quarantine long enough to catch and fix your legitimate sources.

What to Do When Reports Show Alignment Failures

Alignment failures in DMARC reports usually mean one of two things: a legitimate source is misconfigured, or someone is spoofing your domain.

If the failing source is your own infrastructure, fix it. Update your SPF record, check your DKIM signing domain, or reconfigure your sending service.

If the failing source is not yours and you are on p=none, you are watching an attacker in real time. The reports tell you exactly which domains are being spoofed and when. Even without enforcement, this data is useful for incident response and for proving to your own team that spoofing is happening.

Keeping Your DMARC Effective Over Time

DMARC is not a set-and-forget control. The email sending landscape changes. You add new services, migrate platforms, and your SPF record grows. Each change can break alignment.

Make DMARC review part of your routine:

• Check aggregate reports monthly at minimum


• Review alignment rates when you add new sending infrastructure


• Track your policy progression: none to quarantine to reject


• Watch for sudden spikes in failed messages, which can indicate a new spoofing campaign

If you manage DMARC for multiple domains, automated monitoring that parses aggregate reports and alerts on changes will pay for itself quickly. Most teams discover they have more sending sources than they knew about, and some of those sources have been failing alignment for months.

FAQ

Does having a DMARC record mean my domain is protected?
Not necessarily. A DMARC record set to p=none gives visibility but not protection. Only p=quarantine and p=reject actually block or filter suspicious mail.

What is the difference between p=none and p=reject?
p=none monitors and reports. p=reject refuses mail that fails DMARC checks at the MTA level. p=quarantine is the middle ground, routing suspicious mail to spam instead of refusing it.

How do I check if my DMARC policy is actually working?
Look at your p= value in DNS. Then read your aggregate DMARC reports to see what percentage of mail is passing alignment versus failing. If you are not receiving reports, your DMARC is not working as intended.

Should I move from p=none to p=quarantine or p=reject?
quarantine is the safer first step. Move to reject only after you have resolved alignment issues for all legitimate sending sources.

How often should I check my DMARC reports?
At least monthly, and after any change to your email infrastructure. Frequent checks catch problems before they become incidents.