This bounce means a receiving server could not read your domain's DMARC record well enough to apply it, not that your message failed authentication.
Four things cause it: two DMARC records at once, a syntax fault in one record, a record at the wrong DNS name, or a resolver that will not answer.
Find your branch below.
The number itself adds to the confusion. RFC 3463 originally defined the enhanced status code X.7.5 as Cryptographic failurea label written for S/MIME key problems years before DMARC existed.
Mail providers repurposed the same code for a DMARC record a server could not evaluate, which is why the wording on the wire rarely matches what an RFC glossary says the code means.
Which of these four is it
Symptom | What it indicates | Read this |
|---|---|---|
A lookup tool or | Duplicate records, the most common cause | Two records answer when you query |
One record exists and a checker still flags it as invalid | A syntax fault inside the record itself | One record, and a checker calls it invalid |
The record checks out clean everywhere you look, but the bounce keeps coming | Published at the wrong DNS name for this sender | The record is published at the wrong name |
| The zone itself is not resolving | DNS itself will not answer |
None of the four rows above match your situation | Escalate it | None of these match: escalate it |
Read the bounce before you touch DNS
Two facts decide everything that follows.
The first is which domain actually failed. A 554 5.7.5 reply names the domain in the visible From header, the one DMARC evaluates, and that domain is not always the one you were watching. A message relayed through a second platform, forwarded from an old address, or sent from a marketing tool on a lookalike subdomain can trip this on a domain nobody checked.
The second is what your own lookup shows. Before changing anything, query the record directly. The output tells you whether you are in the duplicate branch, the syntax branch, or somewhere else entirely.
A clean domain returns exactly one string. Querying _dmarc.google.com for this piece, live, returned a single record in 6 milliseconds:
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"One answer, one target, nothing for a receiving server to discard. That single line is the whole reason the next four sections exist: each one is a different way a domain fails to look like that.
Find the visible From domain
Open the full headers, not the summary view. Look for the From: line as written by the sending system, then compare it against whatever domain your DMARC record actually lives on. A mismatch here sends you chasing the wrong zone.
Count the records
Run the same query against your own domain. One answer is healthy. Two or more, and the receiving server is not obligated to pick a favorite. It drops both.
Two records answer when you query _dmarc
What it means: A domain can publish only one DMARC policy record. A second one, added by an old marketing tool, a second DNS provider, or a migration nobody finished, does not average out or merge with the first.
Per RFC 7489 section 6.6.3, a receiver encountering more than one record at _dmarc must stop policy lookup entirely: "policy discovery terminates and DMARC processing is not applied to this message." RFC 9989, the DMARC specification that replaced 7489 in May 2026, restates the same outcome inside its DNS tree walk procedure: multiple records at one target "are all discarded."
That is a specific instruction, not a vague warning, and it says skip, not reject. A 554 5.7.5 bounce is one receiving system's own choice to treat a discarded lookup as a hard failure rather than falling back to no policy.
Two message providers can see the identical duplicate record and produce two different outcomes: one delivers with no DMARC applied, the other returns this exact string.
Confirm it: Query _dmarc.yourdomain.com for TXT records through your DNS host's own panel, not only a third party checker, since some checkers silently collapse duplicates into one display row.
Fix it: Delete every record at _dmarc except the one you intend to keep. Check every place a record could have been added: your primary DNS host, a CDN or proxy layer that manages its own DNS, and any marketing, help desk or forms tool that ran a DMARC setup wizard during onboarding.
Takes effect: Once you are down to one record, a receiving server sees it on its next lookup. That is governed by the TXT record's TTL, often anywhere from 5 minutes to 24 hours depending on what your zone was set to before the change.
One record, and a checker calls it invalid
What it means: A single record can still fail if its syntax is wrong. The confirmed cause behind two separate Microsoft support threads on this exact error was a trailing period at the tail end of the record value, a character that renders invisibly in most DNS editing screens.
Other syntax faults on this site's coverage map: smart quotes copied in from a word processor, a missing semicolon between tags, tags placed out of the required order, or a mailto: scheme typed twice inside the rua address.
One tag deserves its own note: p=. RFC 7489 section 6.6.3 states that when the p tag is missing or unreadable but the record still carries a valid rua address, a receiver "SHOULD act as if a record containing a valid 'v' tag and 'p=none' was retrieved, and continue processing."
A broken p= tag alone, with everything else intact, is supposed to degrade to no enforcement rather than block mail. A hard 554 5.7.5 on a record with only that one fault points at a stricter local implementation, not at the specification.
Tag | Plain meaning | Why it matters here |
|---|---|---|
| Declares the record as DMARC, must be the first tag | A missing or misplaced |
| The policy: none, quarantine, or reject | A malformed value can fall back to none rather than block |
| Where aggregate reports go | Must use |
| Where forensic reports go | Optional, same |
| Percent of mail the policy applies to | A stray value outside 0 to 100 breaks parsing |
| Policy for subdomains | Read separately by the tree walk, covered below |
Confirm it: Paste the record's raw text into a plain text editor and turn on invisible characters, or read it back with dig +short TXT _dmarc.yourdomain.com and count every character against what you intended to publish.
Fix it: Rewrite the record from scratch in a plain text editor rather than patching the broken one, then paste the clean version into DNS. Retyping avoids carrying over whatever invisible character caused the fault the first time.
Takes effect: Same TTL rule as a duplicate record. Note the exact time you saved the change so a retest a few minutes later is not mistaken for a failed fix.
The record is published at the wrong name
What it means: DMARC is read from a specific DNS name, and a policy published at the wrong one is invisible to the domain actually sending mail.
A record at _dmarc.mail.yourdomain.com does nothing for mail sent from yourdomain.com itself. RFC 9989's DNS tree walk changed how a receiver climbs from a subdomain toward the organizational domain when no record exists at the exact sending name, which shifts where some policies now get picked up compared with the older lookup rule.
Confirm it: Identify the exact domain in the visible From header from the bounce, then query _dmarc at that precise name. If nothing answers there but something answers one level up, the record and the sending domain are not aligned.
Fix it: Publish the record at _dmarc. plus the exact sending domain. If subdomains send mail under their own policy, add an sp= tag to the organizational record or a dedicated record at that subdomain's own _dmarc name.
Takes effect: Standard TTL propagation, same as the other two branches above.
DNS itself will not answer
What it means: This is a smaller share of cases, but a real one. A dig or nslookup query that returns SERVFAIL or times out with no answer at all is not a syntax problem; it is the zone failing to resolve.
A DNSSEC signing error at the parent zone, a lapsed or mismatched registrar configuration, or a nameserver outage can all produce this, and a receiving server that cannot resolve the name at all may log it the same way it logs a discarded duplicate.
Confirm it: Query the domain's nameservers directly rather than a public resolver, and check whether DNSSEC validation is enabled and correctly signed if your registrar offers it.
Fix it: This one usually sits with the registrar or DNS host rather than the record itself. Open a support case with the exact SERVFAIL output attached.
Takes effect: Resolver problems can take longer to clear than a plain TXT edit, since a broken DNSSEC chain has to be corrected and signed again rather than cached again.
None of these match: escalate it
A domain that publishes one clean record at the right name can still bounce off one specific receiving system while every other provider delivers it without complaint.
When your own lookup is clean across every check above, the fault is most likely something in how that one receiver evaluated the record, not something in the record.
What to hand the receiving admin
The complete, unedited bounce text, not a paraphrase of it
The exact domain from the visible
FromheaderYour
dig +short TXT _dmarc.yourdomain.comoutput, timestampedConfirmation of how many DMARC records exist at that name
Whether the same message delivered cleanly to any other provider
A Microsoft Community Hub thread on this exact error carries a useful lesson in what actually got it resolved: the poster's own record had one invisible character, a trailing period, and it took another contributor pointing at the raw record text, not the bounce, to spot it.
The thread has run since 2018 with replies as recent as 2024, including one from a Microsoft MVP confirming the trailing dot as the fix.
Confirm the fix actually worked
Checking too early is the most common reason a real fix looks like it failed. Google Workspace's own DMARC setup guidance states that administrators should allow 48 hours after SPF and DKIM changes before adding or editing DMARC, and the same patience applies to a retest after fixing a broken record.
Change made | Typical wait before retest | Why |
|---|---|---|
Deleted a duplicate record | 5 minutes to 24 hours | Governed by the TXT record's own TTL |
Rewrote a malformed record | 5 minutes to 24 hours | Same TTL rule, resolvers must expire the old cached answer |
Moved the record to the correct name | Up to 24 hours | New name has no cached answer yet, old name may still return stale data |
Fixed a DNSSEC or resolver fault | Hours to a few days | Depends on signing the zone again and propagation across the parent zone |
Check the authentication header
A passing header after the wait window is the clearest confirmation available. dmarc=permerror in that same header, appearing again after the TTL has clearly expired, means the record is still not resolving the way you expect.
Recheck the record itself
Run the same dig query one more time. One record, correct syntax, correct name, answering without SERVFAIL: that is a clean read in every branch this bounce can come from.
What stops most of this before it starts
Three of the four branches above trace back to the same habit: DMARC handled as a one time DNS edit, made by hand, in a panel nobody revisits.
TrueEmailer configures SPF, DKIM and DMARC together on the sending domains it manages at setup, instead of leaving each record to be added separately by whoever happens to be in the DNS panel that week.
That removes the duplicate record, the syntax fault and the wrong DNS name as ways a domain sending through it can end up here.
It does not touch the fourth branch: a DNSSEC or resolver fault sits with the domain's registrar no matter which platform sends the mail.
Related error codes
This bounce is easy to confuse with its neighbors. 550 5.7.26 and 550 5.7.1 fire when a message was evaluated and failed alignment, a different problem from a policy the server could not read at all.
550 5.7.509 is Microsoft's own reject wording for a domain with an enforced policy and no passing alignment. 554 5.7.13 is a similar permanent policy rejection some providers return with different phrasing. 451 4.7.5, the temporary sibling of this exact code, means the same evaluation failed, but the receiver is asking for a retry rather than closing the door.
For the two most common of those neighbors, five separate causes sit behind a 550 5.7.1 reputation or authorization bounce, and a 550 5.4.1 rejection usually points at something on the recipient's own mailbox rather than your domain at all.
Both sit inside the wider set of 550 permanent failure codes that this one is part of.
FAQs
What does 554 5.7.5 permanent error evaluating DMARC policy mean?
The receiving server could not successfully read or apply the sending domain's DMARC policy record. It is a record problem, not proof that your message itself failed authentication.
Can SPF or DKIM alignment cause this, or is it always the record?
Almost always the record. A message that fails SPF or DKIM alignment usually returns a different code, 550 5.7.1 or 550 5.7.26, because the server did manage to evaluate the policy and then reject on alignment. 554 5.7.5 means evaluation itself broke first.
Should I lower my policy to p=none to fix it?
Only as a temporary measure while you fix the underlying record, and only if you understand what it gives up: p=none stops enforcement entirely, so a spoofed message using your domain would no longer be blocked by DMARC while that setting is in place.
Can one bad tag break the entire record?
Usually not the way people assume. A malformed p= tag next to a valid rua address is meant to degrade to p=none rather than block mail outright, per the DMARC specification. A hard block from one tag fault points at how that specific receiver implemented the rule, not at a universal outcome.
Does this bounce mean someone is spoofing my domain?
No, and this is worth saying directly because the fear is common. This code fires when a receiver cannot read the policy record at all, before it ever gets to evaluating whether a specific message is legitimate or forged.
How long until mail flows again after I fix it?
Usually within the TXT record's TTL, often well under an hour, though a full 24 hours is normal if the TTL was set high before the fix. A DNSSEC or resolver fault can take longer, since it depends on signing the zone again rather than simple cache expiry.
Before you say the fix worked
One clean record, at the right name, answering without a second entry behind it: that is the target state for all four branches above.
The difference between a receiver that skips a broken policy and one that returns 554 5.7.5 is not something a domain owner controls, which is exactly why getting to one clean, correctly named record matters more than guessing at which receiver will be forgiving.
Verified September 10, 2026 against RFC 7489, RFC 9989, RFC 3463, and Google Workspace's published DMARC documentation.