Loading

SMTP Accounts

SMTP is the standard way to send mail, supported by essentially every provider.

Where to find it

Architect Panel → Integration & Connections:

  • E-mail Accounts — the accounts mail is sent and received through

Architect Panel → Activity:

  • E-mail Log — every message sent, with its result

What it needs

  • A server and port.
  • Encryption.
  • Credentials.

Your provider publishes all four. Use what they document rather than what worked somewhere else.

Always encrypt

Unencrypted SMTP sends your credentials and your message content in clear text across the network. There is no situation where that is the right choice today, and providers increasingly refuse it anyway.

Use an application password where offered

Many providers issue a credential specific to one application rather than using the account password. Where that is available, use it: it can be revoked without changing anything else, and it usually works where the main password is blocked.

When SMTP is the right choice

  • The provider offers nothing better.
  • You are sending through a dedicated mail service.
  • You want one method across several providers.

When a provider connection is better

For Microsoft 365 in particular, the Graph connection is generally the better option: it avoids credentials being refused as organisations disable basic authentication, and it is what the provider is steering people towards.

If your organisation is on Microsoft 365 and SMTP has started failing, that is usually the reason rather than anything you changed.

Sending limits

Providers cap how much you may send — per hour, per day, per recipient count. A general mailbox is not built for bulk, and exceeding a limit gets your account restricted rather than politely throttled.

If you send campaigns, use a service intended for it rather than a mailbox.

Failures are informative

SMTP errors are more specific than most. An authentication failure, a relay refusal and a rate limit read differently in the log — worth reading rather than treating every failure as "mail is broken".

Test a send and a failure

Send successfully, then send to a deliberately invalid address to see what the failure looks like in the log. The second is what your support team will actually encounter.

Worked example

An organisation configures SMTP against its provider's documented settings with encryption and an application password. Transactional mail goes through it; campaigns go through a separate sending service, after a bulk send through the mailbox triggered a rate limit and suspended the account for an afternoon.

Recommendations

  • Always encrypt, and use the provider’s documented settings.
  • Use an application password where offered.
  • Prefer Graph on Microsoft 365.
  • Do not send campaigns through a mailbox.