Yahoo 421 4.7.0 TSS04: why your mail is deferred and what to do
Yahoo's 421 4.7.0 TSS04 is a temporary deferral tied to volume or complaints, not a permanent block. What Yahoo says, what to check, and how to retry safely.
On this page(8 sections)
A Yahoo reply that starts with 421 4.7.0 [TSS04] means Yahoo has temporarily deferred your mail: it did not reject the message, it asked your server to try again later. Yahoo ties this family of deferrals to unexpected volume, user complaints or a weak sending reputation, so the fix is almost never "retry harder". It is to look at what Yahoo is scoring and give it a better signal.
This guide separates what Yahoo itself documents from what deliverability vendors say about the code, because the two are often blended together.
What does 421 4.7.0 TSS04 actually mean?
It is a temporary failure. The 421 is an SMTP transient reply and the 4.7.0 is an enhanced status code in the "security or policy" class (see RFC 3463). TSS04 is a Yahoo-specific tag, and the text after it usually reads something like this:
421 4.7.0 [TSS04] Messages from 203.0.113.25 temporarily deferred
due to unexpected volume or user complaints - 4.16.55.1;
see https://postmaster.yahooinc.com/error-codes
(203.0.113.25 is a documentation address, not a real sender.) The pattern is a sending IP that Yahoo has chosen to slow down.
What does Yahoo say about it?
Yahoo's SMTP error codes page groups these under "message temporarily deferred" (the TS* family). At the time of writing, it says:
- The error is temporary and your server may retry automatically.
- Follow Yahoo's Sender Requirements and Recommendations.
- Review outgoing messages for potentially objectionable content.
- If you do not mainly send bulk mail, check your outbound queues for abuse.
- If the same error lasts for an extended period, submit a Sender Support Request with the specific error and diagnostic codes from your logs.
Notably, that page describes the family rather than ranking the causes of TSS04 specifically. Anything more precise, such as "it is always complaints", comes from vendors and forum threads, so treat it as a hypothesis to test against your own data.
What are the usual causes?
Treat these as ordered suspects, not facts about every case:
| Suspect | How to check |
|---|---|
| A sudden jump in volume from a new IP or a quiet domain | Compare daily Yahoo volume with the previous two weeks |
| Complaints from Yahoo recipients | Your complaint feedback loop data and Yahoo's Sender Hub |
| Old, purchased or unengaged addresses in the batch | Last-engagement date of the segment that was deferred |
| Missing or mismatched authentication or DNS | SPF, DKIM, DMARC alignment, forward and reverse DNS |
| Other senders on a shared IP | Ask your provider whether the pool is deferred too |
Yahoo's sender best practices set the baseline you are measured against: keep the spam rate below 0.3%, enroll your DKIM domains in the complaint feedback loop, authenticate with SPF and DKIM (bulk senders need both plus a DMARC policy of at least p=none that aligns), keep valid forward and reverse DNS on sending IPs, and for marketing mail support one-click unsubscribe and honor it within two days. Our Gmail and Yahoo requirements guide walks through each one.
What should you do in the first hour?
- Stop adding pressure. Pause or slow only the Yahoo-bound queue. Do not requeue everything at once; every retry that fails looks like more volume.
- Save the evidence. Keep the full SMTP reply, sending IP, From domain, message type (transactional, marketing, one-to-one) and the time of the first deferral.
- Find out which stream is affected. If password resets are deferred but your newsletter is not, the problem is not your newsletter. Separating streams is easier when they use different sending subdomains.
- Check complaints. Look at feedback-loop reports for Yahoo and read what a spam complaint rate really measures.
- Verify DNS and authentication. Confirm SPF and DKIM pass and that the sending IP has matching forward and reverse DNS (why that matters).
- Suppress the obvious. Remove recent complainers, hard bounces and addresses that have not engaged in a long time from the next Yahoo batch.
How should you retry?
Let your queue retry on its own schedule, with backoff and jitter rather than a tight loop. A sensible approach is in our posts on retry and backoff policy and per-provider throttling: give Yahoo its own queue, lower its concurrency and messages per connection, and raise them again only when deferrals stop.
Yahoo also notes that it accepts a limited number of messages per SMTP connection and may end the connection without an error when the limit is reached. You can reconnect right away; this is not the same as a TSS04 deferral.
Keep retrying for a normal window (many systems use a few days) before giving up on a message, and tell the sender what is happening if a person is waiting on it. Do not convert a 421 into a hard bounce or a suppression: the address is fine, the route is slow.
When is it time to contact Yahoo?
Contact Yahoo only after controlled retries have failed for an extended period and your checks are clean. Use the Sender Support Request form and attach the exact reply text, diagnostic code, sending IP and a sample timeline. If you send through a provider, ask the provider to file it, since they hold the IP relationship.
If the cause turns out to be complaints, a request will not fix it. The remedy is a cleaner list, easier unsubscribing and a slow ramp, as in the IP warm-up schedule and list hygiene guides.
How do you prevent the next one?
- Ramp new domains and IPs gradually instead of sending a full list on day one.
- Send only to people who asked for the mail, and remove unengaged addresses on a schedule.
- Make unsubscribing easier than reporting spam, and honor requests quickly.
- Watch deferral rates per provider, not just bounce rates, so you notice a
4xxtrend before users do. - Keep authentication and DNS monitored so a changed record does not turn a slowdown into a block.
Bottom line
421 4.7.0 TSS04 is a slowdown, not a verdict. Pause the Yahoo queue, save the evidence, check complaints, volume and DNS, retry gently with backoff, and escalate to Yahoo only if a clean setup still gets deferred for an extended time. Treat any vendor's specific diagnosis as a hypothesis until your own logs agree.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
