Product documentation
Updated July 17, 2026

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

FieldNotes
Profile Name (required)A label for the profile, e.g. Team Notifications.
SMTP HostThe outgoing mail server, e.g. smtp.gmail.com. This is what sends.
SMTP PortCommonly 587.
IMAP HostThe incoming mail server, e.g. imap.gmail.com. Only needed if the profile must read mail.
IMAP PortCommonly 993.
SecuritySSL/TLS or None.
UsernameThe mailbox, e.g. your-email@gmail.com.
PasswordAn 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:

PortTypical use
587SMTP with STARTTLS. The usual modern choice.
465SMTP over implicit SSL/TLS.
25Unencrypted SMTP. Widely blocked; don't reach for it.
993IMAP 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 587 with 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

Next steps

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.