Email rejected per DMARC policy: how to fix the bounce

What usually causes it?

A legitimate sender has no aligned authentication pass

A marketing platform, CRM, help desk, or transactional service can use your visible From domain while using its own envelope sender and DKIM signing domain. In the illustrative header, SPF fails for bounce.marketing-tool.example and DKIM is absent. Neither result supplies an aligned pass for example.com.

Confirm the application and outbound route before changing DNS. Why DMARC fails and how to fix it explains why a passing authentication result can still fail DMARC alignment.

DKIM passes for an unaligned signing domain

A dkim=pass result is insufficient by itself. The passing header.d domain must align with the visible From domain under the domain's DMARC alignment mode. This follows from the DMARC alignment rules in RFC 9989. It does not prove that a particular sending service lacks support for domain authentication.

SPF passes for an unaligned envelope sender

SPF evaluates the SMTP envelope sender domain, exposed as smtp.mailfrom in a trusted Authentication-Results field. A service can pass SPF for its own return-path domain while the visible From address uses your domain. DMARC still fails unless DKIM supplies an aligned pass.

Do not add a service to SPF based on a bounce alone. Confirm that the service sent the rejected production path, then use that provider's current account-specific instructions for an authenticated return path or DKIM domain.

An indirect mail flow changed the message path

Forwarding can break SPF because the receiver evaluates the forwarding server's IP address. An aligned DKIM signature can preserve DMARC through an unmodified indirect flow, but message changes by a list or intermediary can invalidate that signature. RFC 7960 explains these indirect-mail limitations.

This remains an inference until you compare the original route with the forwarded or list-processed route.

The rejected message was spoofed

If sender logs and DMARC reports do not identify the IP, application, or platform as an authorized source, the rejected message may be spoofed. In that case, rejection can be the expected result of enforcement. Changing policy reduces the domain's requested protection without repairing a legitimate sender.

For help interpreting other returned-mail symptoms, see Bounce-back email: how to read the error and fix the cause.

What about "554 5.7.5 Permanent Error Evaluating DMARC Policy"?

Some receivers return a 554 response instead of a 550 when DMARC evaluation fails:

554 5.7.5 Permanent Error Evaluating DMARC Policy

554 5.7.5 means the receiver queried _dmarc. and could not turn the answer into a policy. The record was unparseable or ambiguous. That is a policy discovery failure rather than an authentication result, so a message can draw this response while SPF and DKIM both pass. It is not an authentication verdict at all: RFC 3463 registers X.7.5 as "Cryptographic failure", so this string is a receiver's non-standard reuse of a code that means something else. Preserve the exact response, then check the record itself before changing anything else.

A DMARC record the receiver cannot resolve

Publish exactly one DMARC record at _dmarc. When two TXT records exist there, policy discovery returns no usable record and receivers can return this permanent-error response even though each record looks valid on its own. Query the label directly to see what the receiver sees:

dig +short TXT _dmarc.example.com

Exactly one line should come back, and it should start with v=DMARC1. Two lines is the common cause. No line at all is a different situation: a domain that publishes no DMARC record is skipped rather than rejected, so look at the recipient-side policy below.

A single record still fails to parse when it omits the policy tag or carries stray characters. Start with v=DMARC1, specify the policy with p= (none, quarantine, or reject), and remove characters left by manual entry or a copy-paste mistake. This record fails because of the trailing tag:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; extra-character=!;

Remove the invalid extra-character=!; entry, republish, and validate the record before resending.

A recipient-side policy

The receiving server applies its own rules for handling mail that fails authentication, and those rules can reject or quarantine a message independently of your published record. When one recipient domain keeps rejecting repaired mail, work with that recipient to understand how its policies evaluate the message and align your authentication settings accordingly.

What this response does not tell you

A misconfigured SPF or DKIM record does not produce 554 5.7.5. It produces an ordinary DMARC failure and one of the 550 responses covered above. If the record at _dmarc resolves and parses and mail is still rejected, the problem is the alignment failure described earlier on this page, not this one.

You will still need the record syntax to make that repair. An SPF record is a DNS TXT record that looks like this:

v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.0/24 include:example.com -all

The ip4: mechanisms authorize address ranges, include: pulls in another domain's authorized senders, and -all marks every other source as a hard fail. A DKIM public key is published under a DKIM selector:

thirdparty._domainkey.example.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

Use the selector and key generated by your own sending service, not this example.

What about "DMARC unauthenticated mail is prohibited"?

"DMARC unauthenticated mail is prohibited" is a third wording for the same rejection: the receiver found no aligned SPF or DKIM pass and applied the published DMARC policy. Google states the same refusal as a 550-5.7.26 response, and that is the wording senders most often paste into a search box:

550-5.7.26 Unauthenticated email from example.com is not accepted due to
domain's DMARC policy. Contact the administrator of example.com domain if this
was legitimate email. To learn about the DMARC initiative, go to Control
unauthenticated email from your domain.

Microsoft and several appliance vendors return the "unauthenticated mail is prohibited" phrasing instead. The response code differs and the sentence differs, but the cause does not. Unauthenticated mail here means mail that carries no authentication result the receiver can tie back to the domain in the visible From: header, not mail that failed a spam check.

