Introduction
Yahoo TSS04 is a temporary deferral. It belongs to the family Yahoo calls "TS* errors": a 4xx reply that means Yahoo has paused acceptance from your sending IP because of complaints, spam-like content, poor IP or subnet reputation, or unusual traffic. It is a reputation signal, not an authentication fault, so changing SPF, DKIM or DMARC records will not clear it.
That distinction matters for anyone who supports other people's email. An MSP that treats every Yahoo bounce as a DNS problem will spend hours on records that are already correct, while the real cause (a volume spike, a complaint-heavy campaign or a compromised mailbox) keeps going. This guide sets out what Yahoo itself documents about its bounce codes, separates the ones you fix in DNS from the ones you cannot, and gives a triage routine for a client portfolio. The DMARC guide covers the protocol background.
Key takeaways
- TSS04 sits in Yahoo's "TS*" family of temporary deferrals. Yahoo's documented causes are complaints, objectionable content, poor IP or subnet reputation and unusual traffic patterns.
- Yahoo does not publish a separate meaning for each individual code such as TSS04, TSS05 or PH01. It documents families (TS and PH) and categories of error.
- Authentication failures (SPF, DKIM, DMARC) are fixed in DNS and on sending platforms. TS* deferrals and complaint or volume problems are not.
- A 4xx reply means retry later; a 5xx reply means do not retry that message.
- DMARC aggregate reports show every source sending as a domain, which helps find unexpected volume and spoofing, both of which affect how Yahoo judges the domain.
What does Yahoo TSS04 mean?
TSS04 means Yahoo is temporarily deferring mail from your server. Yahoo's SMTP error codes page groups these under "Message temporarily deferred (eg: TS* Errors)" and says: "This is a temporary error and your mail server may automatically re-try sending the email at a later time." The message was not rejected, and your server will normally keep trying.
Yahoo lists four possible reasons for a TS* deferral:
- Emails from your mail server are generating substantial complaints.
- The message contained objectionable content.
- The IP (or its subnet) has a poor reputation.
- Yahoo is seeing unusual traffic patterns from your mail servers.
None of these is a DNS record. They describe how recipients react to your mail and how your sending behaves. Yahoo's advice is to follow its Sender Requirements & Recommendations, review outgoing content, and, for servers that do not primarily send bulk mail, check outbound queues for spammers abusing the server.
Does Yahoo document TSS05, TSS09, TSS11 or PH01 individually?
No. Yahoo's error codes page uses the wildcards "TS" and "PH" and does not define individual codes by name. You will see specific codes in bounce text and in forum posts, but any per-code meaning beyond the family is not something Yahoo publishes. Treat a TS-prefixed code as a temporary deferral and a PH-prefixed code as a content block, and diagnose from there.
Which Yahoo errors are authentication failures and which are reputation?
Yahoo's documentation splits cleanly into two groups. Authentication failures, where SPF, DKIM or DMARC did not pass, are fixed by correcting DNS records and sending platform settings. Reputation and rate problems, including TS* deferrals, complaints, unsolicited volume and content blocks, are fixed by changing sending behaviour. DNS changes cannot fix the second group.
The table summarises each category on Yahoo's error codes page. The "Temporary or permanent" column follows Yahoo's own wording or SMTP class; where Yahoo does not state it, read the first digit of the reply.
| Yahoo code or category | Temporary or permanent | What Yahoo says it means | What to check | Fixable in DNS? |
|---|---|---|---|---|
| TS* (includes TSS04) | Temporary (Yahoo calls it a temporary error) | Deferral due to complaints, objectionable content, poor IP or subnet reputation, or unusual traffic | Recent volume spikes, complaint data, shared IP neighbours, outbound queues for abuse | No |
| 421 or 451 | Temporary | A temporary problem blocking delivery; causes include unusual traffic, complaints, busy servers and temporary authentication errors | Whether it clears on retry; if it persists, the requirements below | Sometimes |
| 553 or 554 | Permanent | Invalid address, failed DMARC or DKIM checks for your domain, policy-violating content, suspicious behaviour, or a Spamhaus listing | The exact reason text; do not retry the message | Only the DMARC/DKIM cause |
| Authentication failures | Depends on the reply class | Failed SPF, DKIM or DMARC; bulk senders need SPF, DKIM and a DMARC policy | Authentication-Results header, alignment, DKIM signing domain |
Yes |
| Unresolvable RFC5321 or RFC5322 From domain | 451 (timeout or SERVFAIL) or 554 (permanent) | The domain after the @ in MAIL FROM or header From does not look valid; Yahoo checks with an SOA query | SOA plus A or MX records for the domain and any sending subdomain | Yes |
| PH* | Not stated by Yahoo; read the reply class | Content Yahoo will not accept for policy reasons, such as malware, phishing or links to them | Outbound queues and message content | No |
| Excessive user complaints | Not stated | Too many Yahoo users marking mail as spam | Opt-in practices, Complaint Feedback Loop data, shared IP use | No |
| Excessive unsolicited messages | Not stated | High volume from a single IP, possibly a new IP not warmed up gradually | Sending ramp, list consent, content changes | No |
| Excessive unknown recipients | Not stated | Many invalid recipients, which can indicate an open relay or proxy | Relay security, bounce handling, outbound queues | No |
| Recipient does not exist | Permanent (do not retry) | The Yahoo account does not exist | Remove the address from the list | No |
| Other policy errors (550, 554) | Permanent | Null MX, oversized headers, date out of range, undecodable header, forbidden characters in an address | The specific header or address named | Null MX only |
The one row that combines both worlds is 553/554: Yahoo lists failed DMARC or DKIM as one cause among several. Read the full reason text before deciding which world you are in.
What does a Yahoo bounce look like?
A Yahoo bounce contains an SMTP reply code, often a bracketed or prefixed Yahoo code, and the responding Yahoo server. Yahoo's error codes page shows this sample of a permanent failure from a mailer-daemon:
554 delivery error: dd This user doesn't have a yahoo.com account (testing123@yahoo.com) [-5] - mta123.mail.mud.yahoo.comFor a deferral you will usually not get a bounce message at all at first. The reply sits in your mail server or email service provider's delivery log while the server retries. A TSS04 code tends to surface when the retry period runs out, or when an email service provider reports the deferral in its dashboard. When you open a ticket with Yahoo, the error page asks for the diagnostic codes from your logs, so capture the full reply line rather than a summary.
How do Yahoo's bulk sender requirements relate to these codes?
Yahoo's requirements are the baseline its filters measure you against, and several error categories point straight back to them. Bulk senders must use SPF and DKIM, publish a DMARC policy of at least p=none that passes, and keep spam complaints below 0.3%. Failing the authentication parts can produce authentication errors; complaint and volume problems produce deferrals.
Yahoo's best practices page sets two tiers:
- All senders: implement SPF or DKIM at a minimum, keep the spam rate below 0.3%, have valid forward and reverse DNS for sending IPs, and comply with RFC 5321 and RFC 5322.
- Bulk senders: implement both SPF and DKIM, publish "a valid DMARC policy with at least p=none" where "DMARC must pass", align the From domain with SPF or DKIM ("relaxed alignment is acceptable"), support one-click unsubscribe for marketing and subscribed messages, honour unsubscribes within 2 days, and keep the spam rate below 0.3%.
Yahoo's FAQ says enforcement began in February 2024 and that it "will not specify a volume threshold" for bulk senders. It also says non-compliant mail "may be sent to the spam folder or rejected", and, on complaint rates, that "we may defer mail from domains with a high complaint rate." That last sentence is the link between the requirements and TS* deferrals. The rules apply to all domains and consumer email brands hosted by Yahoo Mail, which includes AOL.
A minimal DMARC record that meets the bulk requirement looks like this:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"Yahoo calls the rua tag "strongly recommended to allow monitoring during initial setup." Google and Yahoo sender requirements compares both providers' rules side by side. Gmail returns its own, differently formatted codes, which that article also lists.
How do you fix a Yahoo authentication failure?
Fix it the same way as any DMARC failure: confirm SPF passes for the envelope domain, confirm DKIM signs with your own domain, and make sure at least one of them aligns with the From domain. Send a test to a Yahoo mailbox you control and read the Authentication-Results header to see which check failed.
Work through these checks in order:
- DMARC record present and valid for the From domain, at
p=noneor stronger. - SPF passes for the sending IP, with the record inside the 10 DNS lookup limit (see SPF too many DNS lookups).
- DKIM signs with your domain. Yahoo's FAQ requires "a DKIM key length of 1024 bits or greater" and recommends 2048 bits.
- Alignment. If SPF passes for a provider's bounce domain and DKIM passes for the provider's own domain, DMARC still fails. Why DMARC fails when SPF passes explains the pattern.
- Forwarders and mailing lists. Yahoo suggests that mailing lists put the list address in From and the original sender in Reply-To, and recommends considering ARC for forwarded mail.
- Domain resolvability. Yahoo checks the envelope and header From domains with an SOA query, so a sending subdomain needs an SOA record in addition to its A or MX record.
The approach mirrors the one in our Microsoft 550 5.7.515 guide, because the underlying requirement (aligned SPF or DKIM, plus a DMARC record) is the same at Outlook.com and Yahoo.
What should you do about a TSS04 deferral?
Stop looking at DNS and look at sending behaviour. Yahoo's documented causes for TS* deferrals are complaints, content, IP or subnet reputation, and unusual traffic, so the fix is to find which one changed. Let your server keep retrying, slow the send if volume jumped, and investigate before pushing the same campaign harder.
A practical sequence:
- Check what changed. A new campaign, a new list import, a migration to a new IP or provider, or a sudden spike in volume. Yahoo's FAQ advises spreading out volume rather than sending in sudden spikes.
- Check complaints. Yahoo's FAQ points senders to its Complaint Feedback Loop to monitor complaints, and recommends opting out users who previously marked mail as spam.
- Check the IP. On a shared IP, other senders' traffic can affect you. Yahoo suggests asking your provider about dedicated IPs if complaints persist.
- Check for abuse. For a business mail server or tenant that does not send bulk mail, a TS* deferral can be the first sign that a compromised account is sending spam. Yahoo's advice for non-bulk servers is to examine outbound queues for this.
- Separate streams. Yahoo's FAQ recommends sending different content types, such as transactional and promotional, through separate IPs and streams.
- Escalate only if it persists. Yahoo says to submit a support request if you see the same error consistently over an extended period, with diagnostic codes from your logs. Its contact page offers a ticket for problems delivering to AOL or Yahoo mailboxes.
How should an MSP triage Yahoo bounces across clients?
Classify first, fix second. An MSP's first job with a Yahoo bounce is to decide whether it is an authentication problem the MSP owns in DNS, or a sending behaviour problem the client or its email service provider owns. A short, repeatable routine keeps the two from being confused across many client domains.
- Capture the full reply. Ask the client or the platform for the complete SMTP line, not a screenshot of a summary.
- Read the first digit. 4xx means deferred and retrying; 5xx means that message failed for good.
- Map the Yahoo code to a family. TS is a reputation deferral, PH is content, and authentication or DMARC wording is a DNS task. Use the table above.
- For authentication cases, check the domain's records and a test header, then confirm in DMARC aggregate reports which platform is failing.
- **For TS* and complaint cases,** ask what changed in sending, check for compromised accounts, and route marketing issues to whoever runs the client's email service provider.
- Record the outcome against the client, so a repeat deferral next month starts with history rather than from zero.
Explaining the split to the client helps too. "Your records are correct; Yahoo is slowing mail because of how recipients reacted to the last campaign" is a different conversation from "a platform is sending as your domain without authentication."
How do DMARC aggregate reports help with Yahoo bounces?
Aggregate reports show every IP that sent mail using a client's domain, with message counts and SPF, DKIM and DMARC results per source. That makes them the quickest way to confirm an authentication fix and to spot sending you did not know about. They do not show complaints, content or Yahoo's deferral decisions.
Three uses matter here:
- Finding the failing platform. When a Yahoo bounce cites DMARC or DKIM, the reports show which source fails alignment, so you fix the right platform. DMARC aggregate reports explained shows how to read them.
- Spotting unusual volume. A source that suddenly sends far more than usual may be a new campaign or a compromised account, both of which can lead to deferrals.
- Finding spoofing. Yahoo's FAQ says spoofed emails "will count towards the mail we look at for enforcement", and that a domain with a spoofing problem "should be implementing a DMARC enforcement policy (p=quarantine or p=reject) regardless."
That last point is a strong reason to move client domains beyond p=none. Under RFC 9989, the path is p=none, then p=quarantine, then p=reject, once reports show every legitimate source aligned. How to move from monitoring to enforcement safely covers the steps. For MSPs handling many domains, a multi-tenant platform such as DMARC AI for MSPs processes aggregate reports per client domain, so a failing or unexpected source is visible without opening XML by hand.
FAQ
Is Yahoo TSS04 a hard bounce?
No. Yahoo describes TS* errors as temporary, and your mail server may retry later. It only becomes a bounce if retries run out. Repeated TSS04 deferrals across days are still a warning: Yahoo's causes include complaints and poor IP reputation, which get worse if you keep sending the same mail.
Will fixing SPF, DKIM or DMARC stop TSS04 errors?
Usually not. Yahoo's documented causes for TS deferrals are complaints, objectionable content, IP or subnet reputation and unusual traffic, none of which are DNS settings. Correct authentication remains a Yahoo requirement and is worth checking, but the fix for a TS deferral is in sending behaviour.
Does Yahoo have a bulk sender threshold like Google?
No. Yahoo's FAQ says it "will not specify a volume threshold" and defines a bulk sender as one sending a significant volume of mail. In practice, treat any client sending marketing or automated mail to Yahoo or AOL addresses as subject to the bulk requirements: SPF, DKIM, passing DMARC, one-click unsubscribe and low complaints.
Do Yahoo's rules apply to AOL addresses?
Yes. Yahoo's FAQ states the requirements apply to all domains and consumer email brands hosted by Yahoo Mail, which covers AOL. Yahoo Japan is a separate company and is not covered by these statements. A client deferred at Yahoo will often see the same behaviour at AOL addresses.
Can Yahoo whitelist a client's IP to stop deferrals?
No. Yahoo's FAQ answers this directly: "Yahoo does not have a whitelisting program." It also notes that a support request does not guarantee inbox delivery. The dependable route is fixing the complaint, volume and content causes Yahoo lists, then escalating with diagnostic codes only if deferrals persist.