What causes 'Permanent Error Evaluating DMARC Policy' bounce message?
Updated on 9 Oct 2026: We clarified DMARC reporting errors and added public DNS checks for permanent policy evaluation bounces.
A "Permanent Error Evaluating DMARC Policy" bounce means the receiving system stopped delivery during DMARC processing and treated the condition as permanent. Start with the sender domain's public DMARC DNS answer. Check for multiple DMARC policy records, v=DMARC1 outside the first position, invalid policy syntax, a DNSSEC or resolver failure, or a receiver using this wording for a message that actually failed DMARC.
Do not assume this is the same as "rejected due to DMARC policy," but do not assume the wording proves a record parsing error either. A normal DMARC rejection means the receiver found a policy and the message failed the required domain match checks. A DMARC permerror means evaluation hit an unrecoverable error. Some gateways use less precise bounce text, so the full response and authentication results matter.
The practical first step is to inspect the sender domain's _dmarc TXT answer, correct confirmed defects, publish one policy record at each lookup name, and then watch real authentication results through DMARC monitoring. Suped is our DMARC platform. It parses the record, groups authentication sources, and surfaces issues that need a DNS or sender configuration change.
What the bounce means
The phrase appears in a non-delivery report (NDR) with an SMTP status such as 554 5.7.5. The 554 reply tells the sending system that delivery failed permanently. The IANA status code registry defines 5.7.5 as "cryptographic failure," not a DMARC-specific condition. Receivers use enhanced status codes inconsistently, so the accompanying DMARC text, remote host, and full bounce provide the useful context.
A sender often sees the mailbox provider's brand in the bounce, but the exact SMTP text can come from a downstream receiving gateway. The fix can sit in the sender's DNS or authentication setup, while a clean result limited to one receiving gateway can point to that gateway's local rule. Check the full bounce, final recipient domain, and remote MX host before assigning the cause.
DMARC processing starts with the domain in the visible From header. The receiver discovers the applicable policy in DNS, evaluates SPF and DKIM results against that domain, and then applies its handling decision. The bounce can occur during DNS lookup or record parsing, but some gateways also use it after a DMARC failure. A valid DKIM signature helps only when it passes verification and its signing domain has the required domain match.
Key distinction
The exact bounce phrase is a clue, not a standardized DMARC result. Confirm the result before changing DNS.
- A policy rejection follows a readable policy and a DMARC failure, subject to the receiver's local decision.
- A DMARC permerror is an unrecoverable evaluation error, such as an improperly formatted policy record.
- A local gateway can present either condition with the same 554 5.7.5 wording.
Typical permanent error
554 5.7.5 Permanent Error Evaluating DMARC Policy
Related temporary form
451 4.7.5 Temporary Error Evaluating DMARC Policy
Most common causes
Start with the DMARC record and DNS response, not the message body, campaign content, or blocklist (blacklist) status. A domain reputation issue has different symptoms. If DNS is clean, move to the message's DMARC result and the receiver's local handling.
A record can look readable and still be unusable. DNS control panels can hide separate resource records, add literal quotation marks, or publish a value at the wrong host. Verify the public DNS answer and authoritative nameservers, not only the value shown in the DNS host interface.
- More than one DMARC policy TXT record is returned at the same _dmarc name.
- The record is published at the root, at the wrong subdomain, or with v=DMARC1 outside the first tag position or with the wrong capitalization in DMARC1.
- A report destination without mailto: or with doubled dots in its domain is a reporting defect. Repair it, but do not treat it as proof of a delivery-policy error.
- Extra punctuation, literal smart quotes, commas in place of semicolons, or pasted line breaks damage the record syntax. Commas are valid between reporting URIs, while semicolons separate tags.
- An invalid value such as p=block can leave older and current receivers with different fallback behavior.
- DNS returns SERVFAIL, times out, or fails DNSSEC validation. A temporary reply is common, but DMARC leaves DNS error handling to the receiver.
- The message has dmarc=fail under an enforced policy, and the gateway exposes that result with imprecise 554 5.7.5 wording.
Six-step flowchart for troubleshooting a 554 5.7.5 DMARC policy evaluation error, including DNS validation and delivery retesting.
DMARC records to check first
The most useful evidence is the actual TXT response published at _dmarc. Current and older DMARC implementations do not handle every invalid detail in the same way, so treat these patterns as diagnostic leads rather than guaranteed one-to-one causes.
Policy and reporting defects
- Two policy TXT records are published at one lookup name.
- The v=DMARC1 tag is missing, is not first, or has the wrong capitalization in DMARC1.
- A report address is listed without mailto:.
- A report destination contains bad punctuation or doubled dots.
Valid patterns
- One policy TXT record exists at the exact lookup name.
- The record starts with v=DMARC1, with the case-sensitive value DMARC1.
- Aggregate report destinations use complete mailto: URIs.
- The p value is none, quarantine, or reject.
A malformed reporting destination does not automatically invalidate an otherwise usable policy. RFC 9989 requires receivers to ignore unknown tags and unsupported reporting URI schemes. Repair the reporting address, then confirm whether the rejecting gateway recorded a policy error or an authentication failure.
Do not confuse one TXT resource record split into several quoted character strings with several TXT resource records. Receivers concatenate the strings inside one record before DMARC parsing. Separate records that each begin with v=DMARC1 create the duplicate-policy problem.
Policy defects and unusable reporting destinationsdns
v=DMARC1; p=reject; rua=reports@example.com v=DMARC1; p=reject; rua=mailto:reports@dmarc..example.com v=DMARC1; p=block; rua=mailto:reports@example.com p=reject; v=DMARC1; rua=mailto:reports@example.com
Valid monitoring recorddns
v=DMARC1; p=none; rua=mailto:reports@example.com
|
|
|
|---|---|---|
Two v=DMARC1 answers | Duplicate policy | Merge into one |
Version tag not first | Record ignored | Move v=DMARC1 first |
No mailto scheme | Invalid email reporting destination | Add mailto: for reports; diagnose the bounce separately |
SERVFAIL or DNSSEC error | DNS failure | Repair DNS |
dmarc=fail | Authentication failure or domain mismatch | Check SPF/DKIM results and domain matching |
Fast triage signals for a DMARC evaluation error.
Verify the public DMARC DNS answer
Replace example.com in the TXT queries with the exact domain in the visible From address. For the NS query, use the DNS zone that hosts it, often the parent domain for a sending subdomain. Replace ns1.example.net with an authoritative nameserver for that zone. Repeat the TXT lookup against each authoritative server and another recursive resolver.
Inspect DMARC answers and authoritative DNSbash
dig TXT _dmarc.example.com +noall +comments +answer +authority dig NS example.com +short dig @ns1.example.net TXT _dmarc.example.com +norecurse +noall +comments +answer +authority
Count separate TXT resource records that start with v=DMARC1, not quoted strings within one record. An authoritative NOERROR response with no TXT answer and an SOA record indicates no matching TXT data; NXDOMAIN indicates a nonexistent DNS name. Neither response alone proves a permanent DMARC error, because an inherited policy still needs checking. SERVFAIL requires investigation of DNS resolution or DNSSEC.
DNS propagation depends on caching. A resolver can retain the previous answer until its cached TTL expires. RFC 2308 also defines negative caching for missing names and record types. Adding a record therefore does not immediately clear every cached missing-record answer. Lowering the TTL after the change does not shorten the lifetime of data already cached under the previous TTL.
How to troubleshoot it
Use a narrow troubleshooting path. First check which policy public DNS exposes for the visible From domain. Then determine whether the message produced dmarc=permerror, dmarc=fail, or a different receiver-side condition.
- Save the full SMTP response, recipient domain, timestamp, message ID, sending IP, and remote MX name.
- Read the visible From header and use its domain as the starting point for DMARC policy discovery.
- Query TXT at _dmarc for that domain, then check the applicable parent policy when no valid direct record exists.
- Compare authoritative answers with independent public resolvers, and check for duplicate policy records, SERVFAIL, truncation, or DNSSEC validation errors.
- Use a Suped's DMARC checker to validate tag order, syntax, policy values, and reporting URIs.
- Inspect Authentication-Results added by the receiving system on a delivered test message. A dmarc=permerror result supports an evaluation defect, while dmarc=fail requires checking SPF/DKIM authentication and domain matching. Results from another receiver do not prove what the rejecting gateway saw; request its logs if the evidence conflicts.
- Send a fresh message through the same sending path to the affected recipient after authoritative and sampled recursive answers show the repaired record. A permanent 5xx rejection is not normally queued for automatic retry.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
If the record parses correctly and the error continues, check DNS behavior. Look for split-horizon DNS, stale data at one authoritative provider, a CNAME at the wrong name, DNSSEC validation failure, or TXT content accidentally created as separate resource records by the DNS interface. A clean answer from one recursive resolver does not prove every receiver saw the same answer.
Also compare the visible From domain with the domain whose record was queried. Under RFC 9989, a receiver checks the Author Domain first and then uses a DNS Tree Walk when it finds no valid direct policy. A parent or public suffix policy can therefore apply to a subdomain, and the sp or np tag can change the requested handling.
Temporary DNS trouble often produces a 4xx reply such as 451 4.7.5, but this is receiver policy rather than a guaranteed mapping. RFC 9989 allows a receiver to deliver despite the DNS error or defer with a temporary reply. Persistent 5xx results still justify checking permanent DNS and policy defects first.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
How RFC 9989 affects policy errors
RFC 9989 is the current Standards Track DMARC specification. It obsoletes RFC 7489 and RFC 9091, while the DNS record version remains v=DMARC1. This matters during troubleshooting because older and current receivers can discover or handle a damaged policy differently.
- Policy discovery now uses a DNS Tree Walk. The receiver checks the Author Domain and can move up the DNS hierarchy, with an eight-query limit.
- If one lookup name returns multiple DMARC policy records, RFC 9989 discards them at that name and can continue discovery higher in the tree.
- If p is missing or invalid, or sp or np is invalid, but rua has a valid reporting URI, the receiver processes the record as p=none. Without that valid URI, it applies no DMARC processing.
- The pct tag is historic. The t tag carries the testing function with values y or n, and np provides policy for non-existent subdomains.
- Publishing one explicit, valid policy record for every domain used in the visible From header reduces mixed-version receiver differences.
Why this changes the diagnosis
A duplicate or malformed record is still a defect that should be repaired, but current standards do not require every such defect to produce this bounce. Confirm what policy the receiver found and whether the recorded result was permerror or fail.
How to fix the record
The repair is usually small, but it needs care because a broken DMARC record affects every receiver that checks the same DNS name. Correct syntax and DNS publication first. Keep an established quarantine or reject policy when repairing syntax alone. Use p=none for a new deployment while confirming that aggregate reports arrive and legitimate senders produce a passing SPF or DKIM domain match.
Safe repair sequence
- Remove duplicate policy records and retain the intended policy in one record. Combine report destinations inside its rua tag.
- Place v=DMARC1 first, use a valid policy value, and repair reporting URIs.
- Verify legitimate sending sources in aggregate reports before increasing enforcement.
- Use Suped alerts to catch later DNS or authentication changes.
Suped is our DMARC and email authentication platform. For this bounce, the useful workflow is to inspect the published record, separate duplicate or syntax issues from sender failures, review the affected sources, follow the DNS remediation steps, and receive an alert if the result changes again.
For teams that do not want to edit DNS for every policy change, Suped's Hosted DMARC workflow keeps later policy changes in one managed configuration after the required DNS setup is published.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
When a valid DMARC record still produces bounces
A clean DMARC record does not end every investigation. The next check depends on whether the evidence shows dmarc=fail, a DNS error, or a rejection limited to one receiving gateway.
SPF and DKIM can both pass while DMARC fails if neither authenticated domain has the required match with the visible From domain. Compare the envelope sender (Return-Path or smtp.mailfrom) and the DKIM signing domain (d= or header.d) with header.from. DMARC needs only one passing method with the required domain match. aspf=s and adkim=s require an exact domain match for their respective methods; relaxed alignment is the default and compares organizational domains. See the authentication requirements.
- A failed authorization check for an external rua destination affects report delivery, not normal DMARC message evaluation.
- A DNS Tree Walk can find a parent or public suffix policy when the Author Domain has no valid direct record.
- Oversized responses, broken DNSSEC signatures, or inconsistent authoritative servers can create resolver-specific failures.
- Forwarding can break SPF, while message changes can break DKIM. If neither method retains the required domain match, DMARC fails.
- If only one recipient gateway rejects after DNS and authentication checks pass elsewhere, collect the transcript and ask that recipient's mail administrator to inspect its rule.
If you are creating a new record, use Suped's record generator and keep the record simple. The monitoring example below requests reports without asking for quarantine or rejection.
Monitoring example for a new deploymentdns
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Views from the trenches
Best practices
Check the sender's public DMARC TXT record first, before changing mail routing or content.
Keep one DMARC policy record per lookup name and validate report URIs after DNS changes.
Compare permanent and temporary SMTP codes with DNS evidence before deciding on a repair.
Common pitfalls
Assuming every 554 DMARC error means the message failed authentication under a reject policy.
Leaving duplicate DMARC policy records at the same lookup name after a mail platform migration.
Publishing report addresses without mailto and assuming the reporting defect proves the bounce.
Expert tips
Trace the final receiving MX host in the full bounce because the mailbox brand can mislead.
Repair doubled dots in report destination domains, then diagnose message evaluation separately.
Monitor aggregate reports after repair and retest delivery through the affected sending path.
Marketer view
Marketer from Email Geeks says the wording is distinct from a normal DMARC rejection and usually points to a policy record that the receiver cannot evaluate.
2024-08-13 - Email Geeks
Marketer view
Marketer from Email Geeks says missing mailto prefixes in aggregate report destinations are a common malformed-record pattern behind this class of bounce.
2024-08-13 - Email Geeks
These community observations describe receiver behavior, not a guaranteed mapping of a DNS defect to this bounce. An invalid reporting destination alone does not prove that DMARC message evaluation failed.
Frequently asked questions
No. The wording can describe an unrecoverable evaluation error or a gateway's local presentation of a DMARC failure. Check the policy DNS response and Authentication-Results before changing the policy.
A rua value needs a valid URI, commonly mailto: followed by the reporting address. An invalid reporting destination does not automatically invalidate the policy or require rejection. Repair it for report delivery, then use the full bounce and receiver logs to establish the cause.
No. A 451 reply is temporary and often follows a DNS timeout, SERVFAIL response, or receiver resolver problem. RFC 9989 leaves DNS error handling to the receiver, so compare the DNS evidence instead of relying only on the code.
Lowering the policy does not repair duplicate records, malformed syntax, or DNS failure. If the message has a real DMARC failure, p=none changes the requested handling during monitoring, but SPF or DKIM domain matching still needs correction. Keep an existing enforced policy when the repair only concerns DNS syntax.
Publish one DMARC policy TXT resource record at each required _dmarc name. One TXT resource record can contain several quoted character strings because receivers concatenate them before DMARC parsing. Separate policy records are the problem.
