Kinsta SPF, DKIM and DMARC setup, step by step

Kinsta's built-in transactional email uses MailChannels and automatic DKIM, but Kinsta states that this route does not support DMARC alignment for your custom domain. If password resets, order confirmations or other site messages must authenticate as your brand, configure an external SMTP or API sender, verify its domain records, and test the actual WordPress messages. Adding an SPF include alone cannot change the built-in envelope sender or DKIM identity. Kinsta email documentation

This guide covers mail generated by WordPress hosted at Kinsta. Kinsta DNS is only a possible place to publish records. Your mailbox provider, website host, DNS operator and outbound sender may be four different services.

Decide which Kinsta email route you are using

Start with one message type, not with a DNS generator. Identify the plugin or application generating it, the visible From address and the configured transport. Repeat this inventory for password resets, form notifications, WooCommerce receipts and scheduled jobs. A plugin test can take a different path from a real order notification.

Kinsta supports transactional sending on production and staging sites, does not include mailbox hosting, and restricts the built-in service to transactional mail. Confirm your plan's current sending limits before relying on that route. Kinsta email scope and limits

Create a before-and-after worksheet containing the application event, environment, From domain, transport, provider account, envelope MAIL FROM domain and DKIM signing domain. Do not put passwords, API tokens or customer message content into the worksheet.

Understand the built-in SPF and DKIM boundary

SPF checks the SMTP envelope MAIL FROM domain, usually visible in a delivered message's Return-Path and receiver-added smtp.mailfrom result. It does not authenticate the address displayed in From simply because the two addresses look related. SPF specification

Kinsta's built-in service uses an envelope identity under kinstamailservice.com and automatic provider DKIM. Changing a WordPress sender setting is therefore not evidence that these authenticated identities changed. The documented limitation remains even if a recipient reports spf=pass and dkim=pass. Kinsta transactional email identities

For DMARC, at least one passing identity must align with the visible From domain. A provider-owned identity and example.com are different organizational domains. Neither strict nor relaxed alignment bridges that difference. In contrast, bounce.example.com and example.com can align under relaxed SPF alignment, but not strict SPF alignment. DMARC identifier alignment

For the native MailChannels route, Kinsta's DNS instructions publish the SPF mechanism include:relay.kinstamailservice.com. If your approved sending design requires that authorization at a domain you control, merge that mechanism into its one existing SPF TXT policy at the applicable owner only, after reviewing the actual sending inventory and nested lookup budget. If no policy exists there, have the DNS owner build one for all approved senders and choose its terminal qualifier deliberately. Do not copy the vendor's whole a mx … ~all example over an existing policy: a and mx authorize the applicable addresses of the domain and its mail exchangers, which may not be approved outbound sources. Preserve existing senders, redirect semantics and enforcement. This authorization is not an alignment repair when the message's evaluated envelope domain remains provider-owned; it cannot change that identity or make Kinsta's automatic DKIM branded. Kinsta's native SPF instructions, SPF authorization and evaluation.

Consequently:

• Do not promise branded DKIM completion on the default Kinsta route.
• Do not publish a made-up kinsta selector or upload a private DKIM key to WordPress to fix this limitation.
• Do not add a MailChannels include to your apex solely to repair a message whose evaluated envelope domain is provider-owned.
• Do not delete another service's DKIM records or downgrade an established DMARC policy to accommodate the built-in route. Move the affected mail to a supported aligned sender instead.

Kinsta's DNS page includes advice to remove DKIM or use p=none for the built-in service. Removing a public key does not create alignment, and weakening your domain policy affects more than website notifications. Preserve working controls and resolve the sending route. Kinsta DNS guidance, DMARC authentication model

Prepare an external sender before changing WordPress

Choose a service that supports your mail volume, region, custom-domain DKIM and WordPress integration. Check whether its plan supports the needed domain and bounce-domain features. Obtain access to the sender account, WordPress administration and authoritative DNS. A billing administrator or site editor may not have all three permissions.

Configure the sending domain before switching production mail. The provider must know that it should sign with your domain; publishing a public key without an active signing configuration is insufficient. Kinsta recommends an external SMTP service for aligned mail and links to integration options. Kinsta SMTP options

For a concrete example, an external SendGrid account uses Settings → Sender Authentication → Domain Authentication → Get Started. Select your DNS host, enter the intended From domain and choose the appropriate advanced settings. With automated security enabled, publish the exact generated return-path and DKIM CNAME records, then return to Verify. Use the generated owners and targets, not the documentation's sample account identifiers. Retain an existing DMARC policy rather than overwriting it with the wizard's monitoring example. SendGrid domain authentication

This is an external sending route, not a feature switched on inside MyKinsta. For its provider-specific details, use the SendGrid domain authentication guide. Other senders may issue DKIM TXT public keys instead of CNAMEs and may require a separate activation step. Follow that sender's current workflow.

Publish SPF and DKIM without disturbing existing mail

Find the authoritative nameservers before editing. If Kinsta DNS is authoritative, use the relevant domain in MyKinsta; otherwise use the actual DNS operator. A record in an unused DNS zone has no effect on recipients.

