On WordPress.com, Automattic owns wp_mail‘s transport and the sending domain. On self-hosted WordPress (
WordPress.org), the operator does. That single distinction explains every email difference between the two platforms: who configures the relay, who manages SPF and DKIM, who sees the bounce logs, who can install a mailer plugin, and whether the @yoursite.com in the From header is your domain or a shared Automattic domain.
Neither platform provides mailboxes at the operator’s domain by default. That is a separate question with separate answers on each side.
What WordPress.com does for email
WordPress.com is a hosted service run by Automattic. The operator gets a site; Automattic handles the infrastructure, including the mail-sending pipeline. wp_mail() is called the same way it is on any WordPress installation, but the transport layer (PHPMailer’s SMTP connection) is Automattic’s, routing through Automattic’s sending infrastructure. The operator cannot replace it with a third-party SMTP relay. There are no SMTP credentials to configure and no mailer plugin that takes over the transport.
Transactional email (password resets, admin notifications, comment alerts, new user registrations) is handled by Automattic. These messages route through Automattic’s infrastructure. The sender configuration is theirs to manage, including SPF/DKIM alignment.
Form-block submissions are sent through the same infrastructure. The Forms block (available across plans) logs submissions in the Forms dashboard at Jetpack → Forms, with spam filtering applied; email delivery of those submissions goes through Automattic’s sending pipeline.
Subscribe-block newsletters use Automattic’s sending infrastructure, with a sending domain and reputation that Automattic manages. On higher-tier plans, integrations with external newsletter providers like Mailchimp are available.
WooCommerce notifications on WordPress.com (WooCommerce is included on the Business plan and above) follow the same pattern: Automattic’s pipeline handles the send.
Operator-configurable settings are limited to the From name, the admin email address, and notification message content. The transport and the sending domain are not configurable.
Plugin gating. Plugin installation is available on all paid WordPress.com plans — 
Personal, Premium, Business, and Commerce (this was previously gated to Business and above; WordPress.com extended plugin access to all paid plans in April 2026). Even with plugins available across all paid plans, SMTP-replacement plugins do not take over the sending pipeline. WordPress.com’s hosting environment routes outbound email through Automattic’s infrastructure at the platform level; a mailer plugin that expects to replace PHPMailer’s transport with a third-party SMTP connection cannot reach an external relay in the same way it does on self-hosted WordPress. The WordPress.com support documentation does not detail the technical mechanism, but the practical result is that operators on WordPress.com cannot route transactional email through Postmark, SES, Brevo, or other external sending services the way self-hosted WordPress operators can. Plugin access on free plans is not available.
Logging and visibility. Outside the Form block’s submission log and the Subscribe block’s subscriber list, WordPress.com does not expose detailed email logs to operators. There is no mail log, no bounce report tied to the sending domain, and no delivery API to query.
What WordPress.org leaves to the operator
Self-hosted WordPress calls wp_mail(), defined in wp-includes/pluggable.php, which delegates to the PHPMailer library bundled with WordPress core. WordPress 5.5 (released August 11, 2020) upgraded the bundled PHPMailer from version 5.2.27 to PHPMailer 6.1.6; the current bundled version tracks PHPMailer 6.x releases. PHPMailer’s default transport is PHP’s mail() function, which hands the message to the local mail transfer agent.
On most hosting environments, this default path does not deliver reliably. Shared and managed hosting providers restrict or disable the local MTA entirely (SiteGround, Kinsta, WP Engine, and Cloudways all block or restrict local mail sending); outbound port 25 connections are blocked at the network level on most cloud VPS providers — AWS EC2 blocks port 25 by default for all instances, DigitalOcean blocks it for new accounts, and Linode restricts ports 25, 465, and 587 for accounts created after November 2019; the outbound IP address is on a shared subnet with no per-IP sending reputation, and no SPF record covers mail() sends from the host’s MTA. A self-hosted WordPress site that has never been configured for email is probably silently dropping most of what it tries to send.
A mailer plugin fixes this by hooking into wp_mail and replacing PHPMailer’s transport with a connection to an external SMTP relay or email API. Common choices are WP Mail SMTP, FluentSMTP, and Post SMTP — each replaces the transport layer in the same basic way. The operator then connects the plugin to an external sending service (Postmark, Brevo, Amazon SES, SMTP2GO, Mailgun, and others) and configures the sending domain.
The sending domain is the operator’s to manage. That means publishing SPF records in DNS authorising the chosen relay, generating and publishing DKIM keys (and rotating them periodically), setting a DMARC policy, and monitoring aggregate reports to catch authentication failures.
The five-stage delivery chain — from wp_mail() through PHPMailer, the transport, the relay’s outbound infrastructure, and finally the recipient’s mail server — is described in How Email Works: A WordPress Operator’s Reference. On WordPress.com, Automattic owns stages 3 and 4. On self-hosted WordPress, the operator does. Operator ownership of the transport means operator access to what comes back: bounce events, delivery webhooks, spam complaints, and open/click data where the sending service provides them.
The mailbox question
Neither WordPress.com nor WordPress.org provides mailboxes at the operator’s domain by default. This is the part the top search query — "@wordpress.com" email — is often actually asking about.
There is no [email protected] inbox. WordPress.com manages outgoing transactional email through Automattic’s sending infrastructure, which is why notifications may surface a wordpress.com-adjacent envelope sender, but there is no user-facing mailbox at that address. The platform offers mailbox hosting separately:
- Professional Email — Titan-powered mailboxes at the operator’s custom domain, sold as an add-on through wordpress.com/professional-email.
- Google Workspace — resold as an add-on through WordPress.com for operators who want Google-backed mailboxes.
Self-hosted WordPress has no mailbox product of any kind. The operator brings a mailbox provider independently — Google Workspace, Microsoft 365, Fastmail, Migadu, or whatever fits the use case. WordPress’s email system handles sending; what the domain receives is entirely separate infrastructure.
What changes when you move between platforms
Moving from WordPress.com to self-hosted: the sending pipeline is no longer Automattic’s. On day one at a new host, email is broken: the default PHP mail() path will not deliver reliably. The immediate tasks are configuring a mailer plugin, connecting it to an external sending service, and publishing SPF/DKIM/DMARC records for the sending domain. The admin email address and From name need to be verified in Settings → General on the new installation. The Subscribe block’s subscriber list needs to be exported from WordPress.com and migrated to a newsletter plugin or external provider before the old site is decommissioned. Professional Email or Google Workspace mailboxes remain intact — those are DNS-based and are unaffected by the hosting change unless the domain is also moved.
Moving from self-hosted to WordPress.com: Automattic’s sending pipeline takes over. Mailer plugin configuration and SMTP credentials become irrelevant; the platform handles the transport. The envelope sender and DKIM signing domain change to Automattic’s infrastructure, which means a From address that was previously aligned with DKIM on the operator’s domain will no longer align that way — Automattic’s DKIM covers the send, not the operator’s DNS. On any plan, the visibility and configurability the operator had on self-hosted — log access, custom bounce handling, per-message-type routing — do not carry over.
Comparison
| WordPress.com | WordPress.org (self-hosted) | |
|---|---|---|
Who owns wp_mail‘s transport |
Automattic | The operator |
| SMTP configuration | Not available | Via mailer plugin |
| SPF / DKIM / DMARC | Managed by Automattic | Operator-managed |
| Sending domain alignment | Automattic’s infrastructure | Operator’s domain |
| Third-party plugins | All paid plans; transport replacement not available | Unrestricted |
| Mail logs / bounce data | Not exposed to operators | Available from sending service |
| Transactional email | Included, no setup | Requires mailer plugin + sending service |
| Contact form email | Form block included; email via Automattic | Requires form plugin + mailer plugin |
| Newsletter sending | Subscribe block + Automattic infrastructure | Newsletter plugin + sending service (or integrated provider) |
| Mailboxes at operator’s domain | Professional Email (Titan) or Google Workspace, both paid add-ons | Separate provider; WordPress does not supply |
| Synchronous-send blocking | Platform-managed; operator-invisible | Operator-managed; queue plugin may be needed on busy sites |