Email rejected per DMARC policy: how to fix the bounce

An "email rejected per DMARC policy" bounce means a receiving mail server refused your message because the From domain publishes a DMARC policy of quarantine or reject, and the message produced no aligned SPF or DKIM pass. It is usually a real authentication gap, not a mail-server outage. Fix it by reading the bounce and the Authentication-Results header to find the failing source, aligning SPF or DKIM for that source, then resending on the same path.

Quick takeaways

• The bounce means the From domain's DMARC policy is quarantine or reject and the message had no aligned SPF or DKIM pass.
• DMARC passes when SPF or DKIM both authenticates and aligns with the visible From domain, and one aligned pass is enough.
• Read the returned bounce and the message's Authentication-Results header to see which mechanism failed and whether it aligned.
• The most common cause is a legitimate sending platform that is missing from SPF and has no aligned DKIM signature for the From domain.
• Forwarding and mailing lists break SPF alignment, so an aligned DKIM signature is what usually survives.
• Repair the specific failing source, then resend on the same path and confirm dmarc=pass before assuming it is fixed.

What does the failure mean?

A receiver returns this bounce when it evaluates your message against the From domain's DMARC record and finds no aligned pass. Under the DMARC standard (RFC 7489), a message satisfies DMARC only when SPF or DKIM produces a pass on an identifier that aligns with the visible From domain, and the domain owner's policy of p=quarantine or p=reject tells the receiver how to treat a message that fails. A receiver may still deviate, so the policy is a request rather than a guarantee. If you are new to how DMARC evaluates a message end to end, start there.

The bounce and the message's own headers are the primary evidence. The example below shows what a rejection and its Authentication-Results header look like together. Every value here is illustrative, not generated from a real account.

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

Authentication-Results: mx.receiver.example;
  spf=fail smtp.mailfrom=bounce.marketing-tool.example;
  dkim=none header.d=marketing-tool.example;
  dmarc=fail (p=REJECT) header.from=example.com

Different receivers word the bounce differently. Gmail returns text such as "Unauthenticated email from example.com is not accepted due to domain's DMARC policy," documented in Google's guidance on controlling unauthenticated mail, while Microsoft 365 DMARC handling rejects a failing message during the SMTP session with 550 5.7.1 when the sender publishes p=reject. The numeric code varies by receiver, so treat the code in any single example as one receiver's format rather than a universal string.

What usually causes it?

A rejection under an enforcing policy almost always traces to one authentication or alignment gap, not to the receiver. The causes below are ordered by how often they explain a real bounce. For a broader tour of why DMARC failures happen, read the companion guide, then match your own headers to the specific cause here. No provider documents the exact cause of a single message, so confirm the cause from your Authentication-Results header and reports instead of assuming it.

A legitimate sending source is missing from SPF and has no aligned DKIM signature

The most common case is a real platform you use, such as a marketing tool or helpdesk, that sends as your domain but is not listed in your SPF record and does not sign with DKIM using your domain. SPF fails because the sending IP is not authorized, DKIM cannot align because there is no signature for the From domain, and DMARC then fails on both mechanisms.

DKIM signs with a different domain than the visible From address

Here SPF or DKIM can pass on its own yet DMARC still fails, because the passing identifier does not align with the From domain. A vendor that signs with its own d= domain produces a dkim=pass result that does not match your From address. That alignment gap is exactly why DMARC can fail even when SPF passes.

Forwarding or a mailing list broke SPF alignment

When a message is forwarded or sent through a mailing list, the forwarder often keeps your envelope sender, so SPF fails at the new hop, or rewrites it, so SPF passes for the forwarder but no longer aligns with your From domain. The indirect mail flows described in RFC 7960 explain why an aligned DKIM signature is usually the only thing that survives, and why list software that adds a subject tag or a body footer can break even that signature.

The From domain moved to p=reject before every sender was aligned

If the domain advanced to p=reject while a legitimate sender was still unaligned, that sender's mail starts bouncing. The policy is doing what it was set to do, and the gap is an unaligned source that enforcement now blocks rather than a fault in the policy itself.

The rejected message is spoofed and the policy is working as intended

Not every rejection is a mistake. If the failing source is not yours, the bounce is the policy refusing forged mail, which is the outcome p=reject exists to produce. Confirm the source before you change anything, because relaxing the policy to rescue this one message would also unprotect the domain.

How do I diagnose the failure?

Work from the strongest evidence to the weakest: the returned bounce and the message headers first, then DNS, then your aggregate reports. The flow below shows the whole path from the bounce to a validated dmarc=pass.

Source: Original deterministic Palisade diagram of the path from an "email rejected per DMARC policy" bounce to a validated dmarc=pass. It summarizes the steps below; the linked RFCs and provider documentation define the exact decisions.

