421 4.7.26: Rate limited because mail is unauthenticated
421 4.7.26 from Gmail means your message was slowed down because it is not properly authenticated. SPF and DKIM are missing or failing. Today it is a temporary refusal. Left alone it turns into the permanent 5.7.26.
- Bounce type
- Soft bounce (temporary)
- Usually caused on
- Your sending side
- Terlido report label
- Blocked by the provider
What the standard says
RFC 5321 defines 421 as "service not available, closing transmission channel". RFC 7372 defines X.7.26 as "Multiple authentication checks failed": the sender and message could not be tied to the domain by the authentication methods that were tried. Gmail uses the 4.7.26 form to rate limit mail that is unauthenticated instead of blocking it outright.
What the mailbox providers say
- Gmail (421 4.7.26): “This email has been rate limited because it is unauthenticated.” Source
Common causes
- SPF is missing for the sending domain, or the sending service is not listed in it.
- DKIM signing is not turned on, or the DKIM record in DNS does not match the key in use.
- Both checks fail, so the receiver has nothing to trust.
- A new domain that has not yet got any of its DNS records in place.
- A forwarding step or a third-party service that breaks the signature.
- A DNS provider switch where the old SPF and DKIM records were not copied to the new one.
How to fix it
- Publish an SPF record that includes the service that sends your mail.
- Turn on DKIM signing and publish the public key in DNS.
- Add a DMARC record so receivers know your policy, and check that your From domain aligns with the SPF and DKIM domains.
- Wait for the DNS changes to spread, then send a test message and read the headers for pass results.
- Check DNS directly after any provider or nameserver change and confirm that the SPF and DKIM records still exist.
- Do not wait for the permanent 5.7.26 version before you act. Fix authentication while the refusal is still temporary.
Is it a deliverability problem?
This is a sender-side problem and a clear one. Gmail tells you in plain words that the message is unauthenticated. Because the same condition becomes a permanent block in 5.7.26, fixing authentication now protects the whole domain. The rate limit is a mild form of the refusal that follows if nothing changes. Treat it as a deadline. Domains that fix authentication at this stage usually keep their reputation, while domains that ignore it end up fixing it after real blocks.
How Terlido handles it
When a bounce message for this code arrives in a connected mailbox, Terlido reads the status code. An enhanced code that starts with 4 is a soft bounce. In the campaign Reports tab this one is grouped as "Blocked by the provider".
On a soft bounce Terlido logs the event on the lead's activity. The lead is not stopped, and the sequence continues at its next scheduled step.
Check the domain behind the bounce
The free domain checker runs live SPF, DKIM, DMARC, MX and blocklist lookups and explains each result in plain English.
Free tools that help
- SPF checkerInspect a published SPF record and its recursive DNS lookup budget.
- DKIM checkerCheck a specific DKIM selector and explain its published key state.
- DMARC checkerInspect DMARC policy, alignment and report addresses.
Related error codes
- 550 5.7.26: Blocked because the sender is unauthenticated
- 550 5.7.27: Blocked because SPF did not pass
- 550 5.7.23: SPF validation failed
- 421 4.7.0: Temporarily deferred, often for low reputation