Transactional email

Transactional email is the mail your site has to send: password resets, new-user welcomes, comment notifications, WooCommerce order receipts, form submissions. On a vanilla host this is where WordPress quietly falls down — PHP’s mail() hands a message to the local MTA, the receiving server can’t verify it, and it lands in spam or vanishes. managed.dev routes this mail through managed outbound transactional delivery so it actually arrives, with no SMTP plugin to configure.

What’s handled for you

Every site and environment gets working outbound mail out of the box:

• Routing. WordPress mail — wp_mail(), plugin notifications, WooCommerce — is sent through our authenticated relay instead of a local sendmail binary.
• Authentication. Messages are signed and aligned (SPF/DKIM/DMARC) for our sending domain so receiving servers trust them.
• Reputation. Mail goes out over warmed, monitored IPs with proper reverse DNS, kept off blocklists — the reputation work you’d otherwise do yourself.

The practical upshot: password resets and the platform’s own notifications deliver reliably, including the team invites and magic-link SSO emails managed.dev sends on your behalf.

No SMTP plugin needed

You don’t need WP Mail SMTP, Post SMTP, or an external sending API for normal transactional mail. Delivery is wired in at the platform level — installing a competing SMTP plugin can override it, so only do that when you specifically want to bring your own provider.

From-addresses and deliverability

By default, mail is sent in a way that authenticates cleanly against our sending infrastructure, which is what keeps it out of spam. You can set a friendly from name and the reply-to address your recipients should answer to, so the mail reads as coming from your brand even though the platform handles the mechanics underneath.

The email settings panel for a site in the app.managed.dev dashboard, showing the configured from-name, reply-to address, and a “send test email” button with a recent delivery log.

Sending from your own domain

To have mail envelope-authenticated as your domain rather than the platform sending domain, you’ll need the matching DNS records in place. See DNS for the records, and confirm the exact setup in the dashboard — alignment specifics are subject to your domain’s configuration.

When to bring your own SMTP

Managed delivery covers the large majority of sites. You might still point a site at your own provider — SendGrid, Postmark, Amazon SES, Mailgun — when you need to:

• Send bulk or marketing email. Transactional delivery is for transactional mail. Newsletters and campaigns belong on a dedicated bulk-sending provider to protect everyone’s deliverability.
• Consolidate analytics or compliance. You already centralize all outbound mail through one vendor for tracking, suppression lists, or regulatory reasons.
• Use provider-specific features. Templates, dynamic content, or event webhooks that live in your sending platform.

In those cases, install an SMTP plugin and configure it with your provider’s credentials. That mail then flows through your provider instead of the managed relay. Keep your provider’s API keys in your environment’s config and secrets rather than hard-coding them.

Teams & rolesInvites and notifications are delivered through managed mail.

Config & secretsWhere to store your own SMTP provider credentials.