Strapi can send transactional email for important product and CMS workflows, but a basic send test is not enough. If password resets, editor invites, moderation notifications, or approval flows depend on email, you need configuration that is stable across environments and test coverage that checks the actual inbox result.

This guide shows how to configure Strapi email with SMTP or a provider bridge, trigger common email workflows, and validate them safely with MailSlurp before release.

Quick answer

For most Strapi projects, the reliable path is:

  1. configure the email provider with environment-backed settings
  2. keep provider credentials out of source control
  3. test password reset and invite flows against a real inbox
  4. verify links, subjects, and timing before shipping

How Strapi email configuration works

Strapi uses a provider model for sending email. In practice, that means you configure a provider through the app settings and environment variables rather than wiring mail transport logic across your codebase.

A typical setup in looks like this:

The exact provider may vary by project, but the principles stay the same:

  • keep credentials in environment variables
  • keep sender settings explicit
  • keep environment differences small and reviewable

SMTP and provider settings to standardize

Before rollout, align on:

  • SMTP host
  • SMTP port
  • TLS mode
  • provider authentication settings
  • default sender and reply-to addresses

Helpful references:

Common Strapi email workflows to test

The most important Strapi email flows are usually:

  • password reset
  • admin or editor invitation
  • account confirmation
  • moderation or approval notifications

If you use the Users & Permissions plugin, password reset and email confirmation should be first in your test queue. If you rely on Strapi admin workflows, prioritize invitation and approval notifications as separate checks because they often use different templates and environment URLs.

These flows often break from configuration drift, not from code changes alone.

Typical failure modes:

  • wrong sender identity
  • missing reset URL host
  • environment variable mismatch
  • template regressions
  • messages sent but never validated in an inbox

Trigger Strapi email safely in staging

Do not point staging or test systems at real user inboxes. Use isolated inboxes so your team can:

  • trigger a reset email
  • wait for the message
  • check the subject and body
  • confirm that the link resolves correctly

That keeps QA deterministic and reduces the risk of accidental mail to real recipients.

Local provider checks vs inbox testing

Strapi provider configuration tests answer one question: can the app hand a message to the configured transport.

They do not answer the release-critical questions:

  • did the right template render
  • did the right reset or confirmation URL appear
  • did the message reach the expected inbox
  • did the workflow stay correct across staging and production config changes

Use local provider checks to verify plugin wiring. Use MailSlurp when you need inbox-level proof that Users & Permissions, admin invites, and notification flows still work end to end.

Validate Strapi email with MailSlurp

The safer testing pattern is:

  1. create a fresh inbox
  2. use that address in the Strapi workflow
  3. wait for the incoming message
  4. assert the link, subject, and recipient

Example Node.js test flow:

That is materially stronger than checking whether Strapi accepted the send request.

Useful routes:

Configuration mistakes to avoid

Hardcoding provider secrets

Always use environment variables. Hardcoded secrets create deployment drift and increase rotation risk.

Testing only the send action

A successful send call does not prove the email is usable. The password reset URL can still be broken, or the wrong environment host can appear in the template.

Mixing staging and production sender identities

Keep test and production sends clearly separated so troubleshooting is easier and user-facing mistakes are less likely.

Production checklist

Before release, confirm:

  1. provider credentials are environment-backed
  2. sender and reply-to addresses are explicit
  3. password reset and invite flows are tested in a real inbox
  4. links and template variables match the target environment
  5. failures produce enough evidence for debugging

FAQ

Does Strapi support SMTP?

Yes. Strapi can be configured to send through SMTP, often through a provider plugin or bridge layer such as Nodemailer.

What is the biggest Strapi email risk in production?

The biggest risk is assuming configuration is correct because a send call worked once. Broken reset links, wrong hosts, or sender drift often show up later.

How should I test Strapi email in CI?

Use isolated inboxes and explicit receive assertions so you can validate the full workflow without shared mailbox noise.