Moving DMARC from p=none to p=reject

DMARC is one of those security controls that sounds simple until you actually try to enforce it.

At a high level, DMARC helps prevent people from spoofing your email domain. It tells receiving mail servers what to do when a message claims to come from your domain but does not properly authenticate using SPF or DKIM.

The problem is that a lot of organizations stop at this:

v=DMARC1; p=none; rua=mailto:[email protected]

That is better than nothing, but p=none is monitoring mode. It does not tell anyone to block or quarantine spoofed messages. It only asks receiving mail servers to send you reports.

That means if someone is pretending to be your company in an email campaign, your DMARC record may be observing the problem, but it is not doing much to stop it.

The goal should usually be to move toward this:

v=DMARC1; p=reject; rua=mailto:[email protected]

But you should not jump straight from p=none to p=reject without understanding what is sending email on behalf of your domain.

This is a process.

What DMARC Actually Does

DMARC works with SPF and DKIM.

SPF helps define which mail servers are allowed to send email for your domain.

DKIM uses a cryptographic signature to prove that an email was authorized by your domain and was not modified in transit.

DMARC checks whether SPF or DKIM passes and whether the passing result aligns with the domain shown in the visible From: address.

That alignment piece matters. A message can technically pass SPF or DKIM but still fail DMARC if the authenticated domain does not line up with the domain the recipient sees.

DMARC then tells the receiving mail server what to do when a message fails.

The three common policies are:

The key word is “ask.” Receiving mail systems make their own final decisions, but major providers generally honor DMARC policy when it is configured correctly.

Why You Should Not Start with p=reject

It can be tempting to go straight to enforcement.

After all, if the goal is to stop spoofing, why not just publish p=reject and be done?

Because you may break legitimate email.

Most businesses have more systems sending email than they realize. It is not just Microsoft 365 or Google Workspace. It may also include:

• CRM platforms
• Marketing tools
• Billing systems
• Ticketing systems
• Website contact forms
• HR platforms
• Payroll systems
• Cloud applications
• Managed service providers
• Printers or scanners
• Legacy applications
• Third-party vendors

Some of these systems may be sending as your domain without properly configured SPF or DKIM.

If you publish p=reject before identifying those systems, legitimate emails may start getting rejected.

That is why the safe path is:

p=none → p=quarantine → p=reject

Step 1: Set Up DMARC Reporting First

Before you enforce anything, you need visibility.

DMARC aggregate reports show who is sending email using your domain and whether those messages are passing SPF, DKIM, and DMARC alignment checks.

A basic DMARC record might look like this:

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

The rua tag is where aggregate reports are sent.

Technically, you can send these reports to a regular mailbox, but I do not recommend it. DMARC reports are XML files, and they are not fun to read manually. Use a DMARC reporting service or a tool that parses the reports into something usable.

At this stage, your goal is not enforcement.

Your goal is discovery.

You want to answer questions like:

• Who is sending email as my domain?
• Are my main email platforms passing SPF and DKIM?
• Are third-party tools properly authenticated?
• Are there unknown sources sending mail?
• Are messages failing because of SPF, DKIM, or alignment issues?
• Are subdomains being used?
• Are there obvious spoofing attempts?

Do not skip this step. Without reporting, you are guessing.

Step 2: Start with p=none

If you already have DMARC at p=none, that is fine. You are in monitoring mode.

A starter record may look something like this:

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=s; aspf=s"

The adkim and aspf tags control DKIM and SPF alignment strictness.

For many organizations, relaxed alignment is more forgiving and may be easier at first:

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r"

Strict alignment is stronger, but it can also break more things if your sending sources are not configured cleanly.

The right answer depends on your environment.

For most small and mid-sized businesses, the first priority is to get reporting working and understand the current state.

Step 3: Review Reports for a Few Weeks

Once reporting is enabled, let it run.

You want enough time to see normal business activity. A few days usually is not enough. A couple of weeks is better. A month is better yet, especially if you have newsletters, invoices, monthly statements, or recurring system emails.

Look for your known senders first.

Examples might include:

• Microsoft 365
• Google Workspace
• Mailchimp
• HubSpot
• Salesforce
• Zendesk
• QuickBooks
• Shopify
• WordPress
• Website form plugins
• Security awareness platforms
• Ticketing systems

For each one, confirm whether it is passing DMARC.

If it is failing, figure out why.

Common issues include:

• SPF does not include the sending service
• DKIM is not enabled for the sending service
• DKIM is enabled but using the wrong domain
• A vendor is sending through its own domain instead of yours
• A website form is spoofing your domain instead of sending from a valid address
• SPF has too many DNS lookups
• Multiple SPF records exist
• A subdomain is being used without a clear policy

At this point, you are cleaning up your email ecosystem.

This is where most of the work happens.

Step 4: Fix SPF and DKIM Problems

Before moving to enforcement, make sure legitimate senders pass DMARC.

That usually means fixing SPF, DKIM, or both.

SPF Fixes

Your SPF record tells the world which systems are allowed to send email for your domain.

A simple SPF record might look like this:

example.com TXT "v=spf1 include:spf.protection.outlook.com -all"

But many organizations add includes over time:

example.com TXT "v=spf1 include:spf.protection.outlook.com include:sendgrid.net include:mailgun.org -all"

