Server settings
Yahoo publishes the outgoing server as smtp.mail.yahoo.com, listing both 465 and 587 as valid ports, with SSL required and TLS used where available.
Yahoo outgoing server
as Yahoo publishes itThe two differ in when encryption starts. On 465 the connection is encrypted implicitly, from the moment the session opens. Submission on 587, the port defined in RFC 6409, begins in the clear and upgrades through STARTTLS before any credential is sent.
Authentication is required on both ports. Yahoo does not accept unauthenticated submission, so a client that connects without credentials is rejected regardless of which port it used.
Login information
The username is the full Yahoo email address including the domain part, not the account name alone. Addresses on Yahoo's other domains use the same server and the same full-address form.
The password is a generated app password. Yahoo describes these as randomly generated codes that let non-Yahoo email apps access an account when those apps do not use Yahoo's sign-in page, and the code is entered once when the app is configured.
App passwords survive an account password change. Changing the main Yahoo password does not invalidate them, and the only way to revoke one is to delete it from the account security page.
Generate one from the Yahoo Account Security page under external connections. Yahoo advises using a browser already signed in over several consecutive days and avoiding private browsing, because the generation flow can fail otherwise.
What Yahoo SMTP is and is not suitable for
A Yahoo mailbox is provisioned for a person sending personal mail, and its sending limits are sized accordingly. Yahoo does not publish a numeric rate for third-party SMTP submission, so treat any specific figure quoted elsewhere as unverified rather than authoritative.
Application mail does not belong on a personal mailbox. Password resets, receipts and system alerts sent through a consumer account share one credential, one reputation and one set of undocumented limits, and there is no route to per-message delivery status.
Reputation is the constraint that bites first. Mail sent through smtp.mail.yahoo.com is attributed to Yahoo's infrastructure and to the individual mailbox, so a sender gains nothing from their own domain reputation and cannot repair the shared one.
The contrast with purpose-built sending infrastructure is stark. On our own relay, TLS and exact SMTP authentication are mandatory, TCP 2525 is firewall-restricted to the API host, every one-recipient route snapshot is HMAC-signed, and unsigned or replayed requests are rejected. A consumer mailbox cannot make any of those guarantees, because it was never asked to.
George's rule for client work is to send from a domain you verify yourself rather than through a personal consumer account, and he treats the one-minute verification as the thing that keeps deliverability strong. The reasoning is ownership. A verified domain accumulates a reputation that belongs to you and travels with you; a consumer mailbox rents you someone else's, and you have no say in what the other tenants do to it.
He is blunter about the surrounding category error, which is worth stating on a page about a consumer SMTP host: cold infrastructure is not marketing email. Different domains, different mailboxes, different volumes, different deliverability rules. Reaching for a Yahoo mailbox because it is the mail server you already have is how those categories get collapsed, and the collapse is what causes the trouble rather than the hostname.
Authentication and the domain
Passing SMTP authentication is not the same as passing the checks a receiver runs. Authentication proves the client may use the submission server, while SPF, DKIM and DMARC tell the receiving server whether the message is authorised for the domain in the From header.
That second layer is checkable before you send. We built deliverability checks into Nitrosend that verify the SPF, DKIM and DMARC configuration on your domain and report bounce rates back per send, which a consumer mailbox will never do.
Mail sent through a Yahoo account is aligned to Yahoo's domain, not to a custom one. A business sending from its own domain through a consumer Yahoo mailbox creates a DMARC alignment failure, which is exactly what a receiver's policy check is designed to catch.
Yahoo publishes a DMARC reject policy for its own consumer domains. Sending mail with a yahoo.com From address through unrelated infrastructure produces rejection at receivers honouring that policy, which is the intended behaviour rather than a misconfiguration.
Troubleshooting a failed connection
An authentication failure after a working period usually means the app password was deleted or the client is falling back to the account password. Regenerating the app password and re-entering it resolves the common case.
A connection that hangs on port 465 or 587 is normally a blocked outbound port rather than a credential problem. Many networks and hosting providers block outbound SMTP by default, and the symptom is a timeout rather than a rejection message.
A rejection naming a policy or blocklist is a reputation result, not a settings result. No change to the hostname, port or credential affects it, because the receiving server has already decided about the source address.
This is why we track domain health as a single reputation score inside Nitrosend, where a healthy domain reads 1.0. When a rejection names a blocklist, that score is the first thing to pull, because it separates a settings problem from a reputation problem in one look.
There is a bounce pattern here worth knowing about, because it gets misread as a configuration fault. Our support diagnostics on high-bounce accounts keep landing on the same thing: the failures cluster on older, inactive consumer domains, sbcglobal.net, pacbell.net, comcast.net, aol.com and yahoo.com among them, returning errors like mailbox disabled or account closed. Those are dead addresses on legacy consumer providers, not a broken sender.
That matters for anyone reading this page while debugging. If the bounces concentrate on ageing consumer domains and the error text says the mailbox is gone, no amount of adjusting ports or regenerating app passwords will help, because nothing is wrong with the connection. The list is old. The fix is list hygiene, and continuing to send at those addresses is what converts a stale list into a reputation problem.
George's framing on where reputation actually accrues is the other half of this, and it cuts against the instinct to buy a dedicated IP. For Gmail the domain reputation matters more than the IP reputation, which carries a 120-day memory, and dedicated IPs only start making sense above a million emails a month. Below that, a dedicated IP is a warm-up obligation you have taken on for no benefit.