For an already-authoritative Kinsta zone, open MyKinsta → DNS management → the domain → Add a DNS record. On a zone without records, use Add record under Add a DNS record. Select TXT for an SPF policy or direct public DKIM key: enter the relative Hostname, full Content and approved TTL. The TXT form leaves Hostname empty for that zone's main domain and displays the appended suffix. For an issued DKIM CNAME, select CNAME, enter its relative Hostname and exact target in Points to, then choose the approved TTL. Save with Add DNS record, or Change DNS record when editing. Confirm the resulting full owner against the worksheet; do not move nameservers just to use this editor. MyKinsta DNS controls.

Kinsta documents DNS access for Company Owners, Company Administrators and Company Developers. A Site Administrator can manage the zone only when a site they can access is already linked to it; Site Developers do not have Kinsta DNS access. Have an appropriately authorized operator make the scoped change rather than assuming any WordPress or site-level role has permission. DNS role boundary.

For SPF, follow the external provider's instructions for the actual envelope hostname. A provider-managed bounce CNAME may delegate SPF; do not add a TXT record at the same owner. If a TXT policy is required and one already exists there, merge only the necessary authorization into that single policy. Preserve existing senders, redirect behavior and the terminal qualifier. Do not casually change -all to ~all or copy a new whole record over a working policy.

If the existing SPF policy uses redirect=, reconcile its authorizations and terminal behavior with the DNS owner before changing it. Any all mechanism makes redirect ignored regardless of their order. Do not append all automatically: preserve the redirected senders and approved policy semantics through a reviewed design. SPF all and redirect processing.

SPF evaluation permits at most ten DNS-querying mechanisms and modifiers, including nested evaluations. Validate the complete result after a merge; counting the includes visible in your top-level TXT record is not enough. Keep unrelated TXT verification tokens. SPF record and processing rules

For DKIM, retain the provider-generated selector, record type and full value. Publish only public-key material or delegation targets. Keep the private signing key with the sender. Avoid overwriting a selector used by another service. A CNAME cannot coexist with ordinary TXT or other data at the same owner; resolve a collision by obtaining a supported unused selector, not by deleting a working record. DKIM key lookup, DNS alias rule

For an external sender that issues authentication or bounce CNAMEs, including the SendGrid example above, apply these alias safeguards. They do not apply to the built-in route as a way to create branded signing, or to an external provider's direct TXT key. Where the issued authentication or return-path records require literal CNAME answers, use DNS-only aliases returning the exact targets, without an HTTP proxy or flattening hiding them. Turn the relevant per-record Flatten control off when available and ensure applicable zone settings preserve those aliases. Cloudflare documents that flatten-all cannot be overridden per record, apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are conditional DNS-host behaviors, not assumed controls in every panel. If mandatory apex/same-zone behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration with the DNS owner and sender. Do not blindly change the whole zone or remove an existing delegation. CNAME verification, flattening controls and limits.

Kinsta's DNS interface supports TXT and CNAME records for external DKIM. For a long TXT value, its documented input convention omits the opening and closing quotation marks because MyKinsta adds them; put the pair of double quotes only at each boundary between character strings, with no inserted line breaks. Verify the concatenated result is the complete issued key in one logical TXT record, without spaces introduced into p=. The 255-octet limit applies to an individual character string, not the whole DKIM public key. The documentation's sample key and empty Hostname illustrate input formatting, not the selector or value to publish for your sender. Kinsta DNS record entry

Exact owner examples for apex and child domains

These are name-mapping examples, not real Kinsta or provider-issued values. Assume the provider issued selector notify1 for the signing domain stated in each row.

An independently delegated child zone must be edited at its own authoritative DNS service. Entering a full name in an auto-appending field can produce notify1._domainkey.example.com.example.com. Confirm the published fully qualified name, not just the form input.

If _domainkey.mail.example.com is separately delegated, full notify1._domainkey.mail.example.com uses relative notify1 in that zone. Preserve its NS delegation and other selectors; a full-name field takes the complete owner. Use the actual external sender's selector, not this illustration. DNS zone boundaries.

Activate the domain and route the real site events

After DNS resolves, complete the sender's verification and any signing activation. Configure a supported WordPress SMTP or API plugin for that account. Use the sender's actual host, port, encryption and authentication requirements, or its supported API integration. Protect credentials and avoid pasting them into public screenshots.

Set a From address on the authenticated domain. For contact forms, use an authorized site address in From and the visitor's address in Reply-To. A visitor's Gmail address is not a domain you can authenticate for your website.

Check whether plugins override From, select another account or send outside the main mail integration. Test production and staging separately. Do not allow a failed external connection to silently fall back to the unaligned built-in route when brand authentication is required. Record how to restore the previous transport without deleting valid DNS records for other applications.

Retain DMARC policy and add useful reporting

Inspect the policy applying to the visible From domain, including relevant parent policy and sp, adkim and aspf settings. Existing enforcement stays in place while the route is repaired. Only if no direct or applicable inherited policy exists and the domain owner approves a monitoring plan after assessing all senders may this illustrative first TXT record be considered; it needs a real approved reporting destination:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Do not publish the example unchanged. p=none requests no DMARC-specific quarantine or rejection; it does not turn a failing message into a DMARC pass. Confirm reporting is configured and reports arrive before using their absence as reassurance.

