SMTP errors
SubsiMail tests both the SMTP and IMAP connection immediately when you submit the Connect via SMTP/IMAP form, and shows the underlying error directly rather than a generic failure — here's what the common ones mean.
Connection test fails immediately
| Authentication error | Wrong username/password, or the provider requires an app-specific password (common with Gmail/Yahoo if you're using SMTP instead of OAuth) rather than your normal login password. |
| Connection refused / timeout | Wrong host or port, or a firewall blocking outbound SMTP from your server (some cloud providers block port 25 by default — use 587 or 465 instead). |
| TLS/certificate error | Port and encryption mismatch — port 587 expects STARTTLS, port 465 expects implicit TLS. Double-check which your provider expects. |
SMTP works, IMAP doesn't
These are separate credentials and endpoints, even if they're the same mailbox — a working SMTP connection doesn't guarantee IMAP is configured correctly. Some providers (Amazon SES notably) don't have their own IMAP inbox at all; you'd need reply detection through a different connected inbox in that case.
Provider-specific gotchas
- Amazon SES — use SES-specific SMTP credentials generated in the SES console, not your regular AWS IAM access key/secret.
- Gmail/Outlook via SMTP — prefer OAuth instead if it's actually a Gmail or Microsoft 365 mailbox; SMTP is meant for providers without OAuth support.
- Any provider — if you use 2FA on the mailbox, you'll typically need an app-specific password, not your normal login password.