A Yahoo 421 4.7.0 [TSS04] reply means Yahoo is temporarily deferring mail from your IP. Yahoo lists complaints, spam-like content, poor IP reputation and unusual traffic patterns as causes. It's a temporary error, so your server keeps the message and retries. The fix is to slow down, send only to people who want your mail, and check your authentication. TSS09 is a different animal: Yahoo returns a permanent 553 5.7.2 saying retrying will not succeed, and it needs a request to Yahoo's sender support.

This guide explains each code and the steps that actually help.

What the Yahoo replies look like

TSS04, as commonly reported by senders (the exact wording and reference number can vary):

421 4.7.0 [TSS04] Messages from 203.0.113.10 temporarily deferred due to
unexpected volume or user complaints - 4.16.55.1;
see https://postmaster.yahooinc.com/error-codes

TSS09, as Yahoo returns it in reply to MAIL FROM:

553 5.7.2 [TSS09] All messages from 203.0.113.10 will be permanently deferred;
Retrying will NOT succeed. See https://postmaster.yahooinc.com/error-codes
Code Class What it means What your server does
421 4.7.0 [TSS04] Temporary Deferred for volume, complaints or reputation Keeps the message, retries
553 5.7.2 [TSS09] Permanent All mail from this IP refused Bounces the message
Other 421 / 451 Temporary A temporary problem Retries
Other 553 / 554 Permanent Bad address, failed DMARC or DKIM, policy, Spamhaus listing Bounces; don't retry

Yahoo's error-code page (https://senders.yahooinc.com/smtp-error-codes/) groups the TS codes under "message temporarily deferred". It names the same causes: complaints, objectionable content or spam-like traits, poor IP reputation and unusual traffic patterns. It doesn't document each TS number separately, so treat the descriptions above as what senders see rather than Yahoo's official definitions.

Why Yahoo defers your mail

TS codes are about reputation and behaviour, not about a missing DNS record. Authentication failures show up as 5xx errors instead. The usual triggers are:

  • A volume jump. Your IP normally sends a few hundred messages a day to Yahoo, and suddenly sends thousands. A campaign to an old list is the classic case.
  • Complaints. Yahoo users clicking "This is spam". Yahoo asks bulk senders to keep complaints low, alongside Gmail. See the Gmail and Yahoo bulk sender requirements.
  • A new or cold IP. No history means no trust yet. Even small volumes can be deferred.
  • Spam-like content or a bad list. Lots of unknown users, spam traps or mail nobody opens.
  • A compromised server or account. Yahoo specifically suggests that senders who don't normally send bulk mail check their outbound queues for abuse.

How to find Yahoo deferrals in your logs

Deferrals are easy to miss, because nothing bounces for days. On a Postfix server, these commands show whether Yahoo is pushing back and how much mail is waiting:

# Count Yahoo TS replies by code
grep -oE '\[TSS[0-9]+\]' /var/log/mail.log | sort | uniq -c

# Deferred messages still in the queue, by recipient domain
postqueue -j | jq -r '.recipients[].address' | awk -F@ '{print $2}' | sort | uniq -c | sort -rn | head

If most of the queue is Yahoo and AOL addresses and the log shows TSS04, you have a Yahoo-specific problem rather than a general one. If Gmail and Outlook are deferring you too, look at your IP's reputation and your list first. A blocklist listing or a bad campaign affects every provider at once.

How to fix 421 4.7.0 [TSS04]

1. Don't fight the retries

Your server already retries 4xx replies. Postfix keeps a deferred message in the queue and tries again on a growing schedule, for up to five days by default (maximal_queue_lifetime). Don't flush the queue repeatedly or push the same mail through another IP. Hammering Yahoo while it's deferring you makes it worse.

2. Slow down to Yahoo

Limit how fast you send to Yahoo-hosted domains, so a backlog drains gently rather than in a burst. In Postfix, a separate transport for Yahoo does this:

# /etc/postfix/master.cf: a copy of the smtp transport for Yahoo
yahoo     unix  -       -       n       -       -       smtp
# /etc/postfix/main.cf
transport_maps = hash:/etc/postfix/transport
yahoo_destination_concurrency_limit = 2
yahoo_destination_rate_delay = 2s
# /etc/postfix/transport (Yahoo and AOL consumer domains; add country domains you see)
yahoo.com      yahoo:
ymail.com      yahoo:
rocketmail.com yahoo:
aol.com        yahoo:

Then run postmap /etc/postfix/transport and systemctl reload postfix. We use the same mechanism to pace a new stream on our own server; the numbers above are a starting point, not a Yahoo rule.

3. Clean up who you're sending to

Stop mailing addresses that hard-bounced. Suppress anyone who complained. Pause sends to people who haven't opened anything in months. If the deferrals started with one campaign, look at where that list came from. Old or purchased lists are the most common cause of complaint spikes.

4. Check authentication anyway

TS codes aren't authentication errors, but a weak setup makes everything worse. Make sure SPF, DKIM and DMARC pass and align with your From domain, and that your IP has a PTR record that matches your HELO name. The why are my emails going to spam checklist covers the rest.

5. Warm up instead of jumping

If the IP is new or has been quiet, follow a schedule. Start small, send to engaged recipients, and grow only while deferrals and complaints stay low. Our IP warm-up guide has the week-by-week version.

What to do about TSS09

TSS09 says retrying will not succeed, and it means it. Because it's a 5xx reply, every message to a Yahoo address from that IP fails straight away instead of waiting in the queue.

  1. Stop sending to Yahoo from that IP. Hold or reroute Yahoo and AOL mail rather than letting it bounce over and over.
  2. Find the cause. Check for a compromised account or script, a recent send to an old or bought list, or a sudden jump in volume. A new IP sending too much too soon can trigger it too.
  3. Set up Yahoo's sender tools. Verify your domain in Yahoo Sender Hub (https://senders.yahooinc.com/) and join the Complaint Feedback Loop, which sends you a report when a Yahoo user marks your mail as spam. Neither lifts a block by itself, but Sender Hub is where the support forms are.
  4. File a Sender Support Request. Include the exact error from your logs, the IP, what you send, roughly how much, and how you collect addresses. Yahoo's own advice for persistent TS errors is a request with the specific codes.
  5. Check for the block without sending mail. Connect to a Yahoo MX, send only EHLO and MAIL FROM, read the reply and disconnect. A TSS09 reply means it's still blocked. No message is ever transmitted.
import smtplib
s = smtplib.SMTP("mta5.am0.yahoodns.net", 25, local_hostname="mail.example.com", timeout=20)
s.ehlo("mail.example.com")
print(s.mail("probe@example.com"))  # (553, b'5.7.2 [TSS09] ...') means still blocked
s.quit()

Run it from the blocked server, since the block is on its IP. Once MAIL FROM is accepted, resume sending to Yahoo slowly.

Shared IPs, dedicated IPs and Yahoo

An IP's reputation is shared by everyone who sends from it. On a shared pool, a deferral can come from someone else's mail. On a dedicated IP, it's all yours, which is cleaner but means you have to warm the IP yourself and keep volume steady. We compare both in shared vs dedicated IPs for email.

If you'd rather not manage this yourself, our pay-as-you-go sending paces warm-up on each day's results, holds the daily limit after a day with too many deferrals, and pauses sending automatically when bounces or complaints spike.