Pantheon is a WebOps platform for WordPress and Drupal, backed by SoftBank (Series E, $100M in 2021), founded by Zack Rosen, David Strauss, Josh Koenig, and Matt Cheney. It provides no email service: no mailboxes, no relay, and a local postfix MTA that Pantheon tells operators not to use. WordPress mail on Pantheon needs a third-party provider, and Pantheon recommends connecting it through the provider’s REST API rather than over SMTP.
Pantheon’s 
email documentation gives the reason in one line: an SMTP configuration works, “but because SMTP requests are associated with dynamic outgoing IPs there can be negative impacts to deliverability.” It does not say more than that, and it publishes no mail logs, so there is no host-side record of what was sent.
Plans start at $55/month (Basic, monthly billing) or $500/year.
Email on Pantheon
How wp_mail works by default
WordPress sends wp_mail() through PHP’s mail() function, which hands the message to the container’s local postfix MTA. Pantheon’s answer to “Can I use Pantheon’s local MTA (postfix)?” is “We strongly recommend that you do not use the local MTA (postfix).” It also says mail logs for the site are not available. A site that has not been set up with a provider is therefore sending through a path the host disowns, with no log to check when a password reset does not arrive.
The same page gives an SPF include, include:spf.pantheon.io, for sites that use the local MTA anyway, and a few answers later says “we don’t support SPF” when explaining why Microsoft 365 relaying tends to fail. Neither answer makes the postfix path a supported one.
Outbound SMTP port status
Pantheon “strongly encourages using ports other than 25, 465 or 587 to send email because those ports are often blocked by service providers as an anti-spam measure.” It lists the alternate port to use for each common provider:
| Provider | Port Pantheon recommends |
|---|---|
| Amazon SES | 2587 (STARTTLS) or 2465 (TLS wrapper) |
| Mailgun | 2525 |
| Mailchimp | 2525 |
| SendGrid | 2525 |
| SparkPost | 2525 |
| Ports 25, 465, 587 | Strongly discouraged |
For a provider not in the table, Pantheon says to check whether it accepts SMTP on another port. Choosing the right port does not change the outgoing IP: every SMTP connection still leaves from one of Pantheon’s dynamic IPs, which is the deliverability concern Pantheon raises. A REST API integration avoids the question, because the plugin sends the message to the provider over HTTPS and the provider handles delivery from its own infrastructure.
Microsoft 365 and Exchange
Microsoft 365 accepts mail from applications on ports 25 and 587 by default, through SMTP client submission, direct send or an SMTP relay connector. Pantheon’s documentation says: “Because we don’t support SPF, it is likely that most Exchange or Office 365 servers won’t work if configured at your email server.” Operators whose domain mail is on Microsoft 365 should send WordPress mail through a transactional provider instead, and keep Microsoft 365 for the team’s mailboxes.
Sending limits
Pantheon imposes no sending limit because it provides no sending service. The sending limit is set by whichever third-party relay is configured. For operators using Postmark, the Postmark plan sets the limit; for Mailgun, Mailgun’s plan applies; for SMTP2GO, SMTP2GO’s plan applies.
There is no platform-level throttle or queue to manage.
Mailboxes, forwarding, DNS
Pantheon hosts no email. No mailboxes, no IMAP or POP3, no email forwarders, no catch-all addresses. Domain email (branded addresses for the team) requires a completely separate provider: Google Workspace, Microsoft 365, Fastmail, or similar. Pantheon does not intersect with domain email hosting at all.
DNS is managed through the Pantheon dashboard for domains using Pantheon’s DNS. SPF (the DNS record that lists which mail servers are authorised to send on the domain’s behalf), DKIM, and DMARC records for whichever relay is in use are configurable via the DNS panel. Operators using Cloudflare DNS add the records there.
Authentication (SPF, DKIM, DMARC)
SPF and DKIM configuration depends entirely on the third-party relay in use, and on which domain it puts in the envelope sender (the Return-Path address), because that is the domain receivers check SPF against:
- Postmark: Postmark’s default Return-Path needs no customer SPF record; an optional custom Return-Path uses a CNAME. DKIM via Postmark’s sending domain setup.
- SendGrid: with automated security on (the default), SPF is managed through the generated
emCNAME and the root record needs no include. With automated security off, follow the SPF record and return-path instructions SendGrid generates for the configured domain. DKIM CNAME records via SendGrid’s Sender Authentication. - Mailgun: SPF include
mailgun.orgon the sending domain, which Mailgun recommends be a subdomain such asmg.example.com; DKIM record via Mailgun’s domain verification.
Records are added through Pantheon’s DNS panel (or Cloudflare, if DNS is managed there).
DMARC is added separately: a monitoring policy (v=DMARC1; p=none; rua=mailto:reports@<domain>) is the standard starting point. With every message going out through the relay, only the relay provider needs to be aligned. include:spf.pantheon.io belongs in the record only if the site also sends through the local postfix, which Pantheon recommends against.
When the chosen relay’s include has to sit alongside a mailbox provider (Google Workspace, Microsoft 365) in one SPF record, the SPF merger folds the two together and counts the DNS lookups against RFC 7208’s ten-lookup ceiling before publish. Once the record is live, the DNS auth checker reads how the domain’s SPF, the relay’s DKIM CNAMEs, and DMARC resolve from the receiver’s perspective, so a stale nameserver or a mistyped selector shows up before real traffic does.
What Pantheon does not provide
- Any email service. No relay, no supported local MTA path, no mailboxes, no forwarders.
- Standard SMTP ports. Pantheon steers SMTP traffic away from 25, 465 and 587 toward provider-specific alternates such as 2525, and warns that SMTP from its dynamic outgoing IPs can hurt deliverability.
- Email hosting. Domain email requires a completely separate provider with no Pantheon integration.
- Email logs or delivery events. Pantheon provides no mail logs. Delivery visibility comes entirely from the third-party relay’s dashboard.
When a third-party relay is needed
Always. Pantheon’s documentation says local postfix should not be used, so every WordPress site on the platform needs a provider. The choices are which provider and how the plugin connects to it.
A REST API integration is what Pantheon recommends. The plugin hands each message to the provider over HTTPS, and nothing leaves Pantheon on an SMTP port. SMTP is the fallback: it works on an alternate port from the table above, and Pantheon notes that customers have used SendGrid, Gmail, Amazon SES and Mandrill this way, with the caveat about dynamic outgoing IPs.
Service options:
- Postmark for A transactional email is the automated message a WordPress site sends in response to a single user action – a password reset, an order confirmation, a form receipt – addressed to the user who triggered it. Read full reference → where delivery reliability is a revenue requirement. Postmark’s API plugin handles
wp_mail()via HTTP; no SMTP port required. - SendGrid with the WP Mail SMTP or official SendGrid plugin using the REST API (not SMTP mode). Pantheon documents a dedicated SendGrid integration guide.
- Mailgun for pay-as-you-go volume at lower cost than Postmark at scale.
- SMTP2GO for the free-tier entry point (1,000 emails/month); API plugin available.
Check whether the chosen plugin offers a REST API mailer for the provider. If it does, use that integration. If it does not, use the provider’s documented alternate SMTP port where available; Pantheon warns that SMTP from its dynamic outgoing IPs can affect deliverability.
Verdict
Pantheon is the platform-of-record for teams running WordPress or Drupal at scale who treat email as a solved problem handled outside the hosting stack. Email on Pantheon needs a provider set up before WordPress mail can be relied on, and Pantheon recommends connecting it over the provider’s REST API. Operators migrating to Pantheon from a host where wp_mail() worked by default (shared hosting, most managed WordPress hosts) should allocate time for relay setup before go-live.
For the WordPress email setup that supplements Pantheon’s default path, see how to configure WordPress email.
Corrections
- 2026-10-30: an earlier version gave Basic as $50/month and Performance from $160/month; Pantheon’s prices at the time were $55 and $200. It also said Pantheon’s documentation describes the platform’s outgoing IPs as having no PTR records, and called SMTP deliverability from Pantheon near zero. The documentation says only that SMTP requests come from dynamic outgoing IPs and “there can be negative impacts to deliverability”; it does not mention PTR records.
- 2026-11-12: an earlier version gave root-domain SPF includes for Postmark (
spf.mtasv.net), SendGrid (sendgrid.net), and Mailgun (mailgun.org). Postmark’s default setup uses its own Return-Path; SendGrid’s default automated-security setup manages SPF through anemCNAME. Mailgun’s SPF record belongs on its configured sending domain, and Mailgun recommends a subdomain.