WordPress Multisite email deliverability: one test for every tenant

WordPress Multisite is what powers most of the real WordPress-at-scale deployments: university networks, SaaS site builders, large publisher estates, municipality portals. One codebase, one database, many subsites. Convenient to operate, economically clean — and deliverability-wise, a single point of failure.

When every tenant site shares a sending domain, every tenant site shares a reputation. A single bad-actor subsite can land the whole network's sending domain on a DNSBL. A single misconfigured SPF change by a network admin can break authentication for the entire estate. The only sane response is centralised deliverability monitoring — testing the shared pipe, not each tenant in isolation.

Sender strategies: shared vs per-tenant

The first architectural decision is who owns the sending domain. Three common patterns:

Pattern 1: single shared sending domain

Every tenant sends as noreply@network.com or updates@network.com. One SPF record, one DKIM key, one DMARC policy. Simplest to operate, strongest reputation when all tenants behave. Fragile when one tenant misbehaves — a single bulk campaign from one subsite that triggers spam complaints can drag everyone else down.

Good fit for: homogeneous networks where content is moderated centrally (a franchise operator with 50 branch sites, a university with 200 departmental blogs under one editorial policy).

Pattern 2: per-tenant subdomains

Tenant Acme gets mail.acme.network.com, tenant Widgets gets mail.widgets.network.com. Each subdomain has its own DKIM key and SPF record. DMARC can be inherited from network.com via relaxed alignment. A reputation hit on one tenant does not automatically spread.

Good fit for: SaaS site builders where each customer is independent, publisher networks where editorial autonomy is important, anything with heterogeneous sending patterns.

Pattern 3: tenant-owned domains with network relay

Tenant Acme verifies acme.com with the network's ESP. Every notification from Acme's subsite is signed for acme.com, relayed through the network's infrastructure. Each tenant owns its own reputation.

Good fit for: white-label site builders, agency networks where clients bring their own domains and want their own branding on authentication.

Centralised seed monitoring

The multiplier effect in multisite works both ways: one failure affects everyone, but one test covers everyone too. This is the case for monitoring the shared pipe rather than each tenant.

1. Identify the canonical notification path — which relay, which From: domain, which DKIM selector. This is the path every tenant inherits.
2. Build a minimal notification that exercises that path end-to-end. A synthetic "weekly health check" message from a system mailbox works. It does not need real content.
3. Schedule a weekly send from a representative subsite to a 20+ provider seed list. Capture the per-provider verdicts.
4. Alert on per-provider drops. A sudden move from Inbox to Spam at Gmail while Outlook still lands is the classic first signal of a reputation event.
5. Correlate with DMARC aggregate reports. If aggregate volume moves from pass to fail at a receiver, you have authentication drift — usually an SPF or DKIM change someone made without realising the impact.

Multisite-specific failure modes

• Superadmin edits the shared SMTP plugin. FluentSMTP and WP Mail SMTP both support network-wide config. A superadmin tweak — changing the From: address, rotating an API key without updating DNS — breaks every tenant at once.
• Per-tenant SMTP plugins running alongside the network one. Tenants who install their own SMTP plugin on a subsite can override the network-level config for that tenant only. Worth auditing.
• MU-Plugins that touch wp_mail. An MU-Plugin that adds a BCC: or rewrites From: will apply to every subsite. Worth keeping a change log.
• Tenant-created forms that misuse From:. Even with a clean sending domain, a subsite that puts the visitor's email in From: will fail DMARC. Consider auditing tenant form configs, or enforcing a filter at the MU-Plugin level that rewrites From: back to the network address.

Domain hygiene at network scale

Shared reputation amplifies good behaviour and bad. Practices that are optional for a single WordPress site are mandatory at multisite scale:

• List hygiene. Bounces on one subsite affect reputation for all. Purge hard bounces aggressively. Suppress complaints across the whole network, not just the subsite that generated them.
• Rate discipline. A single subsite running a newsletter blast can exceed the shared domain's reasonable daily volume. Throttle at the relay level, not at each subsite.
• Content moderation. Subjects, links, and attachments from one subsite affect how filters score others. Block known spam templates at the MU-Plugin level before they reach the relay.
• Unsubscribe compliance. One-click unsubscribe headers on every bulk message from any subsite, ever. Gmail and Yahoo have been enforcing this for years and Microsoft caught up in 2025.

# Example: MU-Plugin that enforces network From: address
add_filter( 'wp_mail_from', function() {
    return 'notifications@network.com';
} );
add_filter( 'wp_mail_from_name', function() {
    return 'Network Updates';
} );

Incident response when reputation drops

When the weekly seed test shows a sudden move from Inbox to Spam at one or more providers, the triage order matters:

1. Check DNSBL status on the sending domain and the relay's outbound IPs. A fresh Spamhaus DBL listing explains almost everything on its own.
2. Review the last 24 hours of sending volume per subsite. Flag any subsite whose volume jumped significantly; that is the likely culprit.
3. Pull DMARC aggregate reports from the last 24 hours. Look for a spike in fails that would indicate a spoof event or authentication drift.
4. If one subsite is the source, suspend its sending capability while you investigate. Do not pause the network.
5. Re-test the seed path hourly until placement returns.

Frequently asked questions