WordPress newsletter plugins: test what the plugin hides

Running a newsletter from a WordPress admin is appealing. Your subscribers are in the WP users table, your content is already in the CMS, your forms feed directly into the list. The plugin promises to handle the hard parts — rendering the template, keeping the list clean, pushing the send to Mailchimp or Brevo or Mailster, reporting opens and clicks.

What the plugin does not expose is the one thing that matters: folder placement. The built-in report tells you "sent" and "delivered" — meaning the ESP accepted the message and the receiver returned a 250 OK. That is not the same as reaching the inbox. A message can be "delivered" and sitting in Spam, Promotions, or Updates for every recipient.

How WordPress newsletter plugins route

There are roughly three architectures in use, and the deliverability implications differ:

Architecture A: plugin sends from your server

Mailster, The Newsletter Plugin (free mode), WP Newsletter. The plugin builds the message list on your server and loops through SMTP sends via wp_mail(). Whatever SMTP plugin handles your transactional mail also handles your newsletter. The upside is full control. The downside is that if your transactional relay caps at a few thousand messages per day, you cannot send a big newsletter.

Architecture B: plugin pushes the list to an ESP

MC4WP with Mailchimp, Brevo's official plugin, ConvertKit's plugin. The plugin syncs your WP subscriber list into the ESP and lets the ESP run the campaign. From a deliverability standpoint the campaign is an ESP campaign, not a WordPress send. DKIM, SPF, IP reputation, unsubscribe handling all live at the ESP.

Architecture C: plugin renders in WP, sends via ESP API

FluentCRM, Groundhogg with Amazon SES or Postmark. The content and segmentation live in WordPress. The actual SMTP handoff is an API call to the ESP per recipient. DKIM is the ESP's; list hygiene is yours.

Why the plugin report is not enough

Every newsletter plugin report surfaces the same numbers:

• Sent: messages the plugin handed to the transport.
• Delivered: messages the transport received a 2xx on from the recipient's MX.
• Bounced: messages that returned 5xx immediately (hard bounce) or were queued and later failed (soft bounce).
• Open rate: messages where a tracking pixel fired.
• Click rate: messages where a tracked link was clicked.

None of these measure folder placement. A message delivered into Gmail Spam counts as "Delivered". A message filtered into Gmail Promotions counts as "Delivered" and may fire the tracking pixel at the moment of image prefetch — producing an "Open" from a mailbox the recipient never looked at. The plugin report tells you what the ESP saw at the handoff. It does not tell you what the subscriber experienced at Inbox level.

Seed injection for newsletter testing

The right test is to have seed addresses receive the actual campaign alongside real subscribers. If the campaign routes through an ESP, seeds need to be in the ESP's list. If it routes through wp_mail, seeds need to be in the WP subscriber table.

1. Get the raw seed addresses from your placement tester. Usually a list of 20+ mailboxes across Gmail, Outlook, Yahoo, iCloud, Mail.ru, Yandex, GMX, ProtonMail, Fastmail, and so on.
2. Add the seeds to your WordPress subscriber table with the same confirmation status as real subscribers. Bypass confirmation flows if possible; you do not want the confirmation email itself to skew results.
3. Tag the seeds with a hidden segment marker so you can target a test send to them or ensure they are included in the live campaign.
4. Send the real campaign. The seeds receive exactly what real subscribers receive — same segmentation, same rendering, same sending path, same DKIM signature.
5. Check the placement dashboard. Per-provider folder verdicts, authentication results, DNSBL status on the sending and tracking domains, and spam engine scores on the rendered content.

# Example: add seeds via MC4WP/Mailchimp API after WP export
curl -X POST https://us10.api.mailchimp.com/3.0/lists/LIST_ID/members \
  -u "anystring:API_KEY" \
  -d '{
    "email_address": "seed-gmail-01@inbox-check.example",
    "status": "subscribed",
    "tags": ["seed", "placement-test"]
  }'

Plugin-specific quirks

MC4WP + Mailchimp

MC4WP is a signup plugin, not a sender. Every campaign ultimately runs in Mailchimp. Mailchimp signs with its own DKIM for the sending domain you authenticate; you publish the DKIM CNAMEs and a SPF include. Placement is entirely about Mailchimp reputation, which in turn depends on the IP pool your account is on and your account-level list hygiene. Moves between shared pools happen regularly; always seed-test after a reputation change notice.

Brevo (formerly Sendinblue) plugin

Brevo provides a WordPress plugin plus a transactional SMTP endpoint. The plugin syncs subscribers and triggers Brevo-side campaigns. Brevo's shared IPs are regionally distributed; EU sending and US sending can behave very differently at the same provider. Seed lists that span regions help.

FluentCRM

FluentCRM is a WordPress-resident CRM that hands off SMTP to whatever provider you configure — SES, SendGrid, Postmark, etc. Reporting is inside WP, authentication is at the relay. Placement depends on the relay's reputation plus your list hygiene inside WP. The plugin does not shield you from relay-side shared-IP events.

Newsletter plugin with Amazon SES

A popular "cheap at scale" combination. SES sandbox mode is a common trap — messages look delivered in the plugin report but are actually restricted to verified addresses. Move to production mode before running real campaigns, and verify the domain for DKIM rather than just individual sender mailboxes.

Frequently asked questions