Kinsta does not bundle mailboxes. WordPress’s outbound mail leaves through a built-in MailChannels relay with authentication wired in automatically, so password resets and order confirmations go out DKIM-signed without an SMTP plugin. The signature is not aligned with the site’s own domain, so a domain that enforces DMARC needs a third-party relay. Outbound port 25 is blocked; the standard submission ports are open, so a plugin swap to a third-party relay is a credentials-and-install job. Kinsta publishes daily caps of 150, 1,000 and 3,000 messages by plan; its list does not yet name the bandwidth-billed Single GB plans. Policy reserves the relay for transactional mail only. The visible trade-off is the “via kinstamailservice.com” line recipients see under the From address on default-path mail, which a brand-conscious operator will want to remove 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 a fresh install starts above a shared host that ships unsigned mail. It does not pass DMARC for the site’s domain, which the authentication section below covers.
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 is a display annotation; Kinsta’s docs treat it as cosmetic, not a delivery failure. It is also 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, Launch, Launch Plus, Build, Expand | 150 |
| Single 125k through 750k, WP 5/10/20/40, Scale, Lead | 1,000 |
| Single 1.25M through 3.15M, Agency 20/40/60, WP 60/80/120/150 | 3,000 |
Kinsta’s list names the visits-billed Single plans; the bandwidth-billed Single 20GB-500GB plans are not on it, so check the cap with support.
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 150-a-day tier 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 say that when a site breaks the policy, support will ask it to find another way to send. The move to a dedicated relay belongs before sending climbs into that territory, not after. Kinsta publishes its built-in relay’s numbers, which not every managed host does: 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.
Source:
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 or Microsoft 365 for full mailboxes; Fastmail 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 DNS 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, receivers see the relay as unauthorised for the domain, and the mail is more likely to land in spam.
Neither record makes the mail DMARC-aligned. DMARC (the policy record that tells receivers what to do with mail that fails authentication) passes only when the domain in the visible From address matches the domain that passed SPF or signed with DKIM. On Kinsta’s default path, the envelope sender sits on kinstamailservice.com, so SPF passes for Kinsta’s domain rather than the site’s, and Kinsta’s documentation describes the DKIM signature as protecting the kinstamailservice.com domain rather than the site’s. Kinsta states the result directly: outbound mail from the transactional email service “does not currently support DMARC alignment,” and the company recommends a third-party SMTP service for anyone who needs DMARC compliance.
That changes how DMARC should be set. A domain with no DMARC record, or with p=none, still gets its mail delivered, and any aggregate reports show it as unaligned. A domain at p=quarantine or p=reject tells receivers to junk or refuse exactly this mail, and Kinsta’s DNS guide says a domain with a DKIM record and p=reject must drop to p=none or remove the DKIM record to use the MailChannels integration. The usual advice to tighten DMARC once reports look clean does not apply to Kinsta’s default path: the reports will never show it aligned. A site that wants an enforced DMARC policy should send through a third-party relay that signs with the site’s own domain.
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 Kinsta’s docs present as a display matter rather than a delivery one; for most operators it is a brand problem. Switching to a third-party relay with a custom return-path domain (Postmark, Mailgun, SMTP2GO all support this) is the only mechanical fix.
When merging include:relay.kinstamailservice.com into a domain’s existing SPF alongside a mailbox provider or a transactional relay, the SPF merger deduplicates the includes and counts the DNS lookups against RFC 7208’s ten-lookup ceiling. Once the record is published, the DNS auth checker reads how the domain’s SPF and DMARC resolve from the receiver’s perspective, so a stale nameserver or a missed record shows up before real traffic does. It has no DKIM record to find for the default path: the MailChannels signature covers kinstamailservice.com, not the site’s domain.
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 documents no customer-facing 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. Kinsta documents no dedicated sending IP; mail leaves through MailChannels’ shared relay. Sites where deliverability isolation matters need a relay that offers one (Postmark once sending reaches 300,000 emails a month; Mailgun on its 100,000-a-month plans and up).
When a third-party relay is needed
Kinsta’s MailChannels integration is enough for sites that fit the transactional definition, stay under the daily cap, and leave their domain’s DMARC policy at p=none or unset. Personal sites, small WooCommerce stores, and membership sites in the low hundreds of daily transactional messages fit on the bundled relay on those terms. Every message leaves DKIM-signed, just not as the site’s domain.
A dedicated relay is the right call when:
- The domain enforces DMARC, or is about to. Kinsta’s default path is not DMARC-aligned, so
p=quarantineorp=rejecton the sending domain puts WordPress mail in spam or gets it refused. A relay that signs with the site’s domain (Postmark, Mailgun, SMTP2GO) passes DMARC; the bundled path cannot. - Volume crosses the daily cap. A site approaching 150 transactional messages a day on the 150-a-day 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 documents none of this for its bundled path.
- 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, whose domain’s DMARC policy is p=none or unset, and that 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 on the plans Kinsta lists. The hard limit is DMARC: Kinsta’s default path is not aligned with the site’s domain, so any domain that enforces DMARC needs a third-party relay from day one. The softer trade-offs are 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.
- 2026-10-29: an earlier version implied that SPF plus Kinsta’s automatic DKIM made default-path mail DMARC-aligned, and advised tightening DMARC to
p=quarantineorp=rejectonce reports looked clean. Kinsta documents that its transactional email service does not support DMARC alignment; on the default path, that advice would put the site’s mail in spam or get it refused.