421 4.7.0: Temporarily refused: reputation, DNS or TLS

At a glance

• Type: temporary failure (class 4, RFC 3463 §2). The sending server keeps the message and retries later (RFC 5321 §4.5.4.1); it bounces only if the problem lasts until the message expires.
• Basic code 421: “Service not available, closing transmission channel” (RFC 5321 §4.2.3).
• Enhanced code 4.7.0: “Other or undefined security status” in the IANA registry (RFC 3463), in the group security or policy status (RFC 3463 §3.8).

A 421 4.7.0 reply means the receiving server turned your mail away for now, for a policy reason, not because the address is bad. Your server will retry, but the deferrals keep coming until you fix what triggered them.

What it means

A 4yz reply is a transient failure: the client should try again later (RFC 5321 §4.2.1). The 421 code also closes the connection. The enhanced code 4.7.0 is the general "security or policy" status of RFC 3463 §3.8. The reason is in the text that follows the code.

Common causes

• The sending IP has no PTR (reverse DNS) record, or the PTR name does not resolve back to the same IP.
• The sending IP or the sending domain has a very low reputation.
• The recipient domain requires TLS and your server connected without it.
• The recipient domain only accepts mail from an allowlist of IP addresses, and yours is not on it.
• The message content or its links look suspicious.
• The connection stayed open too long and expired.

How providers use it

Gmail sends 421 4.7.0 for every cause in the list above. Its SMTP error reference gives a separate reply text for each one. For a missing or mismatched PTR record, Gmail rate limits your mail rather than refusing all of it. The same reputation problems can also come back as a permanent 550 5.7.1, and a missing PTR alone as 550 5.7.25.

Yahoo defers with a plain 421 for similar reasons: unusual traffic, complaints or spam-like content (Yahoo's error codes).

How to fix it

1. Match the text after 4.7.0 to one of the causes above.
2. Reverse DNS: ask whoever controls the IP (your host or ISP) for a PTR record whose hostname resolves back to that IP. Google's sender guidelines require valid forward and reverse DNS for all senders.
3. TLS: turn on STARTTLS for outgoing mail. The same guidelines require TLS.
4. Reputation: make sure SPF or DKIM passes (SPF checker, DKIM checker), mail only people who asked for it, drop addresses that hard bounce, and watch your spam rate in Postmaster Tools.
5. Allowlist: only the recipient's admin can add your IP.
6. Let the queue keep retrying while you fix it. RFC 5321 §4.5.4.1 says retries should be at least 30 minutes apart and the give-up time generally at least 4 to 5 days.

What to do with the address

Keep it. A 4.7.0 deferral says nothing about whether the mailbox exists. The problem is on the sending side.

Related codes

• 421 4.7.28: Unusual sending rate or unsolicited mail: rate limited
• 550 5.7.1: Delivery not authorized: refused for policy reasons
• 550 5.7.25: Reverse DNS (PTR) check failed
• 450 4.2.1: The recipient is receiving mail too fast: try later

See every bounce code in the dictionary.

Many bounces from addresses that do not exist can be avoided: check an address with our free email checker, or clean a whole list before you send.

How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.