Treat it exactly like the 550 5.7.1 case above. Preserve the response, identify the sending service, then check alignment before changing anything in DNS. For the Google response code on its own, including the full text Gmail returns and the retry behaviour, see SMTP error 550 5.7.26.

How do I diagnose the failure?

1. Preserve the complete returned bounce

Save the complete bounce, reporting host, SMTP status, timestamp, visible From domain, recipient domain, and diagnostic text. Match it to sender logs using the Message-ID, recipient, and sending time where available.

Build a labelled evidence packet before editing DNS or vendor settings:

Illustrative redacted rejection evidence packet
Visible From domain: example.com
SPF envelope domain/result: bounce.marketing-tool.example / fail
DKIM d=/selector/result: marketing-tool.example / selector1 / none
DMARC result/disposition: fail / p=REJECT
Exact recipient response: 550 5.7.1 Unauthenticated email from example.com is not accepted due to domain's DMARC policy.
Message ID/time: <redacted-message-id> / 2026-08-12T10:15:00Z
Sender application: marketing platform

If the response says 550 5.7.1, retain its exact wording. The broad 550 5.7.1 variant guide shows how to distinguish DMARC wording from relay, blocklist, recipient-policy, and content-policy refusals.

2. Identify the exact production sender

Determine which application, ESP, gateway, or user submitted the message. Record the visible From domain, envelope sender, outbound relay or IP, DKIM selector, and branded-domain configuration.

Do not identify the application from the display name. One domain can be used by several independent systems with separate SPF, DKIM, and return-path settings.

3. Read a controlled delivered message

Send a controlled message through the same application, authenticated domain, template type, outbound route, and recipient provider where practical. Deliver it to a mailbox you control that exposes full headers.

Compare the visible From domain with the SPF smtp.mailfrom domain and any passing DKIM header.d domain in the trusted receiver-added Authentication-Results field. This identifies the branch to repair:

• Authentication failure: SPF and DKIM both fail or are absent. Repair the confirmed sender's authentication setup.
• Alignment failure: SPF or DKIM passes, but its passing domain does not align with the visible From domain. Configure the sender's authenticated return path or DKIM signing domain.
• Receiver decision: DMARC fails and the receiver rejects, quarantines, or accepts the test. The domain policy is a request, not a guarantee of identical treatment across receivers.

4. Check the published DMARC policy separately

Look up the From domain's DMARC record after you preserve the message evidence. Confirm the domain being checked is the exact visible From domain or its applicable organizational domain. Record p=, adkim=, and aspf= if they are present.

A public record result shows current DNS publication. It does not prove that the application signs mail, uses the configured return path, or produced the rejected message.

How do I fix it?

Configure the confirmed sender's aligned DKIM domain

When the application supports custom DKIM signing, configure the domain it provides in its account settings and publish the account-generated DNS records. Then complete the provider's verification process.

Do not publish selectors, CNAME targets, tokens, or hostnames copied from another account. Use only values generated for your own domain and tenant.

This repair changes authentication and alignment. It does not alter DMARC enforcement.

Configure an authenticated return path when SPF is the aligned path

When the sender supports a custom return path, publish its account-generated DNS records and confirm that the envelope sender uses the authenticated subdomain. Then send a new message and compare the resulting smtp.mailfrom domain with the visible From domain.

An SPF include can authorize infrastructure, but it does not by itself make a third-party envelope domain align with your visible From domain.

Repair the signing or routing order for indirect mail

If a forwarder, list, or gateway changes the message after signing, determine whether the change can occur before aligned DKIM signing or whether the route can avoid the modification. Test one controlled route at a time.

Do not treat forwarding as proof that the sender configuration is correct. Forwarding and message modification are separate conditions under RFC 7960's indirect-mail guidance.

Keep an enforcement change separate from the repair

Do not lower p=reject as the technical fix. Changing p= changes the domain's requested DMARC handling, not the sender's SPF result, DKIM signature, or domain alignment. If an incident requires a temporary policy decision, document it separately, limit its duration, and continue repairing the identified sender.

How do I validate the repair?

To validate a DMARC rejection repair, repeat the same production path: the same application, visible From domain, template, recipient provider, and routing conditions. A successful DNS lookup is only the first validation layer.

Check each applicable layer:

• DNS: query the domain's published records through the authoritative DNS provider and at least one public resolver.
• Vendor: confirm the sender's current domain-authentication or verification status in its own interface.
• Message: send a new message and inspect the trusted receiver-added Authentication-Results field for an SPF or DKIM pass aligned with the visible From domain.
• DMARC: after reports accumulate, confirm that the repaired source appears as expected in DMARC aggregate-report data.

Find every sender that still fails DMARC alignment

Check the domain's published policy before making another change.

Check your domain's DMARC record

The checker inspects the published record and SPF/DKIM posture. It cannot prove why one specific receiver rejected one specific message, does not monitor continuously, and does not guarantee future inbox placement.

After one sender is aligned, the remaining question is which other production sources still fail alignment. Palisade's DMARC Agent analyzes incoming DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. Your team reviews the evidence and applies the fix. Palisade does not change your DNS or DMARC policy automatically, does not control receiver-side handling, and does not guarantee delivery.

Start with Palisade