4.7.26Mail rate-limited for missing SPF/DKIM authentication (Gmail)

Gmail uses registry pattern X.7.26 ("Multiple authentication checks failed") specifically when mail has no passing SPF or DKIM result; code 4.7.26 maps that pattern onto a transient class after the receiving system rejected or rate-limited the message for more than one failed authentication check. In this catalog, mechanical IANA confirmation for X.7.26 applies only to the class-5 variant (5.7.26, Associated Basic Status Code 550); the concrete class-4 form has no such registry confirmation here. Existence and meaning therefore rest solely on exact, corpus-collected production evidence (the Gmail 421 4.7.26 response below). The status reports a transient authentication shortfall on this attempt, not a permanently invalid address and not a mailbox condition.

RFC 7372 registers X.7.26 specifically for a multiple-authentication-failure condition: a message failed more than one message-authentication check, contrary to local policy, without naming which mechanisms failed. RFC 3463 (Section 3.8) defines the general X.7 "Security or Policy Status" subject class but does not itself enumerate detail code 26; the later registration carries an Associated Basic Status Code of 550, confirmed in this catalog only for class 5 (5.7.26). Concrete code 4.7.26 (class 4) applies that same pattern as a transient failure: in the accepted example, Gmail reports the message as unauthenticated because neither SPF nor DKIM passed, and rate-limits it rather than rejecting it outright. It appears here on exact corpus evidence, not on an IANA registry confirmation for this class.

The leading digit 4 denotes a persistent transient failure: at the moment of this attempt, Gmail is rate-limiting the message because it lacks a passing SPF or DKIM result, but the condition clears once the sender's domain authenticates correctly. Do not conflate this with 5.7.26, where the same "multiple authentication checks failed" pattern appears as a permanent failure.

Class

Temporary failure

Retry

Controlled retry

Suppression

Check the full context

Retrying without changing anything will not help: fix SPF and/or DKIM for the sending domain first, confirm the records have propagated and that outgoing mail actually carries a passing signature or SPF result, then retry with backoff and an attempt limit. Stop retrying once messages start passing authentication and delivering, or once the limit is exhausted; do not keep resending the same unauthenticated stream expecting a different result.

Do not suppress or remove the recipient address based on 4.7.26 alone: the condition is attached to the sender's own authentication setup, not to the recipient's mailbox or address validity. Suppression decisions should follow independent, per-recipient signals (hard bounces, permanent codes), not this sender-side authentication gap.

• The sending domain has no SPF record, or the SPF record does not include the sending infrastructure's IP address, so SPF fails or returns none/softfail instead of pass.
• DKIM is not configured, the signing key does not match the published DNS selector record, or the message was modified in transit (for example by a forwarding step or relay) so the DKIM signature no longer verifies.
• In the accepted Gmail example, the response explicitly requires both SPF and DKIM to be checked and reports that neither passed — documented behavior of Google's February 2024 sender authentication requirements for bulk senders, not a general definition of code 4.7.26 across providers.

1. Inspect the raw SMTP response and confirm the enhanced code is exactly 4.7.26, and that the basic reply is in the 4xx class (421 in the accepted example).
2. Pull the message's Authentication-Results header (or an equivalent DMARC/DKIM/SPF report) for the specific send and confirm which mechanism failed — SPF, DKIM, or both, as in the accepted example.
3. Check the sending domain's published SPF record and DKIM selector against the infrastructure that actually sent the message, including any third-party ESP or relay in the path.
4. After correcting the DNS records, send a fresh test message and confirm the Authentication-Results header shows a pass before resuming full-volume sending.