SMTP for Yahoo: The Settings Take a Minute, the Sender Requirements Do Not

Yahoo publishes its outgoing mail settings on one help page, and the whole configuration is six lines long. Server smtp.mail.yahoo.com, port 465 or 587, SSL required, authentication required, the full email address as the username, and a generated app password rather than the account password (https://help.yahoo.com/kb/SLN4075.html, read 16 August 2026).

That takes a minute. The part worth more of your attention runs in the other direction, because for a B2B sender Yahoo matters far more as a place mail arrives than as a place mail leaves from, and what Yahoo asks of arriving mail is published, specific, and deliberately missing one number that Google publishes.

The settings, exactly as Yahoo states them

The same Yahoo help page covers incoming and outgoing together, which is the normal shape for a mail client setup pane.

Incoming is imap.mail.yahoo.com on port 993 with SSL required. Outgoing is smtp.mail.yahoo.com on port 465 or 587, with SSL required and authentication required. The login is the full address in the form name@domain.com, and where a password would go, Yahoo's page links to its app password generator rather than telling you to type the one you sign in with.

Two of those values cause almost all of the trouble.

The username field is the first. Yahoo's page says the full email address, domain included. A setup screen labelled "username" invites a local part, and a local part produces an authentication failure that reads exactly like a wrong password.

The port is the second, and it deserves its own section because the answer is not the same everywhere.

Port 465 and port 587, and why the advice contradicts itself

Yahoo lists both ports and does not rank them. Anyone reading a second provider's documentation immediately after will find that the two providers disagree.

Both ports are specified. RFC 6409, which carries the standards designation STD 72, splits message submission away from message relay: "Message relay is unaffected, and continues to use SMTP over port 25. When conforming to this document, message submission uses the protocol specified here, normally over port 587." RFC 8314, published January 2018, then added the implicit-TLS ports as standards-track ports and went further than that, stating that the specification "now recommends the use of Implicit TLS for POP, IMAP, SMTP Submission, and all other protocols used between an MUA and an MSP", with the submissions service on default port 465.

So the standards track recommends 465 in preference to opening in the clear on 587 and upgrading with STARTTLS. Microsoft's guidance for its own endpoint points the opposite way, and says why: "If your device or application recommends or defaults to TCP port 465, it doesn't support the required versions of TLS for client SMTP submission" (https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365). Both of those are current and both are correct on their own surface. Microsoft is describing what a 465 default implies about the software connecting to Exchange Online, not making a claim about the port in general.

The resolution is that the port belongs to the endpoint rather than to a general rule. For Yahoo, both ports are published and either works, and the setting that has to agree with your choice is the encryption mode: 465 expects TLS from the first byte, and 587 expects a cleartext open followed by STARTTLS. A client set to one against a server expecting the other produces a handshake error or a timeout, which reads as a network fault and is not. Our Gmail SMTP settings and Outlook SMTP setup guides carry the equivalent published values for the other two large consumer surfaces.

App passwords, and the eligibility rule nobody expects

Yahoo requires an app password for any client that does not use its own branded sign-in page, and its help page on the subject is worth reading before you generate one (https://help.yahoo.com/kb/SLN15241.html).

Three details on that page change how you should treat the credential. App passwords "remain active - even if you change your main account password", so rotating your login does not revoke them and the only way to invalidate one is to delete it. There is a browser eligibility condition: Yahoo instructs you to "use a browser that you've used to sign into Yahoo for several days in a row and avoid using Incognito mode", and states plainly that "Customer care can't override this process of determining App Password creation eligibility". And the code is shown once, for a single application.

The practical effect is that an app password is a long-lived credential with no rotation story and a generation path that can simply refuse on a fresh browser profile. That is fine for one mail client on one laptop. It is a poor fit for anything automated, and it is one of several reasons the sending direction of this page is the less interesting one.

Outgoing (SMTP)smtp.mail.yahoo.com

• Port 465 or 587, both published by Yahoo
• SSL required
• Authentication required
• Username is the full email address
• Password is a generated app password

Incoming (IMAP)imap.mail.yahoo.com

• Port 993
• SSL required
• Two-way sync, so the mailbox stays on the server
• Same address and app password as the outgoing side
• A separate protocol with its own failure modes

The direction that decides whether your mail arrives

Yahoo runs a sender hub, and its Sender Requirements and Recommendations page is the document that actually governs B2B outbound reaching Yahoo mailboxes (https://senders.yahooinc.com/best-practices/, read 16 August 2026). It opens with a dated note: "Beginning in February 2024, enforcement of the following sending standards will take effect."

The page splits into two tiers, in the same shape Google uses.

For all senders, Yahoo asks you to authenticate mail with SPF or DKIM at a minimum, keep the spam complaint rate below 0.3%, hold a valid forward and reverse DNS record for your sending IPs, and comply with RFCs 5321 and 5322.

For bulk senders, the list grows. Both SPF and DKIM rather than either. A valid DMARC policy with at least p=none, and Yahoo's wording is that "DMARC must pass", with relaxed alignment acceptable and the From header domain aligned with either the SPF domain or the DKIM domain. A functioning list-unsubscribe header supporting one-click unsubscribe, where Yahoo highly recommends the POST method defined in RFC 8058 and accepts the mailto method. A visible unsubscribe link in the body. Unsubscribes honoured within two days. And the same 0.3% complaint ceiling.

None of that is unusual. The interesting part is what Yahoo declines to tell you.

The threshold Yahoo will not publish

Google defines its own bulk tier numerically. Its sender guidelines FAQ states that "A bulk sender is any email sender that sends close to 5,000 messages or more to personal Gmail accounts within a 24-hour period", and adds that "Messages sent from the same primary domain count toward the 5,000 limit" (https://support.google.com/mail/answer/14229414, verified 16 August 2026).

Yahoo's own sender FAQ answers the same question and refuses the number. It classifies a bulk sender as an email sender "sending a significant volume of mail", then adds the sentence that settles it: "We will not specify a volume threshold." The same answer does say how a sender is identified, stating that for the purposes of enforcement a sender "is viewed at the authenticated domain or From header domain level" (https://senders.yahooinc.com/faqs/, read 16 August 2026).

That combination is the most useful sentence on Yahoo's site for anyone planning outbound. There is no volume you can stay under to be certain the bulk requirements do not apply to you, and the unit being judged is your domain. The only planning posture that survives it is to meet the bulk tier from the first send, which costs a DMARC record and a working unsubscribe header, and removes the question entirely.

Meet the bulk tier from the first send

• ✓Yes: SPF and DKIM both published for the sending domain, not one of the two
• ✓Yes: A DMARC record of at least p=none, with the From domain aligned to the SPF or DKIM domain
• ✓Yes: A list-unsubscribe header supporting one-click unsubscribe, with the RFC 8058 POST method preferred
• ✓Yes: A visible unsubscribe link in the body, and unsubscribes honoured within two days
• ✓Yes: Valid forward and reverse DNS for every sending IP
• ✓Yes: Complaint rate held below the 0.3% ceiling Yahoo publishes
• ✕No: Assuming a low send volume puts you outside the bulk tier

Yahoo endorses the architecture, in its own words

Further down the same page, under its recommendations, Yahoo writes: "Don't send bulk/marketing email from the same IPs you use to send user mail, transactional mail, alerts, etc. Each IP and DKIM domain has a reputation, which can impact the delivery of your email."

That is a receiving provider describing the separation that outbound programmes build anyway. Prospecting mail and the mail your business depends on should not share a reputation, because the two carry very different complaint profiles and the cheaper one to lose is the prospecting. The concept sits in our sending domain entry, and the build order is in our cold email infrastructure guide.

Why a yahoo.com address is a poor place to send outbound from

Everything above assumes you are sending from a domain you control. Sending prospecting mail from a yahoo.com mailbox is a different proposition, and the reason is checkable in about ten seconds with a DNS lookup.

A TXT query for _dmarc.yahoo.com on 16 August 2026 returns:

v=DMARC1; p=reject; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;

A query for _dmarc.aol.com returns a byte-identical policy. A p=reject policy at 100% means any message carrying a From header at that domain which fails DMARC is to be rejected by the receiver, and it is Yahoo's record rather than yours. Sending as you@yahoo.com through Yahoo's own submission endpoint aligns and passes. Pointing any other sending platform at that From address does not, and cannot be made to.

The wider point survives the specific record. A consumer mailbox address puts your outbound identity on a domain whose authentication, reputation and policy belong to somebody else, and gives you no route to build domain history of your own. The mailbox provider is doing exactly what it should. The setup is simply the wrong shape for a programme that needs its own standing with receivers.

1. Step 1Separate the direction

   A failure to submit is an SMTP settings or credential problem. Mail that submits and then lands in spam is a sender-requirements problem, and none of the settings above will move it.

2. Step 2Check the credential type

   Yahoo requires an app password for clients that do not use its branded sign-in, and app passwords survive an account password change.

3. Step 3Match the port to the encryption mode

   465 opens encrypted, 587 opens in the clear and upgrades with STARTTLS. Yahoo publishes both.

4. Step 4Check the published sender requirements

   SPF and DKIM, a DMARC policy that passes with aligned From, one-click unsubscribe, valid forward and reverse DNS, complaints under 0.3%.

5. Step 5Check the domain, not the mailbox

   Yahoo enforces at the authenticated domain or From header domain level, so the unit being judged is the domain in your From line.

The short version

Yahoo's outgoing settings are smtp.mail.yahoo.com on port 465 or 587 with SSL and authentication, the full address as the username, and an app password. That configuration is documented, stable and rarely the thing anyone is stuck on for long.

The sender requirements are where Yahoo actually decides your outcome, they have been enforced since February 2024, and Yahoo has said in writing that it will not publish the volume line above which the stricter tier applies. Meeting the bulk tier from the start is the only version of this that does not require guessing. For the rest of the stack, our SPF, DKIM and DMARC guide covers the records themselves, and our email sending limits by provider breakdown holds the per-provider ceilings so this page does not repeat them.

RevenueFlow runs cold email and LinkedIn outreach for B2B companies on separate sending infrastructure we provision and warm ourselves, on generic sending domains that are never the client's own, with one message per campaign and no bump sequences or thread replies. If you would rather not build and maintain that layer, prepay a single qualified meeting and judge the output before committing to anything larger.

Provider settings and requirements verified against the vendors' own published pages as of 16 August 2026. Provider policies change; verify current requirements with the provider before relying on them.