Every self-hosted platform that promises to send your marketing email from its own server is quietly ignoring how mailbox providers actually decide what lands in an inbox. Here's the deliverability reality, and why Stillpoint owns the audience and the journey but hands the send itself to a dedicated provider.
It would be an easy thing to promise: install the plugin, write a campaign, hit send, done. Some tools do promise exactly that. We don't, and it's worth explaining why in enough technical detail that you can actually evaluate the claim, rather than just taking our word for it.
The short version: sending bulk email well is not a feature you bolt onto a web server. It's a discipline that mailbox providers actively police, and the identity a message is sent *from* matters as much as anything in its content. A WordPress install on a shared or generic hosting IP is, structurally, the wrong sender identity for volume email — and pretending otherwise just means your campaigns land in spam while looking, from inside the tool, like they were delivered fine.
The deliverability reality
Mailbox providers — Gmail, Outlook/Microsoft 365, Yahoo and the rest — do not evaluate an email in isolation. They evaluate the sender: the domain, the sending IP, and the authentication attached to the message, built up over a history of previous sends. Three technical mechanisms sit underneath that evaluation.
- SPF (Sender Policy Framework) publishes, in DNS, which servers are allowed to send mail claiming to be from your domain. A receiving server checks the sending IP against that list.
- DKIM (DomainKeys Identified Mail) cryptographically signs outgoing messages with a private key, and the receiving server verifies the signature against a public key published in your DNS — proof the message wasn't altered in transit and genuinely came from a system you authorised.
- DMARC (Domain-based Message Authentication, Reporting and Conformance) ties the two together: it requires that the domain in SPF or DKIM *align* with the domain the recipient actually sees in the From address, publishes a policy for what to do when they don't (quarantine or reject), and gives you back reports on failures.
Get any of that wrong or leave it unconfigured, and mail doesn't bounce with a helpful error — it either lands in spam or is silently dropped, and your tool still shows the send as "complete" because as far as the sending server is concerned, it was.
On top of authentication, mailbox providers track a spam-complaint rate and treat it as close to a hard limit: industry guidance from providers themselves puts the danger threshold at around 0.3% of messages marked as spam. Cross it consistently and your sending domain or IP gets throttled or blocked, and that damage doesn't stay contained to the campaign that caused it — it follows the sending identity into future sends.
And underneath all of that is reputation, which is earned over time and cannot be granted by a plugin update. A brand-new sending IP or domain has no history, so providers deliberately rate-limit and scrutinise it more closely until it proves itself with consistent, low-complaint, well-authenticated volume — a process generally called warm-up. A WordPress server's outgoing mail path was never built for this: it's typically on a shared hosting IP with other customers' traffic, has no complaint-feedback loop wired up, and has no reputation history at all for bulk sending specifically.
What Stillpoint does instead
So we split the problem along its natural seam. Stillpoint owns the audience, the consent record, and the journey logic — everything that determines *who* gets *what* and *when*. Actual delivery of bulk mail is delegated to a send adapter: your choice of SendGrid, Mailgun, Postmark, or Amazon SES over SMTP, all of which exist specifically to solve authentication and reputation at scale, and are what mailbox providers already recognise as legitimate sending infrastructure. For genuinely small lists, a capped direct SMTP option is available where volume is low enough that provider infrastructure is overkill. And where you'd rather run marketing automation as a dedicated concern, you can hand the whole audience off to FluentCRM instead.
To be precise about what that means: Stillpoint does not operate its own bulk-sending infrastructure or claim to guarantee inbox placement, because no honest tool can guarantee that — placement is ultimately the receiving mailbox provider's decision. What Stillpoint guarantees is that the pieces within its control — consent, targeting, journey logic, suppression — are correct, and that the actual transmission goes through infrastructure built and reputationally positioned for the job.
What Stillpoint owns
Dynamic segments
Segments in Stillpoint are built over contacts, deals, order history, and RFM data (recency, frequency, monetary value) for WooCommerce customers — dynamic, meaning a contact moves in or out automatically as their underlying data changes, rather than needing to be manually re-tagged.
Visual multi-step journeys
Journeys are built as a visual sequence of steps with waits (delay for a set period before the next step) and yes/no branching (split the journey based on a condition — opened the last email, made a purchase, matches a segment). That's enough to model a real lifecycle sequence — onboarding, nurture, win-back — without needing code.
Campaign composer, preview and test send
One-off campaigns get a composer with an audience preview, so you can see roughly who a segment will actually reach before you commit to sending, and a test send to check rendering and content on a real inbox first.
Consent tracking
Every contact's marketing consent is tracked with a source (where and how consent was captured) and a timestamp (when) — the pairing regulators and mailbox providers alike expect you to be able to produce on request.
An authoritative suppression list
Unsubscribed, bounced, and complained contacts go onto a suppression list that nothing in the platform can bypass — not a manually rebuilt segment, not a one-off campaign, not a journey step. Suppression is checked before every send, full stop, because a suppression list that can be accidentally overridden isn't actually a suppression list.
One-click unsubscribe and a preference centre
Outgoing marketing mail supports RFC 8058 one-click unsubscribe — the header standard that lets Gmail and other providers render a one-click "Unsubscribe" action directly in their interface, which is now effectively required for bulk senders rather than optional. Recipients also get a preference centre to adjust what they receive rather than only an all-or-nothing opt-out.
Provider webhooks feeding suppression
Your send adapter reports back what happens after transmission — bounces, spam complaints — via webhooks, and Stillpoint feeds those events straight into the suppression list automatically. That closes the loop: the provider does the sending and the signal detection it's built for, and Stillpoint acts on the signal immediately rather than requiring someone to manually reconcile a bounce report.
A practical setup checklist
If you're setting this up for the first time, this is the order that avoids the common mistakes.
- Verify your sending domain with your chosen provider. SendGrid, Mailgun, Postmark and SES all require domain verification before they'll send on your behalf — this is also the step that generates the DNS records you need for the next one.
- Publish SPF and DKIM records in your domain's DNS, using the exact values your provider gives you. Get these wrong and authentication fails silently rather than loudly.
- Set a DMARC record starting at `p=none`. This monitoring-only policy gets you visibility into who's sending as your domain, and reports on SPF/DKIM alignment, without risking legitimate mail being rejected while you're still verifying things are correct. Tighten to
p=quarantineand eventuallyp=rejectonly once you've confirmed alignment is solid. - Warm up a new sending domain or IP gradually. Start with smaller volumes to your most engaged contacts and increase over days to weeks, rather than blasting your full list on day one — this is what builds the sending history providers use to trust you.
- Monitor your complaint rate continuously, and treat anything approaching 0.3% as an emergency, not a metric to review at month end.
- Keep the suppression list authoritative. Never manually re-add a bounced or complained contact to a send just because a segment happens to include them — if you find yourself wanting to override suppression, that's a sign the segment or the campaign needs rethinking, not the suppression list.
The honest summary
None of this is a limitation we'd rather hide. A tool that quietly sent your marketing mail from a generic server, with no authentication story and no reputation history, would look identical in the composer — same audience picker, same send button — right up until the point where opens and clicks mysteriously collapse and nobody can say why. Splitting the responsibility this way costs us a slightly less tidy pitch. It buys you campaigns that actually land.
We could market Stillpoint as sending your bulk email directly, and for a while the demo would look identical to one that actually handles authentication and reputation correctly. The difference only shows up in inbox placement rates weeks later, which is exactly the kind of gap that's easy to paper over and expensive to discover after the fact. Owning the audience, consent and journey logic — and delegating the send itself to infrastructure purpose-built for deliverability — is the version of this we're willing to stand behind. See how the pieces fit together in Marketing Automation, check provider setup in Integrations, and if you're weighing this against a dedicated email tool, our FluentCRM comparison covers the trade-off directly. Pricing is flat regardless of which send adapter you choose — see Pricing.