1. Read the exact bounce and note the reporting host and From domain

Copy the full bounce, not just the first line. Note the reporting host, which is the receiver that refused the message, and confirm the From domain it names. If the bounce carries a specific SMTP code such as 550 5.7.1, that code narrows the receiver's stated reason; the guide to unauthenticated mail and the 550 5.7.1 code covers that string in detail.

2. Inspect the Authentication-Results header for spf, dkim, and dmarc

Open a copy of the message that failed and read its Authentication-Results header. Per the Authentication-Results header field (RFC 8601), each method reports a result and the property it checked: spf against smtp.mailfrom, dkim against header.d, and the overall dmarc result against header.from. Trust only the Authentication-Results added by the receiver that handled the message, because a conforming server removes forged instances from outside its trust boundary. Read whether each mechanism passed and, more importantly, whether the passing identifier aligns with the From domain.

3. Confirm the published DMARC policy and alignment mode for the From domain

Look up the _dmarc TXT record for the exact From domain and read its policy tag and alignment mode. A value of p=reject or p=quarantine confirms enforcement is active. The aspf and adkim tags set whether alignment is relaxed or strict, and strict alignment rejects a subdomain mismatch that relaxed alignment would accept. If a subdomain sent the message, check whether it inherits the organizational domain's record or publishes its own.

4. Match the failing source to a sender in your DMARC aggregate reports

Aggregate reports name the sending IPs and show, per source, whether SPF and DKIM authenticated and whether they aligned. Find the IP or hostname from your bounce or headers in the reports and confirm it is the source that fails alignment. This is where you separate a legitimate sender you must align from forged mail you should let the policy reject. Because no provider maps one bounce to one cause, this match is what turns a guess into a confirmed source.

How do I fix it?

Apply the narrowest repair that aligns the confirmed source. Do not weaken the policy to make the bounce stop; that is handled separately below, because it changes enforcement rather than authentication.

Align the failing source with SPF or DKIM

For a platform that sends as your domain, add its sending mechanism to your SPF record so SPF authenticates and aligns, or configure DKIM at the platform so it signs with your domain. One aligned pass is enough for DMARC, so you do not need both. Prefer DKIM alignment when the platform supports signing as your domain, because a DKIM signature survives forwarding.

Fix DKIM so the signing domain matches the From domain

If the vendor already signs but with its own d= domain, switch it to sign with your domain or a subdomain of it so header.d aligns with header.from. A passing but unaligned signature does not satisfy DMARC, so alignment, not just a valid signature, is the goal.

Handle forwarding and mailing-list mail

You cannot fix a third party's forwarder from your own DNS. Make sure the original message carries an aligned DKIM signature so it can survive the hop, and for internal forwarding consider an ARC-aware path. Accept that some forwarded and mailing-list mail will fail SPF alignment by design.

Reduce impact safely while you align senders

If legitimate mail is bouncing and you need time, you can lower enforcement, but treat this as temporary containment, not a repair. Moving the policy to p=none stops the rejection while removing the spoofing protection the policy provided, and it leaves the underlying authentication gap in place. Re-enable enforcement as soon as the source is aligned.

How do I validate the repair?

Validate on the same sending path that failed, not a substitute. Resend a real message from the repaired source to a mailbox at the receiver that rejected it, then open the delivered message and read its Authentication-Results header for dmarc=pass with the previously failing mechanism now aligned. Confirm the published _dmarc record still shows the policy you expect. Finally, watch the next aggregate reports and check that the source that failed now shows an aligned pass. A single delivered message plus a report trend is stronger proof than any one check on its own.

Find every sender that still fails DMARC alignment

Aligning one source fixes one bounce. It does not tell you which other production systems still send as your domain without an aligned pass, or whether the published record itself is correct. Start by checking the domain's published DMARC record and its SPF and DKIM posture with Palisade's DMARC checker. That inspects the published record from a domain name; it cannot prove why one receiver rejected one message, does not monitor continuously, and does not guarantee future inbox placement.

For ongoing coverage, Palisade's DMARC Agent workflow turns your aggregate-report data into a prioritized list of sender, SPF, DKIM, and DMARC issues and detects when a domain is ready for the next policy stage. A human reviews and applies each change; Palisade does not edit your DNS, change your policy automatically, control receiver-side handling, or guarantee delivery. Start with Palisade when you want that recurring visibility.

Sources and further reading

• DMARC standard (RFC 7489)
• Authentication-Results header field (RFC 8601)
• DMARC and indirect mail flows (RFC 7960)
• Google: control unauthenticated mail from your domain
• Microsoft 365: set up DMARC to validate email
• Palisade: fixing email authentication issues