DMARC Bounce Errors: Find the Cause and Fix Rejected Email

An invoice bounces. A password reset never arrives. Your newsletter is accepted by one provider and refused by another. The delivery report mentions DMARC, but your DNS checker says the record is valid.

Start with the complete rejection message. A DMARC policy rejection, a broken authentication setup, and a provider's additional sending requirements need different fixes. Even a message with DMARC=Pass can be rejected for failing a separate DKIM requirement.

Find Your Error First

 
The descriptions below summarize the diagnostics; they are not interchangeable SMTP responses.

Common SMTP rejection codes and the first authentication issue to investigate for each one.

Microsoft provides separate documents 5.7.515 and 5.7.509 because they refer to different delivery problems. Google lists several meanings for 5.7.26 in its SMTP reference. Yahoo separates authentication failures and DMARC handling.

The 554 5.7.5 and 521 strings above are supplied bounce examples, not universal code definitions.

What a DMARC Policy Rejection Means

 
DMARC connects authentication to the domain people see in the From address. It passes when at least one authentication method both succeeds and aligns with that domain: SPF, DKIM, or both.

A published p=reject expresses the domain owner's handling preference for failing messages; the receiver makes the final delivery decision. See the DMARC specification.

For example:

• A billing application may send as billing@example.com while authenticating only its own infrastructure domain.
• The application can be legitimate and still fail this check.
• The repair belongs to the actual sending application.
• A valid record for your employees' mail platform does not automatically configure your billing system, help desk, or marketing service.

Collect the Evidence Before Editing DNS

 
Before changing your DNS configuration:

1. Save the full delivery report, particularly:
2. Diagnostic-Code
3. Remote-MTA
4. the timestamp
5. Match the failure to your sending platform's event using its message identifier and recipient.
6. Record the relevant identities:
7. the visible From address
8. the SMTP envelope sender
9. any DKIM signing domain and selector available in the original message or logs

Keep these identities separate: the domain people reply to is not necessarily the domain SPF evaluates.

If the message was refused during SMTP, you may not have the rejecting receiver's Authentication-Results header. A delivered test can help, but it is a separate observation.

Use the same application and route, preferably to an account at the affected provider. A Gmail test does not prove what Outlook observed.

Only interpret authentication headers from a trusted receiving service. Other copies may have been added earlier or forged. See the Authentication-Results specification.

Match the Repair to the Failing Identity

 

SPF Fails

 
SPF normally checks the sending IP against the domain in SMTP MAIL FROM, often visible as smtp.mailfrom in authentication results.

To investigate:

• Inspect that domain's configuration.
• Adding an SPF include to your website domain will not repair SPF for an unrelated envelope domain.
• Use your sending provider's account-specific instructions.
• Keep a single SPF policy at the evaluated hostname and check its DNS lookup budget, including nested lookups.
• Do not add every IP from a bounce to your SPF record without identifying the sender.

See the SPF specification.

DKIM Is Missing or Fails

 
A published key does not prove that the application signs outgoing messages.

To investigate:

• Inspect a fresh message for DKIM-Signature.
• Use its d= domain and s= selector to locate the public key.
• Check whether signing is enabled.
• Check whether the correct key is published.
• Check whether a gateway changes signed content after signing.
• Distinguish an absent signature from a present signature that cannot be verified.

See the DKIM specification.

Authentication Passes, but Alignment Fails

 
Consider this original teaching example. It is not a captured customer message:

From: Receipts receipts@example.com

Authentication-Results: mx.test.example;

spf=pass smtp.mailfrom=delivery.example.net;

dkim=pass header.d=example.net;

dmarc=fail header.from=example.com

The service authenticated example.net, while the visible sender uses example.com.

To fix the issue:

• Configure custom DKIM for the customer's domain or a supported custom return path that aligns.
• Check the applicable alignment mode when using subdomains.

Postmark's own DMARC bounce instructions illustrate these two practical configuration paths: domain verification for DKIM and a custom return path for SPF.

Only Forwarded Messages Fail

 
Forwarding changes the IP seen by the next receiver and can break SPF.

An aligned DKIM signature may survive unchanged forwarding, but a mailing list or gateway can invalidate it by modifying the message.

Compare direct and forwarded delivery before treating an intermediary as an authorized original sender. See the indirect mail-flow analysis.

What About “554 5.7.5 Permanent Error Evaluating DMARC Policy”?

 
This wording reports a problem evaluating DMARC. It does not identify one proven DNS fault or one universal receiver implementation.

Start by checking the visible From domain's DMARC lookup:

dig TXT _dmarc.example.com

Then:

• Inspect the DNS status as well as the answer.
• A missing answer and a resolver error are different observations.
• Check the applicable parent-domain policy when the sender uses a subdomain.
• Look for competing DMARC records.
• Look for damaged required values.
• Check for an incorrect hostname.
• Check for differences between authoritative and cached answers.

Multiple quoted strings can belong to one TXT resource record; they are not automatically duplicate policies.

Unknown extension tags are not automatically errors either: the DMARC specification requires unknown tags to be ignored. Avoid deleting configuration merely because a checker does not recognize a tag. See the DMARC record format.

If DNS checks are consistent and only one receiving system still refuses mail:

• Send its administrator the complete diagnostic and a timestamped test.
• Ask what evaluation failed.

Should You Switch to p=none?

 
Changing the policy does not repair authentication or alignment. It also does not exempt you from a provider's sender requirements.

Treat any temporary enforcement change as a separate incident decision with an owner and a restoration plan.

For the original Outlook example:

• SPF=Pass
• DKIM=Fail
• DMARC=Pass

Investigate DKIM first. DMARC already passing is the reason a policy-only change misses the problem.

Verify Delivery, Then Monitor the Sending Source

 
After making the repair:

1. Repeat a small test through the affected application.
2. Confirm the new receiver result and delivery event before resending a failed campaign.

A permanent SMTP rejection does not, by itself, mean the recipient address is invalid. See SMTP reply handling.

Then use DMARC aggregate reports to check whether the repaired source's authentication improves over subsequent reporting periods.

Keep in mind:

• These reports group observations.
• They are not a real-time record of every bounce, recipient, or message.
• Pair them with your ESP's delivery logs.

See DMARC aggregate reporting.

Start with the free DMARKOFF DMARC Checker to inspect the published policy. For ongoing visibility, connect your domain to DMARKOFF and review the sending sources in the reports you receive.
 
Run DMARC Check
 
A useful follow-up to one repaired bounce is finding which other legitimate applications still need attention.