Enhanced Status Code 4.7.26: Multiple Authentication Checks Failed - Temporary
Enhanced Status Code 4.7.26 means “Multiple Authentication Checks Failed - Temporary.” The message failed more than one authentication check and the receiver is deferring rather than rejecting. Both Google and Microsoft use this code to hold unauthenticated mail, and Microsoft applies it specifically to IPv6 senders.
421 4.7.26 Unauthenticated email is rate limited. DKIM or SPF authentication failedWhat does 4.7.26 mean?
Enhanced status code 4.7.26 is the temporary form of a message failing more than one authentication check. Where 5.7.26 rejects, 4.7.26 defers, which usually means the receiver believes the failure could be transient.
Google sends it in two shapes worth telling apart. One says unauthenticated email was rejected because temporary DNS failures prevented authentication, which is genuinely transient: your SPF or DKIM lookup timed out and a retry may well succeed. The other says email is rate limited because it is unauthenticated and DKIM or SPF failed, which is not transient at all, it is a reputation decision dressed as a deferral. The first resolves itself, the second will not.
Microsoft uses 4.7.26 for a rule that catches many senders by surprise: a message sent over IPv6 must pass either SPF or DKIM, with no exceptions and no reputation-based leniency. Mail from the same host over IPv4 is accepted while the IPv6 path is deferred, which produces intermittent delivery that looks random until you notice the correlation with the address family. If you are seeing this from Microsoft, check whether your server prefers IPv6 and whether your SPF record covers your IPv6 addresses.
How 4.7.26 plays out
4.7.26 replyWhere 4.7.26 sits: soft vs hard bounce
| Soft bounce (4xx) | Hard bounce (5xx) | |
|---|---|---|
| Nature | Temporary | Permanent |
| SMTP class | 4xx | 5xx |
| What to do | Let it retry | Suppress the address |
| Recoverable? | Often | No |
| 4.7.26 is | ✓ this code |
What each provider means by 4.7.26
A registered code does not oblige a provider to use it that way, and the large ones diverge. Match the wording in your own bounce, not the definition above.
Common causes of 4.7.26
- Both SPF and DKIM failed or were absent on the message
- A temporary DNS failure prevented the receiver from completing an authentication lookup
- The message was sent over IPv6 without passing SPF or DKIM, which Microsoft rejects outright
- The SPF record does not include the IPv6 addresses the server actually sends from
- DKIM signing is configured for one sending path but not for all of them
- Reputation is low enough that the receiver defers unauthenticated mail rather than accepting it
How to fix 4.7.26
- Determine whether the text names a DNS failure or a rate limit, because only the first is transient
- Publish SPF and DKIM covering every sending path, and confirm both pass on a test message
- Add your IPv6 addresses to SPF, or disable IPv6 sending until they are covered
- Check that your authoritative DNS answers reliably and is not rate limiting the receiver
- Verify DKIM alignment with the From header, not just that a signature exists
- Reduce volume to the affected provider while authentication is being corrected