Kinsta does not bundle mailboxes. WordPress’s own outbound mail goes through MailChannels (the outbound relay Kinsta funnels wp_mail() through) with DKIM (the cryptographic signature receiving servers use to confirm a message came from your domain) wired in automatically, so password resets and order confirmations leave signed without an SMTP plugin. Port 25 is blocked on outbound; ports 465, 587, and 2525 are open, so an SMTP-plugin swap to a third-party relay works directly. Daily limits run from 150 messages on the entry plans up to 3,000 on Agency and top single-site tiers, and Kinsta’s policy reserves the relay for transactional mail only. The visible trade-off is that recipients see a “via kinstamailservice.com” line under the From address on default-path mail, which a brand-conscious operator will want to fix by adding a relay of their own.
Plans renew at $35/month (Single 20GB) and $70/month (WP 2, multi-site), billed monthly or annually with a 15-20% annual discount. Kinsta sits at the premium end of managed WordPress hosting on Google Cloud Platform, alongside WP Engine in the same tier and well above shared hosts like SiteGround and Bluehost.
Email on Kinsta
How wp_mail works by default
A fresh WordPress install on Kinsta sends mail through MailChannels rather than the local server, with no SMTP plugin to install and no relay credentials to add. WordPress core hands the message to wp_mail(), which on this host is wired to ship outbound through Kinsta’s MailChannels integration. The relay signs every message with DKIM automatically, so the deliverability floor on a fresh install is already higher than on a shared host that ships unsigned.
The detail recipients see, and the operator should know about, is the envelope address. SMTP messages carry two From addresses: a header From (the one the reader sees in their inbox, set by WordPress) and an envelope From (the technical address the receiving server uses to bounce undeliverable mail). Kinsta’s MailChannels integration sets the envelope From on kinstamailservice.com, which is correct for bounce handling but causes Gmail and other major clients to render the From line as “[email protected] via mywebsite.kinstamailservice.com.” The “via” notation is a recipient signal that the From and envelope addresses disagree. It does not affect delivery, and it is mechanically unavoidable on any relay where the envelope sender belongs to the relay’s domain. A brand-conscious site will use a third-party relay (with a custom return-path domain) to remove it.
Outbound SMTP port status
| Port | Status | Protocol |
|---|---|---|
| 25 | Blocked | SMTP (legacy) — Kinsta blocks outbound 25 for spam prevention |
| 465 | Open | SMTPS (implicit TLS) |
| 587 | Open | SMTP with STARTTLS — the standard submission port for external relays |
| 2525 | Open | SMTP (alternate) |
Kinsta’s port policy is straightforward: outbound port 25 is closed at the infrastructure level, on the grounds that it is the port most associated with relay abuse. The three modern submission ports (465, 587, 2525) are all open, so any WordPress SMTP plugin that supports authenticated submission (WP Mail SMTP, FluentSMTP, Post SMTP) connects to external services like Postmark and SMTP2GO without trouble. API-based integrations (HTTP, no SMTP at all) work equally well; the choice is operator preference rather than a Kinsta constraint.
Sending limits
| Plan tier | Daily limit |
|---|---|
| Single 35k, 65k, WP 2 | 150 |
| Single 125k through 750k, WP 5/10/20/40 | 1,000 |
| Single 1.25M through 3.15M, Agency 20/40/60, WP 60/80/120/150 | 3,000 |
| Enterprise | Custom |
The limit is a daily ceiling across the plan, not per site. A WP 5 plan running five sites shares the same 1,000-a-day pool. For a low-traffic site (a handful of WooCommerce orders, registration emails, password resets), the entry tier’s 150-a-day is comfortable headroom. Membership sites with active onboarding, contact-form-heavy sites, and any flow that emits a notification on user activity reach the 150 ceiling fast, and Kinsta’s 
transactional email docs recommend moving to a dedicated relay before sending climbs into that territory rather than after. Among managed WordPress hosts, Kinsta’s published numbers are the most generous for a built-in relay: WP Engine uses MailChannels too but does not publish a daily cap, and SiteGround caps at 400/800 messages per hour through a different stack.
Kinsta’s servers should not be used to send non-transactional email. Marketing emails, newsletters, and similar bulk sends fall outside the transactional email service.
—
Treat the cap as the technical ceiling and the policy as the editorial one. Even on the 3,000-a-day Agency tier, broadcast and newsletter traffic belongs on a marketing platform, not Kinsta’s relay.
Mailboxes, forwarding, DNS
Kinsta does not bundle email hosting. There are no mailboxes at [email protected], no IMAP or POP3 to point a mail client at, no webmail interface, and no forwarding rules. The platform’s own email documentation is explicit: hosting and email are kept separate by design, and Kinsta recommends sourcing mailboxes from a dedicated provider. Practical options for the receiving half of domain email: 
Google Workspace at $7/user/month or Microsoft 365 at similar pricing for full mailboxes; Fastmail from $5/user/month for an independent mailbox provider; or a forwarding service (ImprovMX, Forward Email) when the domain only needs to receive at a few addresses without full inboxes.
MyKinsta exposes DNS hosting for any domain pointed at the platform, with the standard A, CNAME, MX, and TXT record types editable in the dashboard. SPF, DKIM, and DMARC records are added there for any domain Kinsta is authoritative for. If DNS lives elsewhere (Cloudflare is the common one), the records are added at that provider instead; the MailChannels SPF include is the same either way.
Authentication (SPF, DKIM, DMARC)
The MailChannels integration handles DKIM signing automatically. There is no DKIM record for the operator to publish; Kinsta’s setup guide confirms that “through our MailChannels integration, DKIM is enabled automatically on the server, no manual DNS setup required.” The DKIM signature applies to every message routed through wp_mail() on the default path.
SPF (the DNS record listing which servers are authorised to send mail under the domain) is the one record the operator must publish themselves. Kinsta does not auto-publish it. The required include is relay.kinstamailservice.com, added either as a fresh SPF record (v=spf1 a mx include:relay.kinstamailservice.com ~all) or merged into an existing one. Without it, MailChannels’ DKIM signature still validates, but the SPF check fails, and providers that require both SPF and DKIM alignment for DMARC will mark the mail as non-aligned.
DMARC is treated as the operator’s call. Kinsta does not publish a default policy; a site that has set up SPF and DKIM correctly can add a _dmarc TXT record at whatever level fits the risk appetite. p=none with a rua= reporting address is the conservative starting position; tightening to p=quarantine or p=reject belongs after aggregate reports confirm clean alignment.
The recipient-visible quirk to plan around is the “via kinstamailservice.com” line. The envelope From on the MailChannels relay is *.kinstamailservice.com, not the operator’s domain. Gmail in particular surfaces this as a “via” annotation under the sender name, which is not a deliverability problem but is a brand one. Switching to a third-party relay with a custom return-path domain (Postmark, Mailgun, SMTP2GO all support this) is the only mechanical fix.
What Kinsta does not provide
- Mailboxes at the hosted domain. No inboxes, no webmail, no IMAP or POP3. Fastmail, Google Workspace, or a forwarding service (ImprovMX, Forward Email) fills the gap.
- A custom return-path domain on the default path. The MailChannels envelope From sits on
kinstamailservice.com, which produces the “via” annotation in recipient inboxes. Third-party relays (Postmark, Mailgun, SMTP2GO) expose this setting; Kinsta’s bundled path does not. - Marketing or bulk email allowance. The transactional policy explicitly excludes newsletters and campaigns. A dedicated marketing platform (Mailchimp, MailerLite, ConvertKit) is the route for broadcast traffic.
- Per-message delivery logs and bounce tracking. Kinsta surfaces no log of what was sent, what bounced, or what hit spam. A relay with webhook delivery events (Postmark, Mailgun) is the way to get that visibility.
- A dedicated sending IP. MailChannels’ relay shares IP reputation across many tenants. Sites where deliverability isolation matters need a relay with a dedicated-IP add-on (Postmark on the Dedicated IP plan; Mailgun on Foundation).
When a third-party relay is needed
Kinsta’s MailChannels integration is enough for most sites that fit the transactional definition and stay under the daily cap. Personal sites, small WooCommerce stores, and membership sites in the low-hundreds of daily transactional messages sit comfortably on the bundled relay, with deliverability that is competitive precisely because every message leaves DKIM-signed.
A dedicated relay is the right call when:
- Volume crosses the daily cap. A site approaching 150 transactional messages a day on the entry tier, or one that needs broader headroom, should move to a relay with a higher ceiling and per-message billing. SMTP2GO is the cheapest credible option; Postmark is the cleanest fit for transactional under 100,000 a month; Mailgun is where higher volumes make economic sense.
- The “via kinstamailservice.com” annotation is unacceptable. A relay with a custom return-path domain, configured to match the brand domain, removes the annotation. This is a fix only a third-party relay can apply; the bundled MailChannels path cannot be retargeted.
- Delivery visibility is required. Per-message delivery, bounce, and complaint events arrive as webhooks from Postmark, Mailgun, and SMTP2GO, with searchable logs and aggregate dashboards. Kinsta’s bundled path surfaces none of this.
- The site needs marketing or newsletter sending. Kinsta’s policy treats this as out of scope. A marketing platform (Mailchimp, ConvertKit, MailerLite) handles broadcast traffic; a dedicated transactional relay handles the transactional half.
Because Kinsta keeps the standard submission ports open, an SMTP plugin connecting to any of the providers above works without an API-only constraint. SMTP is simpler to set up; the providers’ HTTP APIs hold up better when DNS or network changes shift things around. Both work.
Verdict
Kinsta is the right pick for managed WordPress sites that want transactional email working out of the box and are content to source mailboxes separately. The MailChannels integration handles DKIM automatically, the open submission ports keep the relay swap path clean, and the published daily caps are generous enough for most single-site traffic. The trade-off is the “via kinstamailservice.com” annotation in recipient inboxes and the no-mailbox stance: a brand that needs both a custom return-path domain and full domain email will end up paying for a relay and a mailbox provider on top of the hosting bill, which together can match or exceed the cost of the Kinsta plan itself. For the WordPress email setup that supplements Kinsta’s default path, see how to configure WordPress email.
Corrections
- 2026-06-18: an earlier version stated SMTP ports 25, 465, and 587 were all blocked on Kinsta; only port 25 is blocked, and 465, 587, and 2525 are open.