Skip to content

Email SMTP

The platform sends transactional emails on your tenant's behalf — verification, recovery, OTP, invitations. By default, those come from a platform-generic sender. For production, configure your own SMTP so the From address is yours.

The platform's default SMTP is fine for prototyping but:

  • The From address is generic (noreply@<platform-domain>). Users may not recognise it; spam filters look at it harder.
  • Rate-limited (a few hundred sends per hour). Sufficient for small tenants; not for production.
  • Deliverability isn't guaranteed (the platform shares its sending reputation across all default-SMTP tenants).

Your own SMTP / transactional email service (SendGrid / Postmark / Mailgun / AWS SES / etc.) lets you:

  • Send from noreply@cymmetri.com (your domain; familiar to users).
  • Send at volume.
  • Bring your own reputation; track deliverability.

Integrations → Email SMTP. Click Configure your own SMTP.

Form fields:

  • Host — your SMTP server hostname (e.g., smtp.sendgrid.net, smtp.postmarkapp.com).
  • Port — typically 587 (STARTTLS) or 465 (TLS).
  • Username — your SMTP username.
  • Password — your SMTP password / API key. Stored encrypted; never displayed in plain text after entry.
  • From addressnoreply@cymmetri.com or similar. Must be an address you've authenticated on your DNS (see "Deliverability" below).
  • From name — display name on outgoing emails ("Cymmetri Auth").
  • Reply-to — optional address users can reply to (often support@cymmetri.com).

Click Test connection. The platform attempts to send a synthetic email to YOUR address (the signed-in admin's). Confirm in your inbox.

Click Save. Your SMTP is now active; future transactional emails go through it.

For an SMTP integration to actually deliver to user inboxes (instead of spam folders), your sending domain needs:

  • SPF record — DNS TXT record allowing the SMTP provider's IPs to send from your domain. Per provider docs.
  • DKIM — cryptographic signing of outgoing emails. Per provider setup, usually a CNAME or TXT record.
  • DMARC policy — DNS TXT record declaring how recipients should handle email that fails SPF / DKIM. Recommend p=quarantine or p=reject.

The integration's Deliverability tab on the configuration page checks your DNS records + reports status. Green = ready; red = something's missing.

Check at https://mxtoolbox.com/ to confirm independently. Gmail / Outlook deliverability is the bar.

Every transactional email the platform sends:

  • Verification — sign-up email verification.
  • Recovery — password reset link.
  • OTP — sign-in codes.
  • Magic link — sign-in links.
  • Invitation — new tenant admin / new user invitation.
  • Notification — admin-style notifications (breach alert, etc.).
  • Email change — verification for an in-place email change.

All of them use whatever SMTP is configured. There's no per-template-type SMTP routing.

Mid-quarter, you decide to move from SendGrid to Postmark. Procedure:

  1. Set up DKIM + SPF for Postmark on your domain (in parallel; don't break the existing SendGrid setup).
  2. In Integrations → Email SMTP, change the configuration to Postmark's settings.
  3. Test connection. Confirm in your inbox.
  4. Save. Future emails go through Postmark.
  5. Wait a week; monitor deliverability.
  6. Remove the (now-unused) SendGrid integration from your account, if appropriate.

The cutover is essentially instant; no email is "in-flight" through the old SMTP after save.

Each email send records email.sent or email.send_failed in audit. Filter on the latter to find delivery problems.

For provider-side stats (open rate, bounce rate), check your SMTP provider's own dashboard — the platform doesn't proxy that data.

SMTP is tenant-scoped. Different tenants under the same organisation can have different SMTP integrations — e.g., production-cymmetri uses SendGrid; staging-cymmetri uses the platform default (which is fine for testing flows that involve email but don't care about real deliverability).

  • Wrong port. 587 for STARTTLS, 465 for direct TLS, 25 for unencrypted (don't use). Some providers want one specifically; check their docs.
  • DKIM not yet propagated. DNS changes can take minutes to hours. The Deliverability tab reflects DNS as-currently-resolved by the platform; wait + recheck.
  • From address not authenticated on the SMTP side. Most providers require you to verify the From address (one-click verification via an emailed link). Without it, the provider refuses sends.
  • Provider rate limits. Some providers cap sends per minute / hour / day. If your tenant exceeds, emails queue or fail. Choose a provider tier that matches your expected send volume.

Toggle off your custom SMTP → the platform reverts to its default. Useful for short-term debugging if your provider is having issues — emails resume going out through the platform default while you fix your provider.

Audit records the toggle: admin.integration_email_smtp_disabled / _enabled.