Compare the Organizational Domain of the aggregate-report URI's host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as the policy domain is excepted; a different hostname alone does not make it external. Obtain the reporting operator's exact authorization instructions when required. This protocol check is separate from the domain owner's approval to share report data; agree access, retention and privacy. RFC 9990 section 4.

Use aggregate reports to distinguish the new external sender from remaining website traffic on the old route. Review enough traffic to cover scheduled jobs and infrequent notifications before changing enforcement.

Validate public DNS and delivered messages separately

Replace every example name and selector below with the configured values. These read-only commands are a checklist for an authorized implementation, not tests performed for this article.

dig +short NS example.com
dig +short NS mail.example.com
dig +short TXT bounce.example.com
dig +short CNAME bounce.example.com
dig +short CNAME notify1._domainkey.example.com
dig +short TXT notify1._domainkey.example.com
dig +short TXT _dmarc.example.com

Only query the bounce hostname your provider actually uses. For CNAME-based DKIM, confirm the exact target and that its published key resolves. For TXT-based DKIM, confirm the complete key at the selector. Check authoritative DNS and an independent recursive resolver. An empty response is not a diagnosis by itself; distinguish a nonexistent name, missing record type, caching and DNS errors. DNS visibility and the provider's verified status are separate checks.

Next, exercise the actual event paths using controlled test users, approved recipient mailboxes and non-sensitive content. Use a password reset only for a designated test account, a test form notification and, where applicable, a sandbox or other non-charging test order. Do not place a real purchase, contact real customers or disrupt a customer's password merely to test authentication. At the controlled receiving mailbox, inspect raw headers and the Authentication-Results added by the trusted receiver, not an arbitrary earlier header. Authentication-Results trust boundary

Establish which results were generated inside the receiving service's known processing boundary and how it removes, ignores or distinguishes externally supplied Authentication-Results. Use receiver-controlled diagnostics or have the receiving-mail administrator confirm its documented handling. A familiar authserv-id string or header position alone is not proof. Ignore attacker-supplied or otherwise untrusted fields; obtain authenticated receiving-system evidence when provenance is uncertain. Receiver-result trust.

For the external branded route, require all of the following:

1. The intended application event used the intended external account and transport.
2. The intended branded DKIM signature has dkim=pass, and its header.d aligns with the visible From domain under the applied adkim mode. A second provider-owned passing signature is not a substitute.
3. Inspect the actual SPF result and smtp.mailfrom. Investigate fail, softfail, permerror, temperror or unexpected none; an aligned DKIM pass does not excuse a broken SPF configuration. A provider-owned SPF pass without alignment is a distinct result, not an SPF error.
4. The receiver reports dmarc=pass through a known aligned mechanism. Confirm strict or relaxed alignment explicitly.
5. Record delivery or rejection separately. Authentication does not guarantee inbox placement.

The built-in route cannot satisfy the custom-brand acceptance goal documented above. A successful delivery from it is only evidence of that delivery, not proof that the alignment limitation has disappeared.

For the external branded route, keep the approved From unchanged and apply the following independent SPF checks. A rewrite to a provider From cannot satisfy the branded acceptance goal.

Diagnose SPF at the actual envelope owner independently even when aligned DKIM supplies DMARC. For fail or softfail, compare the observed connecting source and MAIL FROM identity with the approved authorization and sending route. For permerror, check duplicate SPF policies, malformed syntax and the full nested DNS-dependent term budget. For temperror, investigate temporary DNS resolution or availability failures and retest after recovery. A provider-owned SPF pass without alignment is different from these failures; escalate errors for provider-owned identities to that sender rather than editing unrelated apex DNS. SPF result definitions.

Troubleshoot Kinsta authentication failures

SPF and DKIM pass, but DMARC fails

Compare the identities. If both passing domains belong to the hosting relay, move the event to the configured external sender. More apex SPF includes do not solve the mismatch.

The external provider is verified, but order messages still fail

Check the receipt plugin, From override, account selection and fallback path. Capture a fresh message after the change. The provider's DNS verification cannot prove that WordPress submitted this event to it.

DNS looks correct in MyKinsta but is absent publicly

Check the authoritative zone, child delegation and duplicated suffix. Confirm whether the field requires a relative name. Then investigate caching and response codes rather than repeatedly recreating records.

Mail stopped after a website DNS migration

Compare the old and new MX and mail-host records. Restore the correct mailbox route through the DNS administrator. Website routing changes do not authorize replacing incoming-mail settings.

Sending stops intermittently

Inspect the actual route's quota, provider events and plugin errors. Kinsta's built-in plan limits and an external sender's limits are different constraints. Do not bypass an account restriction by reverting to an unauthenticated transport.

Documentation review and verification limits

No provider account was configured, DNS changed or test message sent for this article. The examples are illustrative. Validate account-specific values, current plan capabilities, public DNS and delivered headers before treating your implementation as complete.