Email Settings: SMTP and IMAP Profiles
Create the mail profiles that let Shift-Left API send notifications: SMTP and IMAP hosts, ports, security, and credentials — with the usual provider gotchas.
Overview
Email Settings holds the mail profiles the product sends through. Without one, nothing that depends on email works — run notifications, scheduled reports, user invitations, and verification mail all go nowhere.
Nav path: Settings → Email → Email Settings. Requires Administrator access. With none configured you'll see No email profiles configured.
What a profile contains
| Field | Notes |
|---|---|
| Profile Name (required) | A label for the profile, e.g. Team Notifications. |
| SMTP Host | The outgoing mail server, e.g. smtp.gmail.com. This is what sends. |
| SMTP Port | Commonly 587. |
| IMAP Host | The incoming mail server, e.g. imap.gmail.com. Only needed if the profile must read mail. |
| IMAP Port | Commonly 993. |
| Security | SSL/TLS or None. |
| Username | The mailbox, e.g. your-email@gmail.com. |
| Password | An app password or the account password. |
SMTP is the part that matters for notifications — that's the sending path. IMAP only comes into play for features that read a mailbox, so a send-only profile can leave it blank.
Ports and security
The port and the Security setting have to agree, and mismatching them is the most common reason a profile silently fails:
| Port | Typical use |
|---|---|
| 587 | SMTP with STARTTLS. The usual modern choice. |
| 465 | SMTP over implicit SSL/TLS. |
| 25 | Unencrypted SMTP. Widely blocked; don't reach for it. |
| 993 | IMAP over SSL/TLS. |
Set Security to SSL/TLS unless you have a specific reason not to. None sends credentials in the clear, and most providers will refuse the connection anyway.
App passwords
The placeholder says "App password or regular password", and for any major provider the answer is app password.
Google, Microsoft, and most others reject plain account passwords for SMTP once 2FA is on — which it should be. You generate an app password in the provider's own security settings and paste that here. If you're getting authentication failures with credentials you're certain are right, this is almost always why.
An app password is also safer: it's scoped, and revoking it doesn't disturb the account.
Use a dedicated mailbox
Point the profile at a mailbox that exists for this purpose — notifications@yourcompany.com — rather than a person's account.
An individual's mailbox ties your alerting to their employment, their password changes, and their 2FA device. When they leave, notifications stop, and it takes a surprisingly long time for anyone to notice that the silence isn't good news.
After creating a profile
Send something through it before trusting it. A scheduled report that has never actually delivered is indistinguishable from a passing test suite — both are quiet.
See Email templates for content, and Scheduled reports and alerts for delivery.
Managing profiles
Profiles can be edited and deleted — Delete Email Profile removes one. Check what depends on it first: deleting the profile a scheduled report sends through stops that report without disabling it, so it looks configured and silently delivers nothing.
Why email is worth getting right first
Email configuration is the kind of task that gets deferred because nothing appears to depend on it. In practice a surprising amount does, and each failure is silent:
- User invitations don't arrive, so onboarding stalls and looks like a permissions problem.
- Email verification never lands, so accounts sit unusable while Require email verification for new users waits. See User policies.
- Scheduled reports run and deliver nothing.
- Failure alerts don't fire — and this is the dangerous one. A test suite that catches a regression at 2am and can't tell anyone has done none of its job, while every dashboard shows it working perfectly.
That last case is worth dwelling on. Alerting failures are invisible by construction: the absence of an email looks exactly like good news. Everything else on this page is configuration; that is the reason to do it before you need it.
Troubleshooting
- "No email profiles configured" — nothing set up yet. Nothing that emails will work until there is.
- Authentication fails with correct credentials — you need an app password, not the account password. Generate one in your provider's security settings.
- Connection times out — port and Security disagree, or outbound SMTP is blocked from the network the product runs on. Try
587with SSL/TLS. - Mail sends but never arrives — check spam, then whether your domain's SPF/DKIM permits this server to send as that address. Providers quietly drop mail that fails alignment.
- Notifications stopped without any change — the mailbox password rotated, or an app password was revoked. Common when the profile points at a personal account.
- Settings are read-only — you're not an Administrator.
Related articles
Previous
Public API
Product documentation
Next
Email Templates: Notification Content
Product documentation
Related articles
- Administration Settings · Product documentation
- Server Connection · Product documentation
- Proxy Settings · Product documentation
- License Management: Status and Keys · Product documentation
- User Management · Product documentation
- Role Permissions · Product documentation
Next steps
- Getting started · Install + connect your spec
- Configuration fundamentals · Stabilize runs
- Initial configuration · Users, licensing, projects
- Release notes · Updates and fixes
Still stuck?
Tell us what you’re trying to accomplish and we’ll point you to the right setup—installation, auth, or CI/CD wiring.