Source review dated 8 November 2026. Provider settings and acceptance exercises below are documentary guidance, not executed account, DNS or message tests.
Start with the documented alignment limit
Kinsta's default WordPress transactional email uses MailChannels. Its current documentation explicitly says this route does not support DMARC alignment and recommends an external SMTP service when alignment is required. Do not describe adding an SPF include as a complete custom-domain DMARC solution for that route. Kinsta email documentation.
This guide covers that default sending service, not a separately connected SMTP account or all mail whose DNS happens to be hosted by Kinsta. Record the site, production or staging environment, plugin behavior, visible From domain and current delivery route. A hosting account, a DNS host and a mailbox provider are distinct dependencies.
Identify business-critical messages before choosing a change window. Password resets, order confirmations and form notifications need different functional tests, even when they share one sending library. Name a site owner, DNS administrator and person who can approve a mail-provider change. Keep the previous configuration and any pending message identifiers for recovery.
Separate DNS authorization from the actual identities
Kinsta documents include:relay.kinstamailservice.com for SPF and explains that it must be merged into an existing policy. Its default envelope identity is provider-controlled and cannot be changed through this service. The site's visible From address can be different. Kinsta email authentication.
Before any DNS edit, query the authoritative zone and inventory existing senders. Publish at the intended owner, avoid duplicate SPF records, preserve the approved terminal policy and review DNS-lookup cost. Do not add a or mx merely because a generic example contains them; decide whether those authorizations belong in your domain's policy. SPF specification.
Kinsta's included DKIM support protects its provider signing identity; it does not establish customer-domain aligned signing for the default route. A signature can validate cryptographically while its d= domain remains unrelated to the visible From domain. SPF can similarly pass for a provider envelope without giving the customer an aligned path. Kinsta sending behavior, DKIM and DMARC.
The DNS article also suggests lowering an existing reject policy or removing a DKIM record to accommodate the default integration. Do not use that as a routine fix. Lowering enforcement changes protection for legitimate and impersonated mail across the policy's scope, and deleting another sender's key can break its validation without creating alignment here. Preserve working controls and select a route that can meet the requirement. Provider caveat.
Plan an external route when alignment is required
Choose a supported external SMTP or transactional provider based on the site's volume, required identities, security controls and recovery needs. This article does not establish any particular external provider's account values. Obtain its current setup instructions and publish only the generated domain-authentication records approved for that account.
Decide which WordPress component owns sending. Inventory mail plugins, application hooks and any API integrations before enabling another sender, so the change does not create ambiguous routes or duplicate messages. Preserve the existing configuration and document how queued mail will be handled. Keep credentials out of tickets and message-evidence files; use the integration's appropriate protected configuration.
Configure the desired From address consistently, while retaining a usable reply destination. Test in a safe environment with controlled accounts before enabling the production route. Kinsta distinguishes transactional mail from newsletters and bulk marketing, so do not treat the included service as a general campaign platform. Check current service limits separately rather than assuming a successful test authorizes any volume. Kinsta service scope.
Complete the original site-mail identity table
Original acceptance plan, not an executed test: generate harmless examples of each actual workflow, such as a controlled password reset and a test order that does not incur a charge. Build one received-message identity-table row per environment, workflow and selected route. Record site, timestamp, expected From, actual From, Return-Path, trusted receiver SPF identity/result, all DKIM d=/s= values/results, DMARC result and restricted original-message location.
For the default route, record the documented alignment limitation as an unresolved production requirement when custom-domain alignment is needed. Do not prefill the table with a pass. For a replacement route, require observed aligned authentication, successful application delivery and working reply behavior. Avoid retaining active password-reset tokens or customer order details in a broadly shared evidence package.
If the application reports a send but the receiver has no message, inspect the relevant delivery logs and error response before retrying. If a message arrives but authentication fails, compare the observed identities with the approved DNS owners. Stop the new route if it cannot meet the requirement and use only a previously approved recovery path; do not silently return to an unaligned route for a protected domain.
No Kinsta site, live DNS record, external SMTP account or received message was tested here. The original identity table, selected-provider setup, business-flow checks and human SME approval remain open before production acceptance.