That can be fine, but SPF has a DNS lookup limit. If your record gets too large or includes too many third parties, it may fail.

Common SPF cleanup tasks include:

• Removing old vendors
• Consolidating services
• Avoiding duplicate includes
• Making sure there is only one SPF record
• Staying under the DNS lookup limit
• Using -all once you are confident

Be careful with overly broad SPF records. Adding huge IP ranges or unnecessary vendors creates risk.

DKIM Fixes

DKIM is often the better long-term control because it survives forwarding better than SPF.

For each legitimate third-party email platform, check whether it supports DKIM signing using your domain. Most reputable services do.

You may need to add one or more DNS records provided by the vendor.

These often look like CNAME records:

selector1._domainkey.example.com CNAME selector1-example-com._domainkey.vendor.example
selector2._domainkey.example.com CNAME selector2-example-com._domainkey.vendor.example

Or TXT records:

selector._domainkey.example.com TXT "v=DKIM1; k=rsa; p=..."

Once DKIM is enabled, check your DMARC reports again to confirm the messages are passing and aligned.

Step 5: Move to p=quarantine

Once your reports look clean, move from monitoring to partial enforcement.

Your DMARC record might become:

_dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

This tells receiving mail servers that messages failing DMARC should be treated as suspicious.

Some systems may send them to spam. Some may quarantine them. Some may apply their own filtering logic.

This is a good middle step because it lets you start enforcing without immediately rejecting everything that fails.

You can also use the pct tag to apply the policy gradually:

_dmarc.example.com TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]"

That means the quarantine policy should apply to 25% of failing messages.

Then you can increase it over time:

• pct=50
• pct=75
• pct=100

Not every organization needs to use pct, but it can be helpful if you have a large or complicated email environment.

Step 6: Watch Reports for a Couple Months

After moving to p=quarantine, keep watching your DMARC reports.

This is where patience matters.

Let the policy run for a couple months if you can. That gives you time to see less frequent email sources, seasonal campaigns, billing cycles, customer communications, automated systems, and vendor workflows.

During this phase, pay attention to:

• Legitimate senders that are now being quarantined
• Business units using unauthorized tools
• Vendors sending email without proper authentication
• Website or application email failures
• Forwarding-related issues
• Subdomain abuse
• Spoofing attempts

You may discover systems that nobody remembered existed.

That is normal.

The goal is not just to “turn on DMARC.” The goal is to understand and control who can send email using your domain.

Step 7: Move to p=reject

Once you are comfortable that legitimate email is passing DMARC, move to reject.

Your final record may look like this:

_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

This tells receiving mail servers to reject messages that fail DMARC.

This is the strongest common DMARC policy and where most organizations should eventually end up.

At this point, you have moved from visibility to enforcement.

You are no longer just watching spoofed messages. You are asking receiving mail systems to reject them.

Do Not Forget Subdomains

Subdomains matter.

By default, your main DMARC policy may apply to subdomains, but you can also explicitly define a subdomain policy with the sp tag.

For example:

_dmarc.example.com TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]"

This tells receivers to reject DMARC failures for both the root domain and subdomains.

That matters because attackers may try to use subdomains such as:

billing.example.com
mail.example.com
secure.example.com
support.example.com

If your organization sends mail from subdomains, make sure those are included in your review before enforcing a strict subdomain policy.

A Practical DMARC Rollout Plan

Here is a simple rollout plan.

The exact timeline depends on the size and complexity of your environment.

A small business with Microsoft 365 and one marketing platform may be able to move quickly.

A larger organization with dozens of vendors, multiple brands, and legacy systems may need more time.

Common Mistakes

Publishing DMARC Without Reporting

A DMARC record without reporting is not very useful during rollout.

You need the reports to understand what is happening.

Jumping Straight to p=reject

This can work in very simple environments, but it is risky if you do not know all legitimate senders.

Forgetting Third-Party Vendors

Marketing, invoicing, ticketing, HR, and CRM platforms are common sources of DMARC failures.

Ignoring DKIM

SPF is helpful, but DKIM is usually more reliable, especially when email is forwarded.

Letting SPF Get Messy

SPF records tend to accumulate old vendors. Review and clean them up.

Forgetting About Subdomains

Attackers may spoof subdomains if your policy does not cover them.

Treating DMARC as a One-Time Project

DMARC needs ongoing review. Every time a new email vendor is added, someone should ask how SPF, DKIM, and DMARC will be handled.

DMARC Is Not Just a DNS Record

DMARC enforcement is not just a technical checkbox.

It is really about email governance.

Who is allowed to send email for your business?

Who approves new email platforms?

Who owns DNS changes?

Who reviews authentication failures?

Who gets notified when a vendor breaks email authentication?

If nobody owns those questions, your DMARC posture will slowly drift over time.

Final Thought

Moving from p=none to p=reject is not hard, but it does require a process.

Start with reporting. Watch the data. Identify legitimate senders. Fix SPF and DKIM. Move to quarantine. Keep watching. Then move to reject when you are confident.

The mistake is thinking DMARC enforcement is just changing one DNS record.

It is not.

That DNS record is the final step. The real work is understanding who is sending email as your domain and making sure only authorized systems are allowed to do it.