SMTP error code · temporary failure (4xx)
SMTP error 421 4.7.0: connection deferred or rate limited, try again later
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 16, 2026
421 4.7.0 is a temporary deferral, not a permanent rejection: the receiving server (usually Gmail) is throttling mail from your IP because of low reputation, an unusual volume spike, or missing authentication. Your mail server queues and retries automatically, but deferrals that outlast the retry window (typically two to five days) become permanent bounces. Treat it as a warning.
421 4.7.0 at a glance | |
|---|---|
| Code | 421 4.7.0 |
| Class | Temporary (4xx): the message is deferred and the sender retries |
| Category | Rate limiting |
| Side at fault | Sender |
| Auth-related | Yes (SPF/DKIM/DMARC) |
What the bounce actually says
The exact wording varies by provider. These are the documented strings, verbatim. Match yours to pin down which variant you hit.
Gmail — unusual rate of unsolicited mail (production bounce)
421 4.7.0 Our system has detected an unusual rate of unsolicited mail originating from your IP address. To protect our users from spam, mail sent from your IP address has been temporarily rate limited.Source: smtpfieldmanual.com
Gmail (Google Workspace) — very low IP reputation
421 4.7.0 This message is suspicious due to the very low reputation of the sending IP address. To protect our users from spam, email sent from your IP address has been temporarily rate limited.Source: knowledge.workspace.google.com
Gmail (Google Workspace) — 421 4.7.26, rate limited because unauthenticated (sibling code)
421 4.7.0 This email has been rate limited because it is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM. Authentication results: DKIM = did not pass SPF [domain-name] with ip: [ip-address] = did not pass. To resolve this issue, go to Email sender guidelines.Source: knowledge.workspace.google.com
Yahoo Mail — volume or complaint deferral (production bounce)
421 4.7.0 [TSS04] Messages from 0.0.0.0 temporarily deferred due to unexpected volume or user complaintsSource: smtpfieldmanual.com
Why you're seeing 421 4.7.0
421 4.7.0 combines two standard codes: 421 is RFC 5321's "service not available, closing transmission channel," and 4.7.0 is RFC 3463's transient security-or-policy status. Together they mean the receiving server chose not to accept your mail right now, almost always because something about your sending IP or domain looks risky at this moment. Gmail issues most of the 421 4.7.0 deferrals you'll see in the wild, and its documented variants name the triggers: an unusual spike of unsolicited-looking mail from your IP or very low IP or domain reputation. Mail arriving without SPF or DKIM draws the same throttle under Gmail's closely related sibling codes (421 4.7.26 through 421 4.7.40) rather than 4.7.0 itself. The connection closes, your server queues the message and retries on its normal schedule, and if the underlying cause clears, the mail lands late instead of bouncing. If it doesn't clear, the deferrals harden into permanent failures once your queue gives up.
Likely causes, ranked
| Likely cause | What's happening |
|---|---|
| Your IP's spam reputation just dropped | The most common trigger, and the one Gmail's classic wording describes: an unusual rate of mail the receiver classifies as unsolicited. A large cold-outreach blast, a purchased or stale list, spam-trap hits, or a burst of recipient complaints will all move an IP's reputation fast, and the throttle follows within hours. |
| You're sending faster than the receiver allows | Mailbox providers cap connections and messages per IP per hour, and the cap scales with sending history. A brand-new IP with no history hits the ceiling at very low volume, which is why unwarmed IPs see `421 4.7.0` on their first serious send. |
| Your mail is unauthenticated, so it gets throttled first | Since Gmail's 2024 sender requirements, mail with no passing SPF or DKIM is explicitly rate limited before it's rejected. Gmail's sibling codes `421 4.7.26` through `421 4.7.40` say so outright (unauthenticated mail, SPF or DKIM failures, a From domain that doesn't align with what was authenticated, and a missing DMARC policy each get their own code). The throttle behaves exactly like 421 4.7.0's. |
| A compromised account or device shares your egress IP | A hijacked mailbox, a malware-infected workstation, or a misconfigured device relaying through your network sends spam from the same public IP as your legitimate mail. Receivers throttle the IP, and everyone in the office bounces together. |
| You're on a shared IP with a bad neighbor | On shared hosting or a shared ESP pool, the IP's reputation is collective. Someone else's bad campaign can put every sender on the IP behind the same throttle: your logs look clean, but the deferral is real. |
How to fix 421 4.7.0
Check the sending IP's reputation
Pull the connecting IP from your mail server's logs (the address the receiving server actually saw) and run it through the free IP reputation checker below. Then run the sending domain through the domain reputation checker at /tools/domain-reputation: Gmail's variants throttle on either one.
Run the check now
Enter the sending domain and the check runs instantly on the next page. Free, no signup.
Let the retry queue work: don't force resends
A 4xx deferral means your server is already retrying on an escalating schedule. Flushing the queue or resending manually just delivers a bigger burst to a server that's throttling you for volume, which deepens the block. Slow down and let the retries clear.
Cut your sending rate to the affected provider
Set per-destination rate and concurrent-connection limits in your MTA or ESP and drop volume to the deferring provider. Halving it is a reasonable first move. If the IP is new, treat this as a warm-up: start low and ramp over weeks, not hours.
Authenticate everything that sends as your domain
Gmail rate-limits unauthenticated mail by policy, and consistent SPF, DKIM, and DMARC passes are how an IP builds the history that raises its limits. Verify all three in one pass with the free checkers at /tools/spf, /tools/dkim, and /tools/dmarc.
Find the source of the bad traffic
If you didn't change your sending, something else on your IP did: audit for compromised mailboxes, infected machines, and open relays behind the same egress address. Check the public blocklists with the free checker at /tools/blocklist-checker, and watch your IP and domain reputation trend in Google Postmaster Tools.
If deferrals persist, pause, fix, and re-warm
Queued mail expires after roughly two to five days (server-dependent) and then bounces permanently. If you're still deferred after a day, pause bulk sends entirely, fix the root cause, then resume at low volume and ramp back up as the deferrals stop.
Related free tools: Domain reputation · Blocklist checker · Email security score
Authentication is the fix, not a workaround
Every path out of 421 4.7.0 runs through the same three DNS records: SPF, DKIM, and DMARC. Mailbox providers no longer treat them as best practice; they're the entry ticket, and a domain that drifts out of alignment starts bouncing again without anyone changing a thing on your side.
The durable fix is enforcement: publish correct records, watch the DMARC reports for senders you missed, and move the domain to p=reject so receivers drop spoofed mail instead of bouncing yours.
Enforce it — don't just monitor it
Palisade's AI agent takes domains all the way to enforcement: hosted SPF, DKIM, DMARC, and MTA-STS records, DMARC reports monitored continuously, and policies advanced to p=reject automatically. Your first domain is free, and the full product is open for 15 days, no card.
Free 15-day trial · No credit card · Your own domain free forever (NFR)
Why it matters for MSPs
Throttling becomes a fleet problem the moment clients share infrastructure. One compromised mailbox at one tenant (or one line-of-business app blasting invoices) drags down the reputation of the egress IP every client behind that firewall sends from, and the ticket queue fills with 421 4.7.0 under a dozen different client names. Palisade hosts and manages the SPF, DKIM, and DMARC records for every client domain, surfaces the rogue sending source in the DMARC reports before Gmail's throttle turns into a block, and walks each domain to p=reject automatically. It plugs into ConnectWise, HaloPSA, and Autotask so the fix lands in your existing workflow, and your own MSP domain is a free NFR domain you can prove it on first.