554 5.7.5 permanent error evaluating DMARC policy

The exact bounce

The error usually appears in a non-delivery report or SMTP transcript like this:

554 5.7.5 permanent error evaluating DMARC policy
554 5.7.5 Permanent error evaluating DMARC policy
Remote server returned '554 5.7.5 permanent error evaluating DMARC policy'

The important word is "evaluating". The receiver is saying it could not complete DMARC policy evaluation, or it completed the evaluation and rejected the message under a local DMARC rule. You need the full bounce, the sender domain, and the original message headers to tell which case you are in.

Start with the visible From domain

DMARC evaluates the domain in the visible From: header. If the failed message says it came from [email protected], check example.com, even if the mail server was smtp.vendor.net.

dig TXT _dmarc.example.com +short

Also query public resolvers directly to rule out a local DNS cache problem:

dig TXT _dmarc.example.com @1.1.1.1 +short
dig TXT _dmarc.example.com @8.8.8.8 +short

Cause 1: multiple DMARC policy records

A domain can have only one DMARC TXT record at _dmarc. This is a common cause after someone adds a new monitoring service or copies a generator output into DNS without editing the old record.

Bad result:

"v=DMARC1; p=none; rua=mailto:[email protected]"
"v=DMARC1; p=reject; rua=mailto:[email protected]"

Fix it by keeping one record and merging the useful tags into that single value:

v=DMARC1; p=reject; rua=mailto:[email protected],mailto:[email protected]

Do not publish two separate DMARC policies. Receivers are allowed to treat the domain policy as invalid.

Cause 2: malformed DMARC syntax

DMARC records are simple but unforgiving. These examples can trigger permanent evaluation errors or cause receivers to ignore the policy:

# Wrong - missing v tag
p=reject; rua=mailto:[email protected]

# Wrong - invalid policy value
v=DMARC1; p=block; rua=mailto:[email protected]

# Wrong - tag name is policy, not p
v=DMARC1; policy=reject; rua=mailto:[email protected]

# Correct
v=DMARC1; p=reject; rua=mailto:[email protected]

Check for smart quotes, commas where semicolons are required, extra records created by your DNS provider, and line breaks pasted into the wrong field.

Cause 3: DNSSEC or resolver SERVFAIL

If DNSSEC is broken, some receivers cannot retrieve your DMARC policy even though a casual DNS lookup may appear to work from another resolver. Test for failures:

dig TXT _dmarc.example.com +dnssec
dig TXT _dmarc.example.com @9.9.9.9 +dnssec

Look for SERVFAIL, missing DS records after a nameserver move, expired DNSSEC signatures, or mismatched keys at the registrar. If DNSSEC is the cause, fix the delegation first. Editing the DMARC record will not help until DNS validation succeeds.

Cause 4: the receiver is rejecting a real DMARC failure

Sometimes the DNS is fine and the phrase is just how the recipient gateway reports a DMARC rejection. Check the failed message, if you have it, for an Authentication-Results header:

Authentication-Results: mx.receiver.example;
  spf=fail smtp.mailfrom=bounce.vendor.net;
  dkim=fail header.d=vendor.net;
  dmarc=fail header.from=example.com

If the sender domain publishes p=quarantine or p=reject, and both SPF and DKIM fail alignment, rejection is expected. Fix the sender:

1. Make sure the service is authorized in SPF for the envelope sender domain.
2. Enable DKIM signing in the service using a domain aligned with the visible From domain.
3. Send a new test message and verify that either SPF or DKIM passes and aligns.
4. Keep DMARC aggregate reports on so you can see whether the failure is isolated or widespread.

Cause 5: external report authorization confusion

If your rua address points to a different organizational domain, some validators warn about missing external reporting authorization. That is worth fixing, but it normally affects report delivery, not message delivery. Do not assume it is the cause of a 554 5.7.5 bounce unless the recipient logs explicitly say the policy parser failed on that tag.

A cross-domain reporting address looks like this:

v=DMARC1; p=reject; rua=mailto:[email protected]

The reporting destination domain may need an authorization TXT record. Your DMARC monitoring provider should tell you the exact value.

What to collect before escalating

If your DMARC DNS is valid but the bounce continues, collect these details before asking the recipient or your mail provider to investigate:

• The full SMTP error, including the remote server hostname.
• The sender address, recipient address, and timestamp with timezone.
• The visible From: domain and envelope sender domain.
• The sending source IP, if shown in the bounce or mail logs.
• The current _dmarc TXT result from two public resolvers.
• Full headers from a similar delivered message sent through the same provider.

This separates a real sender-side DMARC issue from a receiver-side mail gateway rule that happens to use DMARC wording in the bounce.

Validate the fix

After you change DNS, wait at least one TTL, then verify:

dig TXT _dmarc.example.com @1.1.1.1 +short
dig TXT _dmarc.example.com @8.8.8.8 +short

You want exactly one valid v=DMARC1 record and no DNSSEC or resolver errors. Then use the DMARCTrust DMARC checker to validate the live policy and the rest of your SPF and DKIM setup.

Finally, send a fresh test message. Do not reuse an old bounce, because DMARC is evaluated at delivery time against the DNS and message headers that exist for that new attempt.

Related fixes

• If the record is missing or still at monitoring mode, read DMARC policy not enabled.
• If the message fails because identifiers do not match, read DMARC alignment issues.
• If SPF returns permerror, read SPF errors.
• If a DKIM selector is missing or duplicated, read multiple DKIM records.