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 has the most restrictive email posture of any major WordPress host: no email service, no reliable PHP mail(), and SMTP connections that fail due to dynamic outgoing IPs with no reverse DNS. Email on Pantheon requires a third-party provider configured via API, not SMTP.
Pantheon’s documentation states this directly: outbound email from application containers uses dynamic IPs that change frequently and carry no PTR records (the DNS record that maps an IP address back to a hostname, used by receiving servers to verify the sender is who they claim to be). Messages sent from the local postfix MTA are routinely rejected or spam-filtered. The recommended path is API-based integration with a third-party transactional service.
Plans start at $50/month (Basic, monthly billing) or $41.67/month on annual billing.
Email on Pantheon
How wp_mail works by default
It doesn’t. WordPress sends wp_mail() through PHP’s mail() function, which routes through the server’s local postfix MTA. On Pantheon, Pantheon explicitly says "we strongly recommend that you do not use the local MTA." The reason is not port blocking — ports exist on the server — but IP reputation. Outgoing application containers use dynamic IPs with no PTR records. Receiving mail servers check PTR records during delivery; no PTR means the sending IP cannot be verified, and the message is rejected or spam-classified before any content-level filtering applies.
This is a more fundamental deliverability problem than the port-25 blocking that affects hosts like Cloudways. On Cloudways, the fix is choosing a relay with an open port (587 or 2525). On Pantheon, even with ports open, the dynamic IP means SMTP-based sending is unreliable regardless of port. The only working path is API-based sending, which routes through the relay provider’s infrastructure rather than Pantheon’s outgoing IPs.
Outbound SMTP port status
Ports 25, 465, and 587 are strongly discouraged by Pantheon. Pantheon’s email documentation notes that "SMTP requests are associated with dynamic outgoing IPs" and that this causes deliverability problems. Pantheon suggests ports 2525 or 2587 as alternatives, but the same dynamic-IP issue applies on any SMTP port. Switching ports does not solve the PTR record problem.
| Port | Status |
|---|---|
| 25 | Strongly discouraged (dynamic IP, no PTR) |
| 465 | Strongly discouraged (same reason) |
| 587 | Strongly discouraged (same reason) |
| 2525 | Alternative suggested but same IP issue |
| 2587 | Alternative suggested but same IP issue |
The practical conclusion: SMTP-based sending on Pantheon is unreliable regardless of port. API-based sending bypasses the container’s outgoing IP entirely and is the only consistently working path.
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. Each provider documents its own SPF include string and DKIM key installation:
- Postmark: SPF include
spf.mtasv.net; DKIM CNAME records installed via Postmark’s sending domain setup. - SendGrid: SPF include
sendgrid.net; DKIM CNAME records via SendGrid’s Sender Authentication. - Mailgun: SPF include
mailgun.org; DKIM TXT 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. Because Pantheon has no local MTA sending on the domain’s behalf, the SPF and DKIM alignment paths are cleaner than on hosts with a local MTA — only the relay provider needs to be aligned.
What Pantheon does not provide
- Any email service. No relay, no local MTA path that works, no mailboxes, no forwarders. Zero.
- Reliable SMTP port access. Ports exist on the server but deliverability via SMTP is near zero due to dynamic IPs with no PTR records.
- 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. On Pantheon, there is no "whether" — the platform’s documentation is explicit that local postfix should not be used and that SMTP is unreliable. The question is which relay and how to configure it.
API-based integration is required, not optional. The reason is specific: SMTP connections from Pantheon containers use the same dynamic IPs that cause the PHP mail() problem. Configuring an SMTP plugin with SMTP credentials does not solve the IP reputation issue — the connection still originates from Pantheon’s containers. API-based integration (where the plugin communicates with the relay over HTTPS, and the relay sends from its own dedicated IPs) bypasses the container’s outgoing IP entirely.
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.
For any of these, confirm the plugin is configured to use the API integration, not the SMTP credentials path. Most SMTP plugins offer both; the SMTP path fails on Pantheon for the same reason PHP mail() fails.
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 requires deliberate setup with an API-based relay before any WordPress-generated email can be delivered. 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.