In brief
- A code starting with 4 is temporary, a code starting with 5 is permanent.
- RFC 5321 recommends at least 30 minutes between two attempts, and giving up only after 4 to 5 days.
- At Gmail, 421 4.7.28 signals an unusual rate: stop sending for at least 10 minutes, then slow down.
- If deferrals come back with every campaign, it is no longer an incident: it is a volume or reputation problem to fix.
Deferral or throttling: reading the text
Your sending server retries on its own as long as the refusal is temporary. You only see a failure when the delay expires (often several days later), in the form of a non-delivery message. RFC 5321 gives the rule: an interval of at least 30 minutes between two attempts, and a give-up time of at least 4 to 5 days.
The logs of your sending tool show the deferrals well before the final failure. That is where to read the text, because it says whether waiting will be enough (congestion) or whether you need to change practices (reputation, volume, DNS).
The causes, and how to tell them apart
At Gmail: unusual rate (421 4.7.28)
How to recognize it: The text says “Gmail has detected an unusual rate of email.” Gmail specifies what it is about: the IP, the IP block, the DKIM domain, the SPF domain, the link domain or the Message-ID quota.
What to do:
- Stop sending to Gmail for at least 10 minutes, then resume at a lower rate.
- Follow Gmail's sender guidelines (authentication, one-click unsubscribe above 5,000 messages per day).
- If the refusal comes back, treat it as a block and no longer as throttling: lastingly reduce the volume per mailbox.
At Gmail: IP reputation or suspicious content (421 4.7.0)
How to recognize it: The text says “This message is suspicious due to the very low reputation of the sending IP address” (temporary throttling) or “due to the nature of the content or the links within” (content blocked).
What to do:
- For reputation: improve it by sending less, to engaged recipients, then try again later.
- For content: review the message and its links (shortened links, recent domains, needless attachments).
Missing reverse DNS or suspicious SPF (421 4.7.0, 451 4.7.23 and 4.7.24)
How to recognize it: The text says that the sending IP address has no PTR record, or that the SPF contains suspicious entries.
What to do:
- Have a PTR matching the sending IP created by the owner of the IP (hosting provider or internet service provider), then check with dig -x.
- Simplify the SPF: remove the includes that are no longer used.
DMARC check impossible due to DNS failures (451 4.7.26)
How to recognize it: The text says that Google could not verify DMARC because of temporary DNS failures.
What to do:
- Try again later. If your email is legitimate and the refusal persists, check that the DNS servers of your domain are answering properly, and contact the domain administrator.
TLS required, IP missing from the allowed list
How to recognize it: The text says “TLS required for RCPT domain” or “IP not in whitelist for RCPT domain”. This comes from a setting on the recipient domain.
What to do:
- Enable TLS encryption in the SMTP configuration of your sending tool.
- If the IP must be on an allow list, it is up to the recipient's administrator to add it.
At Yahoo: message deferred for reputation or complaints
How to recognize it: Yahoo groups its deferrals under codes starting with "TS" in the text. The causes cited: recipient complaints, content with spam characteristics, bad IP reputation, unusual traffic.
What to do:
- Review the content and the list, check complaints, slow down.
- If the error lasts a long time, Yahoo asks you to open a sender support request, attaching the error code and the diagnostic codes taken from your logs.
- If the message says the domain of the address cannot be resolved, create the A or MX records and the SOA of the domain.
At Microsoft: temporary restriction (4.7.500 to 4.7.699)
How to recognize it: The text says “Access denied, please try again later.” Microsoft detected suspicious activity and temporarily limits sending to evaluate it.
What to do:
- If the activity is legitimate, the restriction is lifted after a short delay according to Microsoft. Do not force it by resending in bursts.
- If the message contains 4.5.3 (“Too many recipients”), the message exceeds 200 envelope recipients for the same domain: split it into smaller batches.
Check your DNS
Deferrals are read first in the logs of your sending tool. On the DNS side, two checks cover the technical causes.
Read the reverse DNS (PTR) of the sending IP address
dig +short -x 203.0.113.10
Expected result: A hostname. No answer: no PTR. The IP 203.0.113.10 is an example: replace it with the one in the Received header of your message.
Read the SPF record of the sending domain
dig +short TXT yourdomain.com
Expected result: A single line starting with v=spf1. No line: no SPF. Two v=spf1 lines: the SPF is invalid and always fails.
Check your whole domain at once
The free diagnostic reads your SPF and your DMARC and looks for a DKIM signature, with no account. It is the fastest way to find out whether authentication is the problem.
Test my domain nowWhat not to do
- Manually retrying within the minute: you make the throttling you are trying to lift worse.
- Working around the rate by multiplying mailboxes on the same domain or the same IP: Gmail counters cover the IP, the IP block and the domains.
- Turning off the automatic retries of your sending server: it is the one absorbing temporary refusals.
Frequently asked questions
What is the difference between 421 and 451?
Both are temporary. In RFC 5321, 421 indicates that the server is closing the transmission channel (shutdown or unavailability), while 451 signals an action interrupted by a local processing error. In practice, Gmail, Yahoo and Microsoft use both for throttling and deferrals.
How long should I wait before retrying?
RFC 5321 indicates an interval of at least 30 minutes between two attempts and giving up after at least 4 to 5 days. For a Gmail 421 4.7.28, wait at least 10 minutes before resuming at a reduced rate.
Is a 421 or a 451 serious?
In isolation, no: it often reflects congestion. Repeated with every campaign, it warns of rate limiting or a reputation problem that will turn into permanent refusals if nothing changes.
What is greylisting?
It is a technique used by some servers that temporarily refuse the first attempt from an unknown sender and accept the next one. It can only be detected by a 4xx followed by a success on retry; no action is needed if your server retries.
Official sources
- Google: Gmail SMTP errors and fixes
- Google: email sender guidelines for Gmail
- Yahoo: error codes for senders
- Microsoft: non-delivery reports and SMTP errors in Exchange Online
- RFC 5321: Simple Mail Transfer Protocol
Messages and fixes taken from the official documentation on October 21, 2026. Providers sometimes change their wording: if there is a discrepancy, the official page prevails.
Read next
Set up authentication at your mailbox provider
Other errors
Prospect without damaging your domain
Fluenzr sends from your own mailbox, warms up its sending history and monitors its reputation.
Start my 14-day trial