What Happens to Unauthorized Emails When DMARC Reject Is Active?

When an unauthorized email encounters an active DMARC reject policy, the receiving mail server immediately drops or blocks the message during the SMTP transaction, preventing it from ever reaching the recipient's inbox or spam folder. Domain-based Message Authentication, Reporting, and Conformance (DMARC) relies on Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) to verify message authenticity. If an email fails both alignment checks while your policy is set to reject, the receiving MTA refuses the incoming message with a permanent 5xx SMTP error code, often bouncing a non-delivery report back to the sender address (though that address is typically spoofed).

Before implementing strict enforcement, you should thoroughly audit your domain configuration using the Email Security Checker to identify misconfigured sending sources and ensure legitimate mail passes authentication. Understanding the exact lifecycle of a rejected message helps administrators balance strict anti-spoofing security with the delivery of legitimate business emails.

The DMARC Authentication and Alignment Mechanism

To understand why an email gets rejected, you need to understand how DMARC evaluates incoming messages. DMARC does not perform authentication itself; instead, it checks the results of SPF and DKIM and enforces alignment.

Alignment means the domain found in the visible From: header of the email matches (or has an organizational domain match with) the domain used in the SPF MAIL FROM address or the DKIM d= tag.

• SPF Alignment: The domain in the Return-Path must match the Header From domain.
• DKIM Alignment: The domain in the signature's d= parameter must match the Header From domain.

If a malicious actor or an unauthorized third-party service tries to send an email using example.com in the From: header without authorization, SPF will fail because their IP is not in your DNS record. If they also lack a valid cryptographic signature matching your domain, DKIM will fail. When DMARC evaluates these failures against a policy of p=reject, it instructs the receiving server to terminate the connection.

Step-by-Step: What Receiving Servers Do with Rejected Mail

When a receiving mail server processes an inbound message for a domain protected by p=reject, it follows a strict sequence of events defined in RFC 7489.

1. Ingestion and Evaluation

The receiving Mail Transfer Agent (MTA) accepts the SMTP connection, reads the message headers and body, and performs standard SPF and DKIM checks based on the incoming IP address and cryptographic signatures.

2. DMARC Policy Lookup

The MTA performs a DNS query for the DMARC record of the domain specified in the Header From address (e.g., _dmarc.example.com). It retrieves the policy tag, which reads p=reject.

;; Query today's DMARC record for example.com
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

3. Enforcement of the Reject Policy

Because the message failed both SPF and DKIM alignment, and the policy dictates rejection, the receiving server generates an SMTP rejection response. A typical response looks like this in server logs:

550 5.7.1 Unauthenticated email from example.com is not accepted due to domain's DMARC policy

4. Generation of Feedback Reports

If the DMARC record includes a rua= (aggregate report) or ruf= (forensic report) tag, the receiving server compiles daily XML reports detailing the failure. These reports are sent to the designated reporting address, allowing domain owners to monitor blocked traffic and identify legitimate services that might be failing authentication.

Real-World Example: Tracing a Spoofing Attempt

Imagine a malicious actor attempts to send a phishing email pretending to be support@example.com using an untrusted server with IP address 192.0.2.50.

1. The attacker connects to a major email provider (like Gmail or Microsoft 365) via SMTP.
2. The provider checks the SPF record for example.com: v=spf1 include:_spf.google.com ~all.
3. IP 192.0.2.50 is not authorized by that SPF record, resulting in an SPF failure.
4. The attacker attaches no valid cryptographic signature, resulting in a DKIM failure.
5. The provider checks the DMARC record and finds p=reject.
6. Instead of placing the message in the spam folder, the provider responds with an SMTP error code and drops the message payload entirely.

The end user never sees the email—not even in their junk folder. This complete suppression is the primary benefit of the reject policy, as it eliminates any risk of a user interacting with a phishing email.

Comparison: None vs. Quarantine vs. Reject

Choosing the right DMARC policy depends on your current visibility and risk tolerance. Here is how reject compares to softer policies.

Common Mistakes and How to Fix Them

Implementing a strict DMARC policy without careful preparation can cause severe operational disruptions. Avoid these frequent pitfalls:

• Forgetting Third-Party Senders: Marketing platforms, CRM tools, and ticketing systems often send emails on your behalf. If you enforce p=reject before configuring custom DKIM CNAMEs and SPF includes for these vendors, all their outbound mail will be dropped.
• Misaligned Return-Path: Many administrators ensure SPF passes for the third party's domain, but forget that DMARC requires alignment with the Header From domain. Ensure your third-party senders support custom return-path domains matching your brand.
• Skipping the p=none Phase: Moving straight to reject without reviewing XML aggregate reports guarantees legitimate mail will break. Always spend at least two to four weeks analyzing reports at p=none.
• Subdomain Oversights: By default, a DMARC record applies only to the exact domain specified, unless a separate sp= tag is defined for subdomains. Ensure your subdomain policy (sp=) is explicitly declared if you send mail from subdomains like mail.example.com.

Verification Checklist for DMARC Reject

Use this checklist before and after changing your DMARC policy to p=reject:

• Inventory every service, server, and SaaS application that sends email using your domain.
• Implement strict SPF records covering all legitimate sending IPs and include mechanisms.
• Configure custom DKIM keys (selectors) for all third-party email providers.
• Deploy DMARC with p=none and valid rua reporting addresses for at least 14 days.
• Analyze aggregate reports to confirm 100% legitimate traffic alignment.
• Transition the DMARC policy gradually: p=none -> p=quarantine -> p=reject.
• Continuously monitor incoming forensic and aggregate reports for sudden spikes in failure rates.