554 5.7.5 Evaluating DMARC Policy: Read the Record First

A bounce reading 554 5.7.5 permanent error evaluating DMARC policy reports a problem with your DNS, not with the message that came back. The receiving server is saying it could not finish evaluating the policy you published, so the first command to run is a TXT query against _dmarc.yourdomain.com, before anyone opens the sending platform.

What The Numeric Code Is Telling You

RFC 3463 defines the enhanced status codes that sit in front of that message, and the definition is narrower than the wording suggests. The specification describes a 5.x.x class as "a permanent failure is one which is not likely to be resolved by resending the message in the current form." The 7 in the middle covers security and policy: "the security or policy status codes report failures involving policies such as per-recipient or per-host filtering and cryptographic operations."

The specific code is stranger. RFC 3463 defines X.7.5 as a cryptographic failure, where "a transport system otherwise authorized to validate or decrypt a message in transport was unable to do so because necessary information such as key was not available or such information was invalid."

So the number and the sentence beside it describe different problems. The human-readable text belongs to the receiving system and carries the real diagnosis; the registered code tells you only one thing worth acting on, which is that resending the same message will not change the outcome. Turning off retries on this bounce class is the first operational decision, because a retry loop against a permanent failure adds bounce volume to a domain that is already having a bad day.

Rule Out A Duplicate Record Before Anything Else

RFC 7489 sets out how a receiver finds your policy, and the failure mode here is blunt. After collecting the candidate records, the specification states that "if the remaining set contains multiple records or no records, policy discovery terminates and DMARC processing is not applied to this message."

Two records at _dmarc is a common outcome of ordinary company activity. One team publishes a policy during an authentication cleanup, a monitoring platform publishes its own during onboarding, and nobody removes the first. Both look correct in isolation, and the lookup that matters returns both.

Run the count before the inspection:

One line back is the only healthy answer. Two lines is your bounce, and the fix is deletion in the DNS zone, not an edit to either record.

Check The Version Tag Character By Character

RFC 7489 is strict about exactly one part of the record. On the v tag it states that "it MUST have the value of 'DMARC1'," and that "the value of this tag MUST match precisely; if it does not or it is absent, the entire retrieved record MUST be ignored."

A leading space before v, a lowercase dmarc1, or a curly quotation mark pasted out of a word processor all defeat that test. The policy then reads as absent, which is a different condition from failing, and it produces confusing evidence: your record is visibly published, your checker says the domain has DMARC, and receivers behave as though it does not exist.

The rest of the record is governed by a much softer rule. The specification says "unknown tags MUST be ignored," and that "syntax errors in the remainder of the record SHOULD be discarded in favor of default values (if any) or ignored outright."

Our view: a missing mailto: in the rua tag is a weak suspect for this bounce, and the specification is what demotes it. Receivers are instructed to discard errors after the version tag and carry on, so a broken reporting address rarely stops evaluation by itself. Check the front of the record first, and fix the rua because you want your reports back, not because it caused the rejection.

When The Record Is Clean And The Bounce Continues

A single record with a valid version tag moves the diagnosis somewhere else entirely. At that point the receiver evaluated your policy successfully and applied it, and the message failed because neither SPF nor DKIM aligned with the domain in the From header.

That is a different repair with a different owner. Alignment problems come from a sending platform authenticating under its own domain, a forwarding hop that rewrites the envelope, or a DKIM key that was published once and never rotated after a platform migration. Our walkthrough of how to fix DMARC reject covers the alignment path, and how to fix email authentication failing covers isolating which of the two signatures broke.

A second zone problem creates the same bounce pattern from a different direction. Microsoft's DNS reference for Microsoft 365 states that "you can only have one SPF record (that is, a TXT record that defines SPF) for your domain." A second SPF record breaks SPF evaluation the same way a second DMARC record breaks policy discovery. Both come from the same cause, which is a zone edited by several teams over several years, so we check for both in one pass.

The Order We Work Through It

We treat this bounce as a DNS incident with one named owner, because the alternative is three people editing the same zone on a hunch and nobody able to say afterwards which edit changed the outcome.

We also pause the affected sequences while it runs. A campaign generating permanent failures against a policy the receiver cannot evaluate is spending domain reputation for no delivered mail, and the pause costs less than the recovery.

The one judgement call in the sequence below is when to stop. Each check either explains the bounce or clears a suspect, and the moment a check explains it, the remaining checks are optional. A duplicate record found at step one makes steps two and three irrelevant until the duplicate is gone and the bounce is retested.

Run This Today

1. Query dig +short TXT _dmarc.yourdomain.com and count the returned lines. More than one is the answer, and deletion is the fix.
2. Read the first eight characters of the record from that output. Anything other than v=DMARC1 explains the bounce on its own.
3. Query the same way for TXT yourdomain.com and count how many answers begin with v=spf1. More than one breaks SPF independently.
4. Turn off automatic retries for this bounce class in your sending platform, since RFC 3463 classifies it as not resolvable by resending.
5. If all three lookups come back clean, capture a full header from a bounced message and compare the From domain to the SPF and DKIM signing domains.

Step five is what separates a five-minute DNS edit from a sending-platform migration. A clean record with a failed alignment check means the record was never the problem, and continuing to edit it burns the afternoon.

If you want your authentication records, sending domains and sequence setup checked together before the next campaign goes out, book a free ICP and campaign-fit discovery call →.