MailPoet hosting for a site that is also a mail server's problem.
Sending a newsletter from WordPress turns your website into a bulk sender. The queue, the bounces and the reputation are all now yours to manage.
A send is thousands of small jobs.
One newsletter to forty thousand subscribers is not one task. It is forty thousand, and they all have to happen while the site keeps serving visitors.
A queue that does not stall overnight
Sending progresses in batches driven by the scheduler. On a default install that means it only advances when somebody visits, so a campaign sent at midnight arrives over three days.
Subscriber tables built for the list you will have
Subscribers, segments and per-send statistics grow faster than posts ever will. Those tables are indexed for segment queries rather than left to scan a list that keeps doubling.
Bounces that come back and get recorded
Sending to addresses that no longer exist is what destroys deliverability. Bounce processing is expected to run, so the list cleans itself rather than degrading quietly.
Sending that does not slow the site
Campaign batches and visitor traffic want the same workers. Sending is given its own room, so a newsletter going out is not something readers can feel.
The list is the asset
Subscribers are usually worth more than the content. They are included in daily backups rather than treated as plugin data nobody plans to restore.
Delivery is a rate, not an event.
You do not send a newsletter. You start one, and it drains at whatever rate the queue, the site and the receiving providers allow.
- Queue advanced on a schedule, not by visitors
- Sending resourced apart from front-end traffic
- Bounces processed so the list stays clean
- Subscriber and stats tables indexed
The site stays quick while the list goes out.
The number that matters is not how fast a page renders normally. It is how it renders while forty thousand emails are working their way out of the queue.
What we change for MailPoet
Sending from the site means the site inherits a bulk mailer's problems, and each row here is one of them.
| Setting | What we do | Why |
|---|---|---|
| Queue advancement | Driven by system cron rather than visitor traffic | A default install only moves the queue when somebody loads a page, so a campaign sent overnight trickles out over days instead of hours. |
| Send capacity | Allocated separately from front-end traffic | Campaign batches and visitors compete for the same workers, which is why a newsletter going out is something readers can usually feel. |
| Subscriber tables | Indexed for segment and status queries | Lists, segments and per-send statistics outgrow the content tables quickly, and every send starts by asking who should receive it. |
| Bounce processing | Expected to run and monitored when it does not | Continuing to send to dead addresses is the fastest way to lose deliverability, and the failure is silent until inbox placement collapses. |
| List in backups | Included explicitly rather than as incidental plugin data | The subscriber list is usually worth more than the site's content, and it is the thing nobody realises was not covered until they need it. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Why does my newsletter take days to send?
Will sending slow down my website?
Should I send from my site or use a sending service?
Is my subscriber list backed up?
Send the list without slowing the site.
Move the site across. Migration is free, subscribers included.