23 Sep 20264 minutes read
Waseem OsmanDMARC PractitionerTemperror vs. Permerror: What Each One Actually Means
Temperror overview:
- Temperror means a transient DNS issue, not a broken record.
- Permerror means the record is invalid and won’t resolve on retry.
- The Authentication-Results header confirms which one you’re dealing with.
- A flip to permerror, or recurrence across many messages, means escalate.
- A genuine temperror generally traces back to the DNS: timeouts, SERVFAIL, transient failures.
A temperror doesn’t mean your SPF or DKIM record is broken. A temperror means the verifier hit a transient, generally DNS-related, problem while running the check, not that the published record itself is misconfigured. A later retry can succeed without any change to your DNS.
Treating a temperror as a misconfiguration wastes time on a problem that doesn’t exist.
Enterprise teams managing dozens of domains run into this constantly: an alert fires, email is deferred, and someone has to decide in the moment whether to wait it out or start pulling DNS records. Getting that call wrong costs time your security team doesn’t have to spare.
This is an operational guide for CIOs, CISOs, and email administrators who need a reliable way to tell a genuine temperror apart from an authentication failure.
Before triaging a specific event, confirm your baseline. Sendmarc’s free domain checker validates your published records in seconds.
If you’re at risk of impersonation, one of our experts will be in touch to assist.
What Temperror Actually Means
Temperror is a formally defined result, not a general label for any email that wasn’t delivered. RFC 7208, Section 2.6.6, defines it for SPF: the verifier encountered a transient error, generally DNS while performing the check, and a later retry may succeed without further DNS operator action.
RFC 6376, Section 3.9, defines the equivalent output for DKIM’s own verification process: DKIM evaluation ends in one of three states, and TEMPFAIL is “a temporary, recoverable error such as a DNS query timeout.”
In both cases, the authentication check itself failed to complete. The verifier did not reach a pass, a fail, or any other definitive result. It couldn’t finish the DNS lookup, so it reported a temperror and left the door open for a retry.
Temperror vs. Permerror: The Distinction That Matters
RFC 7208, Section 2.6.7, defines permerror separately: the domain’s published records could not be evaluated, an error condition that requires intervention to resolve.
This is the misconfiguration case. A syntactically invalid SPF record, a record that exceeds the 10 DNS lookup limit or a malformed DKIM record produces permerror, not temperror. Permerror doesn’t resolve itself on retry. The record has to be fixed.
Temperror and permerror are easy to conflate. Both mean the SPF or DKIM check didn’t come back clean. Both happen while the verifier is consulting a DNS-published record. But only permerror means that the record itself is incorrect.
The practical difference is what happens next. Temperror generally surfaces as a deferred message. Permerror is a definitive result: the record itself is broken; no retry will change that.
The most useful diagnostic question your team can ask isn’t whether the authentication check failed, but whether it found something wrong. The Authentication-Results header on the message answers that question directly: spf=temperror or dkim=temperror means the check wasn’t completed. spf=permerror or dkim=permerror means it found a broken record.
Common Causes of a Genuine Temperror
A temperror typically traces back to the DNS layer, not the record’s content.
Typical causes include:
- A DNS timeout
- A SERVFAIL response
- A transient resolution failure
None of these involve the record being wrong, which is why the sending server sees a 4xx SMTP error rather than a hard rejection.
Decision Rules for Escalation
Across all three tiers, the SMTP-level signal typically looks the same: a 4xx SMTP error.
Immediate escalation:
- The result flips from temperror to permerror
- Temperror recurring across many messages from the same domain
Standard monitoring:
- An isolated temperror
- No recent DNS or infrastructure changes
Log and close:
- The result changes to pass on retry
- No recurrence across other domains
How Sendmarc Helps
Sendmarc gives email administrators and security teams centralized visibility into SPF and DKIM evaluation results across every managed domain, so the distinction between a genuine temperror and a permerror doesn’t depend on manually parsing DMARC aggregate reports domain by domain.
When an authentication result comes back as temperror alongside a 4xx SMTP error, your team needs to know whether it’s an isolated, self-resolving DNS issue or whether a follow-up check on the same domain shows permerror instead, which means the record itself needs fixing. Sendmarc surfaces that pattern across your domains without requiring manual per-domain DNS checks or report-by-report comparison, reducing the investigation burden on stretched security and IT teams.
For security and compliance teams, the audit trail built into Sendmarc’s DMARC Management Platform supports the documentation requirements that authentication investigations need to produce.
See how centralized authentication visibility fits into your existing SPF and DKIM monitoring workflow. Explore our DMARC Management Platform to review how domain-level authentication results, audit trails, and multi-domain visibility work together across your environment.
