5.7.5 Permanent Error Evaluating DMARC Policy

This is a permanent (5.x.x) SMTP rejection — most often seen in full as 554 5.7.5 Permanent error evaluating DMARC policy — returned by Google's mail servers (Gmail / Google Workspace). Unlike a transient temperror (which produces a 4.x.x defer and resolves on retry), the 5.7.5 enhanced status code signals a permanent condition: the receiver tried to evaluate the DMARC policy for the From header domain and could not arrive at a usable result, so it refused the message outright. The 5.7.5 code borrows RFC 3463's permanent-failure (5.x.x) and security/policy (x.7.x) framework; the specific .7.5 detail code is formally registered by RFC 3463/IANA as "Cryptographic failure" — Google's DMARC-specific reuse of x.7.5 is a provider convention, not an IANA-registered DMARC code.

The key thing to understand: this error is almost always about your own sending domain's DMARC setup, not the recipient's. The receiving server is evaluating your published policy. Most often that means it couldn't read a usable policy out of your DNS record; in some cases it reflects an alignment/authentication failure against your policy.

What causes 5.7.5 Permanent Error Evaluating DMARC Policy?

Per RFC 7489 §6.6.3, a Mail Receiver queries _dmarc.<your-domain> for a TXT record and then filters it. The spec is explicit: "If the remaining set contains multiple records or no records, policy discovery terminates and DMARC processing is not applied to this message." When the receiver cannot turn your DNS into a usable policy, Google reports this as a permanent error. Common triggers:

• Duplicate DMARC records. Two or more TXT records exist at _dmarc.example.com. DMARC does not merge them or pick the stricter one — per §6.6.3, multiple records means no policy is applied. This frequently happens after a migration or when two teams each publish a record.
• Missing or out-of-order required tags. The record must begin with v=DMARC1, and per Google Workspace's DMARC guidance "the v and p tags must be listed first" (other tags may follow in any order). A record whose v= value is not exactly DMARC1 is ignored (RFC 7489 §6.6.3; see also the record format in §6.3); a record with no valid p= tag has no policy to apply.
• Syntax errors in the TXT record. Commas or colons used where semicolons are required, stray quotation marks splitting the value, misspelled or unsupported tags, malformed rua/ruf URIs, or smart-quotes copied from a doc (curly “v=DMARC1” instead of v=DMARC1).
• Record published at the wrong name. It must live at _dmarc.example.com, not at the bare domain or a different label.
• SPF/DKIM alignment failures against an enforcing policy. When SPF and DKIM don't align with your From domain and your policy is quarantine/reject, the message fails DMARC. Google more commonly reports that case as 550 5.7.26, but 554 5.7.5 can also surface on authentication/alignment problems — so don't assume the cause is purely a syntax issue without checking alignment too.

The 5.7.5 "evaluating" wording points most cleanly at the policy being unreadable (the DNS-record problems above), which is why fixing the record is the first thing to check. If the record is clean, investigate SPF/DKIM alignment next.

How do I fix 5.7.5 Permanent Error Evaluating DMARC Policy?

1. Inspect what DNS actually returns. Query the record directly so you see every TXT entry, including duplicates: bash dig +short TXT _dmarc.example.com If more than one v=DMARC1 string comes back, that is your problem.
2. Publish exactly one DMARC record. Merge the tags you need into a single TXT record and delete the rest. A minimal, valid record: v=DMARC1; p=none; rua=mailto:dmarc@example.com Start at p=none (monitor mode) so you collect aggregate reports without affecting delivery, then tighten to quarantine/reject once SPF and DKIM are aligned.
3. Validate the syntax. Confirm v=DMARC1 is first, p= is present and is one of none, quarantine, or reject, tags are separated by semicolons (not commas/colons), and there are no curly quotes or trailing junk.
4. Confirm the record name. It must be the _dmarc subdomain of the exact From domain.
5. Check SPF and DKIM alignment. If the record is well-formed but mail still fails (often reported as 550 5.7.26), confirm SPF and DKIM authenticate and align with your From domain.
6. Wait for propagation, then re-test. DNS/TTL changes can take time to propagate. Re-run the dig command and resend.

If you authenticate from your own domain through Courier, make sure SPF and DKIM are also in place so that once DMARC parses correctly, your mail passes alignment rather than failing the policy.