What 421 4.7.0 Means
The recipient Google Workspace domain has configured an IP whitelist policy through its admin console, and your sending IP isn't on it. Gmail returns 421 4.7.0 with text like 'IP not in whitelist for RCPT domain, closing connection'. It's transient — your sending server may retry — but persistent failures require the recipient organization to whitelist your IP.
Google Workspace domains (any custom domain MX'd to Google) where the admin has enabled inbound gateway / IP whitelisting. Not seen at consumer @gmail.com addresses.
The recipient's Google Workspace admin enabled an inbound mail gateway or IP whitelist (Google Workspace Admin → Apps → Gmail → Spam, Phishing → Inbound Gateway) and your sending IP isn't listed. This is most common at security-conscious enterprises that route inbound through ProofPoint, Mimecast, or another gateway service.
How to Fix 421 4.7.0
- 1
Confirm this is a Google Workspace domain
Use the MX Lookup tool at coldrelay.com/tools/mx-lookup against the recipient domain. If the MX points to a Google host (aspmx.l.google.com, alt1.aspmx.l.google.com, etc.), it's Workspace. 421 4.7.0 is Workspace-specific behavior.
- 2
Retry — most 421 4.7.0 events are policy-flap
Some 421 4.7.0 events resolve on retry because the recipient's whitelist policy is transient or rule-evaluation-order dependent. Your sending platform's natural retry queue will catch these.
- 3
If persistent — request whitelisting from the recipient
If 421 4.7.0 persists across multiple retry cycles for one recipient domain, that domain has hard whitelisting and your IP isn't on it. The recipient's IT admin needs to add your sending IP to their inbound gateway list. This is a recipient-action fix, not a sender-action fix.
- 4
Provide the prospect organization your IP details
When asking for whitelisting, send the prospect's IT team your sending IP, hostname, and authentication setup. ColdRelay dashboard shows your dedicated IPs under Servers → IPs. Sharing these lets the recipient organization add an inbound gateway rule for your specific sender.
- 5
Consider whether the prospect is worth the friction
Cold email to organizations with strict IP allowlisting has a low success rate without prior relationship. If the prospect has IP allowlisting, they likely also have content filtering — your unsolicited cold email may not be a good fit. Evaluate prospect-by-prospect.
References
421 4.7.0 in the Cold Email Context
421 4.7.0 from a specific recipient domain is a 'this org has hardened security' signal. The recipient is doing IP allowlisting for a reason — they're trying to stop unsolicited mail. Cold email to these recipients has a structurally low ROI. ColdRelay's dedicated IPs make whitelisting easy IF you have a relationship with the prospect organization (their IT can allowlist your specific IP), but you can't bypass the allowlist with infrastructure alone. The infrastructure-side improvement: dedicated IPs are easier to allowlist than shared IPs (which the recipient won't accept because they don't know whose traffic they'd be allowing in).
Frequently Asked Questions
Why does Google use 421 instead of 550 for IP allowlisting?
421 lets the sender retry. Google's reasoning: the policy is recipient-configurable, so the receiving organization might whitelist your IP at any time and a future retry would succeed. 5xx would close that path.
Can I get on an allowlist proactively?
Only via direct contact with the recipient organization. Their IT admin manually adds IPs. There's no Google-side global allowlist that cold senders can join.
Does this affect my IP reputation?
No. 421 4.7.0 is policy-based, not reputation-based. Your IP reputation for other recipients (Gmail consumers, other Workspace domains without strict allowlists) is unaffected.
If I switch IPs, will my new IP be whitelisted?
No — whitelists are per-IP. A new IP will hit the same 421 4.7.0 against the same recipient until that recipient adds the new IP to their list.