Customer SMTP server

An email connector picks its outbound transport when it is created. The default is a managed inbox: AltScore provisions it through AgentMail, and it can receive replies. The alternative is the customer's SMTP server: the email leaves from their server, with their credentials, and nothing on their DNS has to change.

Choose SMTP when the customer cannot or will not publish DNS records for us, or when the mail has to come from their own infrastructure and carry their own sending reputation. If neither applies, the managed inbox is the simpler option.

What you give up

This transport is send only. The platform hands the message to the customer's server and that is the end of its involvement.

The consequence to say out loud to a customer before they choose: a conversation on an SMTP connector is one-directional. The flow can write to a person; the person's answer does not come back. Use it for notifications — a code, a receipt, a status change — and not for a conversation that expects a reply.

The same applies to anything that needs to read delivery results. Bounce handling, suppression lists and reputation are whatever the customer's provider does with them; the platform never sees the outcome.

The transport is locked after creation

The transport is chosen on the create form and cannot be changed afterwards — the form says so: "The transport is set when the connector is created and cannot be changed afterwards." Moving a connector from a managed inbox to SMTP, or back, means creating a new connector and repointing the flows at it.

The connector's mode is not a choice either. An SMTP connector is forced to send only when it is created, because the customer's server never hands us incoming mail; offering two-way would promise a reception the transport does not have.

Configuration

Authentication is username and password. It is the only mechanism available today; a connector asking for anything else is refused with "That authentication method is not available yet. Use username and password."

The password is stored like every other connector secret: write-only, under the key smtp_password. Once saved it shows as masked dots and cannot be read back. To rotate it, type a new one — leaving the field untouched keeps the current value.

Port and encryption

Any other port is refused when the form is saved: "Port not allowed. Use 25, 465, 587 or 2525."

Microsoft 365

Most customers who ask for this transport are on Microsoft 365, and it is the setup with the most ways to fail. Three things have to be true, and none of them is the default.

STARTTLS on port 587. Exchange Online does not accept implicit TLS on 465 — the TLS versions that port expects are not the ones it supports. Pointing the connector at a Microsoft host with implicit TLS is blocked on save: "Microsoft 365 only accepts STARTTLS. Change the encryption or use another server."

SMTP AUTH enabled on that specific mailbox. Microsoft turns authenticated SMTP off by default on every mailbox. The tenant-wide setting is not enough; an administrator has to enable it for the mailbox the connector uses. The mailbox also has to sit outside any Conditional Access or authentication policy that blocks basic authentication — a tenant with security defaults on blocks it for everyone. When it is missing, the server rejects the login and the connector reports: "The server rejected the credentials. Check that SMTP AUTH is enabled for that mailbox."

A licensed mailbox. Shared mailboxes without a license and accounts without an Exchange Online plan cannot submit.

Leave the sender address empty

The sender address is optional, and leaving it empty is the combination that needs no extra permission: the email goes out from the mailbox that authenticated, which is by definition allowed to send as itself.

Whatever address ends up in use goes on both the envelope and the From header, so it is also the address a bounce comes back to. The From name on the connector only changes the display name next to it.

Set a different address — noreply@company.com while authenticating as notifications@company.com — and Exchange requires an administrator to grant that mailbox the Send As permission on the address. Without it, Exchange rejects the message with 5.7.60, and because this transport is send only, the rejection notice arrives in the customer's mailbox, not on the platform. Nothing on the conversation says the mail did not go out.

That is why the form asks you to confirm it explicitly. When the sender address differs from the username, saving is blocked until the confirmation is ticked: "The sender address differs from the user: confirm the admin granted Send As permission." The connector detail view then shows Send As permission: Confirmed or Not confirmed.

If nobody can confirm the permission, leave the sender address empty.

Test it before handing it over

The connector detail view has a Send test email action: you give it a destination address and it sends a real message through the configured transport — the same code path a flow uses, not a simulation.

When it fails, the panel shows the Server response: the reply the SMTP server actually gave, verbatim, instead of a translated summary. That raw text is what tells you whether the rejection is authentication, the sender address, or the mailbox being blocked for submission, and it is the only place it is exposed. On success you get a confirmation and nothing else.

Run it once against an address you control before the customer's first flow goes live. This transport has no other feedback channel.

When it fails

Two more you can hit in flight:

• The server is throttling by volume. Try again later. — any temporary (4xx) refusal.
• The server did not accept an encrypted connection. We do not send credentials without TLS. — the server did not offer STARTTLS. The password is not sent in that case.

Validation on the form catches the rest before anything is sent: a missing server, an IP address instead of a DNS name, a port outside the allowed four, implicit TLS on a Microsoft host, a missing username or password, and an unconfirmed Send As.

A failed send is not retried

Neither temporary nor permanent failures are retried. That is deliberate: Exchange Online blocks a mailbox for SMTP submission when an application keeps retrying after errors, and a blocked mailbox is a much worse outcome than a message that did not go out. When a send fails, fix the cause and send again.

A blocked mailbox surfaces as "The provider blocked the mailbox for SMTP submission" and carries an SMTP status in the 5.2.251–5.2.255 range. Microsoft decides how long the block lasts; it cannot be lifted on request, and the affected messages leave no trace in Message Trace.

Limits

Gotchas

• Replies are lost, not queued. Somebody will answer the notification. That answer goes to the customer's mailbox and no notice appears anywhere in the platform.
• The transport cannot be changed later. Decide before creating the connector.
• A rejected message is invisible on our side. The NDR goes to the customer's mailbox, so make sure somebody there reads it.
• Microsoft 365 needs three separate things enabled, and SMTP AUTH per mailbox is the one that is off by default and gets forgotten.
• Leaving the sender address empty avoids the whole Send As problem. Only set one when the address genuinely has to differ and an administrator has granted the permission.
• The password cannot be read back. Store it wherever the customer keeps credentials; the connector will not show it again.

See Channel Connectors for the settings every connector shares.