Implementing DMARC p=reject: A Technical Step-by-Step Guide to Maximize Deliverability & Prevent Spoofing in 2026

Understanding DMARC and the 'reject' Policy

DMARC (Domain-based Message Authentication, Reporting, and Conformance), defined in RFC 7489, is an email authentication protocol. It builds upon SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) to provide domain owners with the ability to instruct receiving mail servers on how to handle unauthenticated mail. DMARC's primary functions are to prevent email spoofing and phishing attacks, and to improve legitimate email deliverability.

The DMARC p=reject policy represents the highest level of enforcement. When a receiving mail server receives an email that fails DMARC authentication and alignment checks from a domain with p=reject, it will completely block the message. This policy ensures that only authenticated and aligned emails reach recipients, providing maximum protection against brand impersonation and enhancing sender reputation. Implementing p=reject requires careful planning and execution to avoid disrupting legitimate email flows.

Prerequisites and Initial DMARC Deployment

Before moving to p=reject, foundational email authentication protocols must be correctly configured and aligned. This involves setting up SPF and DKIM for all legitimate sending sources.

SPF (Sender Policy Framework) - RFC 7208:
SPF allows domain owners to specify which IP addresses are authorized to send email on behalf of their domain. A valid SPF record is a TXT record in DNS.

• Syntax: v=spf1 ip4:192.0.2.1 include:_spf.google.com ~all
• v=spf1: Specifies the SPF version.
• ip4 / ip6: Authorizes specific IP addresses.
• a / mx: Authorizes the domain's A or MX records.
• include: Authorizes another domain's SPF record.
• ~all (Softfail): Messages from unauthorized sources may be accepted but marked.
• -all (Hardfail): Messages from unauthorized sources are rejected. Use -all only when all legitimate sending sources are explicitly listed.

DKIM (DomainKeys Identified Mail) - RFC 6376:
DKIM adds a digital signature to outgoing emails, allowing the receiver to verify that the message was not altered in transit and originated from an authorized sender. DKIM records are also TXT records in DNS.

• Syntax: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDY...
• v=DKIM1: Specifies the DKIM version.
• k=rsa: Specifies the key type.
• p=: Contains the public key.

DMARC Alignment:
For DMARC to pass, either SPF or DKIM must pass, AND their respective domains must align with the From: header domain.

• SPF Alignment: The Return-Path domain (envelope sender) must match the From: header domain (strict) or be a subdomain (relaxed).
• DKIM Alignment: The d= tag in the DKIM signature must match the From: header domain (strict) or be a subdomain (relaxed).

Initial DMARC Deployment (p=none):
Begin DMARC implementation with a p=none policy. This monitoring-only mode collects reports without affecting email delivery. These reports are essential for identifying legitimate and illegitimate email sources.

• Example DMARC p=none record:
  _dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1"
• v=DMARC1: Specifies the DMARC version.
• p=none: Sets the policy to monitoring.
• rua: Specifies the email address for aggregate reports.
• ruf: Specifies the email address for forensic reports.
• fo=1: Requests forensic reports for all failed checks.

After deploying SPF, DKIM, and the initial DMARC record, confirm your SPF setup is correct. You can use our SPF checker to verify your records. Allow several days for reports to accumulate.

Analysis, Iteration, and Transition to p=quarantine/p=reject

The transition to p=reject is an iterative process. It requires careful analysis of DMARC reports and adjustments to your email infrastructure.

1. Analyze DMARC Aggregate Reports (RUA):
These XML reports provide a summary of email traffic, showing which emails passed or failed SPF/DKIM authentication and DMARC alignment.

• Identify all legitimate sending sources. Ensure they are correctly authenticating and aligning.
• Identify any legitimate sources failing authentication. These require immediate attention.
• Note any unexpected sending sources. Investigate these for potential spoofing.

2. Remediate Authentication Gaps:
Address all identified issues based on report analysis.

• SPF: Update your SPF record to include all legitimate sending IPs and include statements for third-party senders (e.g., marketing platforms, transactional email services). Ensure the SPF record does not exceed the 10-lookup limit.
• DKIM: Configure DKIM for all legitimate sending services. Verify that DKIM signatures are present and valid for all outgoing mail. Many third-party services provide specific DKIM keys for your domain.
• Alignment: Confirm that the From: header domain aligns with either the SPF Return-Path domain or the DKIM d= tag domain. Adjust relaxed/strict alignment settings if necessary, though strict is preferred for p=reject.

3. Transition to p=quarantine:
Once DMARC reports show a high percentage of legitimate mail passing authentication, transition your policy to p=quarantine. This policy instructs receiving mail servers to treat unauthenticated mail as suspicious, typically by moving it to the spam or junk folder.

• Example DMARC p=quarantine record:
  _dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected]"
• pct=100: Applies the policy to 100% of unauthenticated mail. You can start with a lower pct value (e.g., pct=10) to gradually test the policy's impact.

Monitor DMARC reports again for several weeks. Look for any legitimate emails being quarantined. Adjust SPF/DKIM configurations as needed.

4. Final Transition to p=reject:
When DMARC reports consistently show no legitimate mail failing authentication under p=quarantine, you are ready for p=reject. This policy instructs receiving mail servers to completely block unauthenticated mail.

• Example DMARC p=reject record:
  _dmarc.example.com. IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]"

This final step significantly reduces the risk of spoofing and enhances your domain's email reputation. To ensure your domain's standing, regularly check domain reputation.

Post-Implementation and Best Practices

Implementing DMARC p=reject is not a one-time task. It requires ongoing vigilance and maintenance.

Continuous Monitoring:
Regularly review DMARC aggregate reports. New sending services, changes in existing services, or misconfigurations can cause legitimate mail to fail authentication. Monitoring helps detect and resolve these issues promptly. Automated DMARC report analysis tools can simplify this process.

Sender Compliance:
Any new service or platform sending email on behalf of your domain must comply with your DMARC policy. Ensure SPF and DKIM are correctly configured for these new senders before they begin sending mail. Update your SPF record and add necessary DKIM keys to your DNS.

DNS Management:
Maintain clean and accurate DNS records. Outdated or incorrect SPF and DKIM entries can lead to authentication failures. Regularly audit your DNS for any unauthorized changes or expired records.

Subdomain Policies:
Consider implementing DMARC policies for subdomains. The sp= tag in your DMARC record allows you to set a separate policy for subdomains. For instance, sp=reject will enforce rejection for all subdomains, offering broader protection.

Mailing List Considerations:
DMARC p=reject can impact mailing lists that modify email headers. When an email is sent to a mailing list and then re-sent to subscribers, header modifications can break SPF and DKIM signatures, leading to DMARC failures. Solutions like ARC (Authenticated Received Chain) help preserve authentication results across intermediaries. Ensure your mailing list providers support ARC or other DMARC-friendly forwarding methods.

By adhering to these practices, organizations can maintain a strong DMARC p=reject posture, maximizing email deliverability and ensuring robust protection against email-based threats well into 2026 and beyond.