Outgoing server details
The hostname is the setting people get wrong, because the two are similar and the failure is not obvious. A paid organisation account pointed at smtp.zoho.com fails at authentication, which reads as a password problem rather than a wrong-server problem.
Zoho outgoing server details
two hostnames, one letter apartPersonal and free accounts use smtp.zoho.com. Paid organisation accounts, meaning those sending from a custom domain on a paid plan, use smtppro.zoho.com.
Both hostnames accept the same two port and encryption pairings. Port 465 uses SSL, encrypting from the first byte, while 587 upgrades to TLS through STARTTLS after the connection opens.
Match the port to the encryption mode rather than mixing them. Pairing 587 with implicit SSL produces a connection that hangs rather than returning a clear error.
Regional data centres matter for Zoho in a way they do not for most providers. Accounts hosted in the EU, India, Australia and other regions use region-specific hostnames, so a client configured with the default may fail for an account outside that region.
Account credentials
The username is the full email address, whether that ends zoho.com or a custom domain. Zoho requires the authenticating address to match the sending address or one of its aliases, so sending as an unrelated address on the same account is rejected.
Accounts with two-factor authentication require an application-specific password rather than the account password. This is generated in Zoho's account security settings and is scoped to the client it was created for.
Store the credential in an environment variable or a secrets manager rather than in the file that uses it.
Required account setup
SMTP access is not enabled by default on every Zoho plan. It is switched on in Zoho Mail settings under the mail-access section, alongside POP and IMAP.
An account that has not enabled it fails at connection or authentication with no indication that a setting is missing, which is the second most common cause of a failing Zoho configuration after the hostname.
Administrators on organisation plans can restrict this at the org level, so an individual user may be unable to enable it themselves.
When mailbox submission is the wrong path
These settings configure a client to send as one Zoho mailbox, which is correct for a person sending their own mail.
Application mail is a different case. Mailbox submission carries per-user sending limits sized for a person, sends as an individual rather than as a domain identity you manage, and reports no delivery events, bounce classification or suppression state back to the sending system.
George, our CEO, holds the same rule for client work: sending happens from your own domain, which you verify in about a minute, never through a personal mailbox account, because the verified domain is what keeps deliverability strong.
For application or bulk mail the appropriate arrangement is a submission service authenticating as a verified sending domain, which supplies that reporting layer.
We identify and record the email stack behind every customer domain at signup, so we know exactly which mailbox provider a new account is arriving from when the reporting gap starts to bite.