Zoho SMTP settings, and what changes when an agent sends through Zoho

Outgoing server details

The hostname is the easy setting to get wrong, because the two are similar and the failure is not obvious. A paid organization account pointed at smtp.zoho.com fails at authentication, which reads as a password problem rather than a wrong-server problem.

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.

What changes when an AI agent sends through Zoho

A person sets up Zoho SMTP once, in a mail client, and sees the error when it fails. An AI agent asked to send email from a Zoho account writes the same settings into application code, and that code then runs unattended. Four things change.

• The host depends on account type and region. An agent filling in a host from memory tends to write smtp.zoho.com. A paid organization account needs smtppro.zoho.com, and an account hosted in another region, such as the EU, needs that region's hostname rather than the .com one. Both mistakes show up as authentication failures, so the agent may keep changing the password instead of the host. The port pairing is the same on both hosts and is explained under SMTP port numbers.
• The credential ends up in code. On an account with two-factor authentication the agent needs an application-specific password, and the quick path for a coding assistant is to paste it into a config file or print it in a log. It belongs in an environment variable, as covered under SMTP passwords.
• Zoho's mailbox limits apply to the app. The application sends as one Zoho user, so every message counts against that user's sending limit, and the application gets no bounce or delivery events back.
• An API is the alternative to a mailbox. An agent can send application mail through an email API or over MCP, authenticating as a verified sending domain. Nitrosend has no SMTP host to put in these fields, so the Zoho settings on this page stay with a person's own mailbox.

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 sign that a setting is missing. Check this after the hostname.

Administrators on organization plans can restrict this at the org level, so an individual user may be unable to enable it themselves.

Worked example: an agent sends booking confirmations without a Zoho mailbox password

A small booking business has been sending its confirmations through the front-desk Zoho mailbox, a paid organization account. The owner asks a coding assistant to move them off it.

Prompt: "Send our booking confirmations from our own domain instead of the front-desk Zoho account, and show me a test confirmation before any customer gets one."

Before, unguided: the assistant hardcodes smtp.zoho.com, port 465 and the front-desk app password into the booking code, Zoho rejects the login because the organization account lives on smtppro.zoho.com, and the assistant retries with the same password.

With the Nitrosend MCP tools, in this order:

1. nitro_get_status reads the account's readiness and the sender identity the confirmations would carry.
2. nitro_manage_domains adds and verifies the business domain for sending, so confirmations come from the business rather than a staff mailbox.
3. nitro_manage_template creates the booking confirmation as a reusable template, with the date, time and location as fields.
4. nitro_review_delivery checks the confirmation before anything leaves: validation, spam analysis and a preview of a filled-in booking. It sends nothing.
5. nitro_send_test_message delivers a single sample confirmation to the owner's test address, the one stored with nitro_configure_account.
6. Person approves: the owner reads that sample and approves the wording. Nothing goes to a customer before this.
7. nitro_send_message is then called by the booking code once per booking, reusing an idempotency_key only when it retries that exact booking.
8. nitro_get_insights shows how the confirmations perform over the following weeks, with trends and recommendations.

After: confirmations go out from a verified business domain, no Zoho password sits in the booking code, and a retried booking does not produce a second confirmation.

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.

Mail an app sends is a different case. Sending through one mailbox carries per-user sending limits sized for a person, sends as an individual rather than as a domain you manage, and reports no deliveries or bounces back to the app.

For mail an app sends, use an email sending service that sends from your own verified domain and reports deliveries and bounces back to the app.

Where it goes wrong when an agent uses Zoho SMTP

These failures are specific to Zoho, and the first two look like a wrong password when they happen.

• smtp.zoho.com used for an organization account. The agent picks the free-account host, the paid organization account rejects the login, and changing the password does nothing. The host has to change to smtppro.zoho.com.
• The .com host used for an .eu account. An account hosted in Zoho's EU data center authenticates against the EU hostname, so an agent that only knows the .com host gets the same failed login. Check the host before the password, because Zoho returns the same failed login for a wrong host and a wrong password.
• An app password owned by a staff member who leaves. The application-specific password belongs to one person's account. When that person leaves and the password is revoked or the account closed, the application stops sending, and because mailbox submission reports no delivery events, nothing in the app flags it.
• The sending limit used up by a loop. An agent that retries a failed send in a loop, or sends one message per record from a batch job, spends the mailbox user's sending limit. Because the limit belongs to that user, their own outgoing mail is affected as well.

Application mail that needs delivery events and a domain identity is better served by a transactional email API, and the wider pattern for agents is covered in sending email from LLMs.

Go deeper