4.7.5 Temporary Error Evaluating DMARC Policy

Most senders see this from Gmail / Google Workspace as the full line:

451 4.7.5 Temporary error evaluating DMARC policy (in reply to end of DATA command)

The 451 is the SMTP reply code and 4.7.5 is the RFC 3463 enhanced status code. Read those two numbers before you touch any DNS record — they tell you exactly what happened.

What does 4.7.5 actually mean?

The leading 4 is the decisive digit. Under RFC 3463, a 4.x.x code is a persistent transient failure: "the message as sent is valid, but persistence of some temporary condition has caused abandonment or delay." The .7.x subject is the security/policy class. RFC 3463 §3.8 defines X.7.5 generically as "Cryptographic failure" — "a transport system otherwise authorized to validate or decrypt a message in transport was unable to do so because necessary information such as a key was not available or such information was invalid." The RFC text never mentions DMARC, SPF, or DKIM by name; Google and other providers have adopted X.7.5 as their de facto text for a stalled DMARC/SPF/DKIM check, but that mapping is a provider convention layered on top of the RFC, not an assignment the RFC itself makes.

Put together, 4.7.5 Temporary error evaluating DMARC policy does not mean your message failed DMARC and was rejected by a p=reject policy. It means the receiver started the DMARC evaluation and could not finish it because something timed out or errored mid-check. This is the SMTP-level expression of a DMARC TempError — the temperror result defined by RFC 7489 (DMARC formally registers the temperror/permerror results in its Authentication-Results registry update, §11.2; §6.6.3 separately covers how DNS lookup errors during policy discovery should be handled). The 4.7.5 / 5.7.5 text is Google's own way of surfacing that result over SMTP, not wording RFC 7489 itself assigns. Either way, the receiver is deferring delivery and expects you (or it) to retry.

This is the temporary twin of the permanent 554 5.7.5 Permanent error evaluating DMARC policy. Same subject code, different class digit (5 = won't resolve on retry). If you got the 451/4 version, retrying often succeeds on its own.

What causes 4.7.5 Temporary error evaluating DMARC policy?

DMARC evaluation requires the receiver to perform several DNS TXT lookups — your _dmarc record, your SPF record (and every include/a/mx it chains to), and the DKIM selector key. A temporary failure in any of those lookups produces a temperror. Common transient causes:

• DNS SERVFAIL or resolver timeout on your domain's authoritative nameservers, or on a third party referenced by an SPF include:.
• Slow or flapping authoritative nameservers — intermittent latency means the lookup sometimes completes and sometimes doesn't, which is why the error comes and goes.
• Truncated TXT responses / UDP-vs-TCP issues — an oversized record that doesn't fit a 512-octet UDP packet can be truncated; a resolver or firewall that mishandles the TCP fallback intermittently fails the lookup.
• DNSSEC validation failures on the TXT lookup (e.g. expired signatures) that surface as SERVFAIL.
• A mid-cutover state — you're migrating DNS, SPF, or DKIM (a common Microsoft 365 / Google Workspace transition symptom) and records are momentarily unresolvable or inconsistent.

Note: a permanently broken record — bad DMARC syntax, an SPF record over the 10-DNS-lookup limit (RFC 7208 §4.6.4), a missing record — typically produces a PermError / 5.7.5, not this temporary code. If 4.7.5 is constant rather than intermittent, treat the underlying lookup as effectively broken and check those too.

How do I fix 4.7.5 Temporary error evaluating DMARC policy?

1. Retry first. Because this is a 4.x.x transient code, a compliant sending MTA will automatically re-queue and retry. Many one-off occurrences clear themselves within minutes once the DNS hiccup passes. Confirm whether the error is a blip or persistent before changing anything.
2. Check your authoritative DNS health. Query your _dmarc.<domain>, SPF, and DKIM records directly against your authoritative nameservers (e.g. dig +trace txt _dmarc.example.com, dig txt example.com, dig txt selector._domainkey.example.com). Look for SERVFAIL, slow responses, or one nameserver answering differently than another.
3. Verify your SPF stays under 10 DNS lookups. include, a, mx, ptr, exists, and redirect each count; ip4/ip6/all do not. Over-budget or deeply nested includes cause timeouts and PermErrors. Flatten or trim unused includes.
4. Keep TXT records small and TCP-friendly. Avoid bloated records that force truncation, and make sure nothing in your network path blocks DNS over TCP (port 53) so the fallback works.
5. Test your authentication records with a DMARC/SPF/DKIM checker or by sending a probe to a tool like mail-tester.com. A valid _dmarc record begins with v=DMARC1; followed by a p= policy tag — but treat syntax checks as ruling out the permanent variant; they won't explain a purely intermittent temperror.
6. If it only happens to one recipient domain and you fail nothing else, the transient condition may be on the receiver's resolver. There is little you can do but retry; check your own DNS is clean and let the queue drain.