DMARC Reject Policy Explained

Your domain uses p=reject — the strongest DMARC policy available. Emails that fail authentication are blocked entirely, preventing attackers from spoofing your domain. Here's what that means and how to keep it working.

What p=reject means

The p=reject policy in your DMARC record tells receiving mail servers to reject any email that fails DMARC authentication. This is the strongest level of protection available. When a spoofed email pretending to be from your domain arrives at a recipient's server, that server will refuse to deliver it.

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

The p=reject tag is the critical part. It instructs receivers: "If an email claims to be from my domain but fails both SPF alignment and DKIM alignment, do not deliver it at all."

🎉

Congratulations! Your domain is using the strongest DMARC policy available. The p=reject policy provides maximum protection against email spoofing and phishing attacks. Most domains never reach this level of email security.

What happens to failing emails

When a receiving server processes an email from your domain and it fails DMARC authentication under a p=reject policy, the email is completely blocked:

The email arrives at the receiving server

A mail server receives an email with your domain in the "From:" header. It queries DNS for your DMARC record at _dmarc.yourdomain.com.

SPF and DKIM are checked

The server runs SPF validation (checking the sending IP against your SPF record) and DKIM validation (verifying the cryptographic signature). It then checks whether either result aligns with your "From:" domain.

DMARC fails — neither aligns

If neither SPF nor DKIM passes with proper alignment to your domain, DMARC authentication fails.

The email is rejected

Because your policy is p=reject, the receiving server refuses delivery. The email is bounced back or silently dropped. The intended recipient never sees it.

💡

Legitimate emails are not affected. Emails sent from properly configured servers that pass SPF or DKIM alignment are delivered normally. The reject policy only blocks emails that fail authentication — which means they are either spoofed or sent from a misconfigured service.

How DMARC works with SPF and DKIM

DMARC doesn't work alone. It builds on two underlying authentication mechanisms: SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). For DMARC to pass, at least one of these must pass and align with the visible "From:" domain.

📋

SPF alignment

SPF checks whether the sending server's IP is authorized in your domain's SPF record. For DMARC alignment, the Return-Path domain must match the "From:" domain (exact match for strict, organizational domain for relaxed).

🖊️

DKIM alignment

DKIM verifies a cryptographic signature in the email header. For DMARC alignment, the DKIM signing domain (d= tag) must match the "From:" domain. DKIM survives email forwarding, making it especially important.

SPF result	DKIM result	DMARC result
Pass + aligned	Pass + aligned	Pass — email delivered
Pass + aligned	Fail or not aligned	Pass — email delivered
Fail or not aligned	Pass + aligned	Pass — email delivered
Fail or not aligned	Fail or not aligned	Fail — email rejected (p=reject)

💡

Only one needs to align. DMARC passes if either SPF or DKIM passes and aligns. This is by design — SPF often breaks when emails are forwarded, but DKIM signatures usually survive forwarding. Having both configured provides redundancy.

Why reject is the best policy

There are three DMARC policies, and p=reject is the gold standard:

p=none (Monitor only)

No protection. Spoofed emails are delivered normally. Only useful during the initial monitoring phase to collect data.

p=quarantine (Spam folder)

Moderate protection. Failing emails go to spam. But attackers' emails still reach inboxes — just in the junk folder where some users may still open them.

p=reject (Block entirely)

Maximum protection. Failing emails are never delivered. Attackers cannot spoof your domain because their emails are rejected at the server level.

With p=reject, your domain is protected against phishing attacks that impersonate your brand. Recipients will never receive fraudulent emails claiming to be from your domain, protecting both your customers and your reputation.

Maintaining your reject policy

Having p=reject is a significant achievement, but it requires ongoing maintenance to ensure legitimate emails continue to be delivered. Here's what to watch for:

✅

Monitor DMARC reports regularly

Review your aggregate reports (rua) at least monthly. Look for legitimate sending sources that are failing authentication. This can happen when you add a new email service, change email providers, or a third-party service updates their infrastructure.

✅

Update SPF when adding new email services

Whenever you start using a new service that sends email on your behalf (marketing platforms, CRM tools, helpdesk software), add their sending IPs or include mechanism to your SPF record before they start sending.

✅

Configure DKIM for all sending services

Each service that sends email as your domain should sign with DKIM using your domain. This is especially important because DKIM survives email forwarding, while SPF does not.

✅

Set a subdomain policy

If you have subdomains that send email, make sure they have proper SPF and DKIM configured. Consider setting sp=reject to protect subdomains too, or sp=none if subdomains need separate rollout.

✅

Keep your rua address active

Make sure your DMARC reporting address is monitored. If the mailbox fills up or is deactivated, you lose visibility into authentication failures and potential abuse of your domain.

⚠️

Don't downgrade your policy. Once you've reached p=reject, resist the temptation to downgrade to quarantine or none when a new service isn't sending properly. Instead, fix the service's SPF/DKIM configuration. Downgrading re-exposes your domain to spoofing.

Best practices

✅

Use a DMARC reporting service

Raw DMARC aggregate reports are compressed XML files that are difficult to read manually. Use a service like Postmark DMARC, dmarcian, Valimail, or EasyDMARC to parse reports into clear dashboards.

✅

Protect non-sending domains

If you own domains that don't send email, publish v=DMARC1; p=reject along with v=spf1 -all on those domains too. This prevents attackers from spoofing domains you're not actively monitoring.

✅

Audit third-party senders periodically

Services change their sending infrastructure over time. Periodically verify that all your authorized senders still pass SPF and DKIM alignment. DMARC reports will show you if anything has broken.

✅

Consider strict alignment for high-security domains

The default relaxed alignment (aspf=r; adkim=r) allows subdomain matches. For high-security domains, consider strict alignment (aspf=s; adkim=s) to require exact domain matches — but test thoroughly first.

Keep your domain protected

Domain Guarddog continuously monitors your DMARC, SPF, and DKIM configuration and alerts you if anything changes or breaks.

Get Started Free