To authenticate Klaviyo email, configure a branded sending domain, publish the exact DNS records issued for that domain, and verify and activate it. Do not add a separate root SPF record for Klaviyo. Its CNAME or NS setup connects your sending domain to provider-managed SPF and DKIM. The ownership-verification TXT record is not an SPF policy. Finally, inspect a delivered message to confirm the identities align with your visible From domain. Klaviyo authentication overview, DNS and SPF guidance.
Choose the email type before choosing DNS records
Klaviyo now supports branded sending domains for marketing, transactional and service email. Do not assume the domain used for a newsletter also covers a Helpdesk reply or a transactional message. Record the email type, account, From address, routing method and sending subdomain for each route you will validate. A branded domain is also not the same thing as a dedicated IP or a click-tracking domain. Current branded-domain setup.
The transactional domain can carry only flow messages explicitly designated as transactional; campaigns are not eligible. Service applies to Klaviyo Helpdesk, including Customer Agent replies, or the free Inbox tier. Enable inbound email in the account's email settings before selecting Service during domain setup. If the account does not use those service features, do not add a Service domain merely to authenticate marketing mail. Send-type eligibility.
Start with a domain you control, an unused sending subdomain, DNS access, permission to edit Klaviyo domain settings, and a recipient mailbox for header inspection. The documented eligible roles are Owner, Admin, Manager and Campaign Coordinator. Use separate subdomains for the different send types; the account's branded sending domains must share its root domain.
Before reserving a name such as send.example.com, ask whether it already serves a website, receives mail, supports another sender, or contains records for another application. This fictional example is an architectural illustration, not a name to publish. Inventory the whole subtree before delegating it, not just the owner name visible in the DNS editor.
Save the current records and identify who approves the cutover. If an agency operates multiple accounts, record which account generated each value. Authentication details that look almost identical can still belong to different sending configurations.
If GoDaddy is your authoritative DNS host, use the GoDaddy DNS publishing guide for that editor. Klaviyo's account-issued records remain the source of truth; do not move authority to follow another panel's instructions.
Generate the correct records in Klaviyo
Open the company's Settings → Domains area and choose Add domain. Select the email type, confirm the root domain, choose the unused sending subdomain, then select Dynamic or Static routing. The setup offers manual publication or eligible automatic setup through Entri. Review the proposed DNS changes before authorizing automatic access. Official setup workflow.
Both Dynamic and Static routing require the root-domain ownership-verification TXT record in addition to their NS or CNAME records. Copy the complete record set from this account into a worksheet. For every row, retain its purpose, type, owner, value and routing method. Separate ownership verification from authentication and routing. Do not copy example targets, public API-key placeholders or selectors from a tutorial as if they were account values.
For manual setup, give the DNS administrator the complete owner names as well as the values. Explain whether the DNS editor expects a relative label or a fully qualified name. Keep that worksheet as the source of truth through verification; do not mix records from an earlier setup attempt with records generated after changing the subdomain.
Dynamic routing and Static routing are different designs
Dynamic routing delegates the sending subdomain to Klaviyo with NS records. Klaviyo then answers DNS queries for that subdomain and names beneath it. Adding an extra record for that delegated subtree at the original DNS provider does not make it authoritative. Use Klaviyo's Manage DNS zone interface when appropriate for that delegated zone. Root-domain records, including root mailbox records, remain with the root domain's DNS provider. Managing a Dynamic domain.
This delegation is not permission to replace your domain's registrar nameservers. Publish only the NS owner and values generated for the sending subdomain. If your DNS provider cannot publish the required subdomain delegation, choose the supported Static workflow rather than changing unrelated infrastructure.
Before publication, the DNS owner must approve the exact delegated child and complete generated NS target set, including every existing service beneath it. Compare the full delegation owner and all targets at the parent authority and an independent recursive resolver with that approved plan before activation. Stop on missing, extra or unapproved entries. A generated packet is not separate authorization to transfer control of the namespace; preserve root DNS, DNSSEC and unrelated mailbox routes.
Static routing uses account-generated CNAME records and a root ownership-verification TXT record. The CNAMEs connect sending and signing names to Klaviyo's managed infrastructure. The current documented record families distinguish marketing selectors km1/km2, transactional kt1/kt2, and service ks1/ks2; additional domains can receive subsequent pairs. Older Static domains using kl1/kl2 remain supported. These names describe families, not a replacement for the exact values issued to your account. Current DNS troubleshooting and selector guidance.
Do not change a working legacy selector merely to match a new screenshot. For Static service domains, follow the generated CNAME/TXT set; Klaviyo manages inbound MX configuration, so do not add a separate MX record alongside that alias. Service and legacy setup notes.
Publish safely and preserve other senders
A CNAME cannot share an owner with ordinary TXT, MX or other records. Stop on a conflict and determine what already uses the name. Adding a new authentication route is not a reason to delete your employee-mail MX records or another sender's key. DNS alias rules.
The DNS host field and destination field have different meanings. If your editor appends example.com, a full hostname entered as a relative label can create example.com.example.com. Conversely, an editor requiring a full name will not understand a bare label the same way. Check the final public lookup name, rather than assuming the form saved what you intended. Keep Klaviyo CNAMEs DNS-only, with any CDN proxy disabled: proxying prevents verification. Allow up to 48 hours for DNS changes to propagate, but correct a known wrong record rather than simply waiting. Official DNS troubleshooting.
For an illustrative issued owner SELECTOR._domainkey.news.example.com, a suffix-appending editor for example.com uses SELECTOR._domainkey.news; one for a separately delegated news.example.com zone uses SELECTOR._domainkey. If _domainkey.news.example.com itself is delegated, use relative SELECTOR in that zone. A full-name field takes the complete issued owner. Replace the placeholder with the actual account selector, preserve existing NS delegations and active selectors, and publish with the actual authority rather than adding an inactive parent-zone copy. DNS zone boundaries.
For Static routing's required aliases only, apply these controls; Dynamic NS delegation is not a CNAME and should not be replaced with one. 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.
Leave the existing root SPF policy intact. Klaviyo's verification TXT can coexist with SPF because it is a different TXT record, but two records beginning v=spf1 at the same owner are not valid SPF configuration. For unrelated sender changes, evaluate the complete SPF policy and its ten DNS-querying-term limit, including nested includes. Do not use this setup as an excuse to expand authorization unnecessarily. SPF standard.
Preserve DMARC and evaluate alignment correctly
DMARC passes through either a passing, aligned SPF identity or a passing, aligned DKIM signature. SPF evaluates the envelope MAIL FROM domain, normally reflected in Return-Path; DKIM supplies the signing domain in d=. Neither is automatically identical to the visible From address. Relaxed alignment accepts the same organizational domain, whereas strict alignment requires an exact domain match. DMARC, RFC 9989.
For example, an envelope domain beneath example.com may align with From example.com under relaxed SPF alignment, but not strict alignment. This is an illustration, not a claim about the domain a particular Klaviyo account will emit. The delivered message settles that question.
Keep an existing direct or applicable inherited DMARC policy and authorized reporting destinations. Do not duplicate or weaken a working policy. Current RFC 9989 replaces RFC 7489 and removes pct; do not rely on that obsolete tag for a new rollout.
Only if no direct or applicable inherited DMARC policy exists, and the domain owner approves a monitoring plan after reviewing legitimate senders, a first TXT policy for fictional From domain example.com may be v=DMARC1; p=none at full owner _dmarc.example.com. The minimal value requests no reports; provision an approved reporting destination and review process before adding rua. Preserve established enforcement and authorized reports.
For a first policy at full owner _dmarc.example.com, a relative-name field in zone example.com takes _dmarc. For a deliberately approved child policy at _dmarc.news.example.com, use _dmarc.news in the parent zone or _dmarc in a separately delegated news.example.com zone. A full-name field takes the complete owner. These examples do not authorize overriding an inherited policy.
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.
Verify DNS and activate the selected route
Adapt these read-only queries using the actual generated names. They are examples, not reported test results:
dig +short NS SENDING_SUBDOMAIN
dig +short CNAME GENERATED_CNAME_OWNER
dig +short TXT VERIFICATION_OWNER
dig +short TXT _dmarc.FROM_DOMAIN
Run the NS check for Dynamic routing and the CNAME check for Static routing. Compare answers with the worksheet, including every required record. An ownership TXT value only proves that particular token is published. For a CNAME DKIM record, resolve its target's public-key TXT data as well. For delegated DNS, query the authoritative service for names inside the delegated zone.
For manual setup, return to Klaviyo and select Verify after publishing the records. With Entri, verification starts automatically. Select Finish to return to Domains while checks continue. Verified means the records are valid and the domain is ready to activate, not that it is already sending. Verifying means checking is ongoing; Action required or Failed requires investigating and correcting the records. Once verified, select Activate on that domain's row. For the first domain of that email type, confirm with Activate in the dialog and check the completion status. Verification and activation states.
For a first marketing branded domain, plan the vendor-recommended pause of flows and campaigns around activation and testing. A separate transactional or service activation on an account with an active marketing domain does not require pausing marketing. Review the current warming guidance for your account history rather than assuming all existing senders must restart. Activation and transition guidance.
When replacing an existing domain, activation follows the transition options offered for that account, rather than the first-domain confirmation alone. If offered, choose the approved Move traffic with domain warming or Move all traffic now path, then Activate and complete its confirmation. If Klaviyo presents a required warming confirmation instead of a choice, follow that supported transition. During a gradual move, the old domain remains Active while the new one is Warming; completion makes the new one Active and removes the old domain automatically. An immediate move also removes the old domain when activation completes. Review the service and tracking dependencies below before either transition. Replacement-domain lifecycle.
For marketing and transactional From addresses, use a reply-capable root-domain mailbox rather than the sending subdomain. Service domains differ: Helpdesk uses the service subdomain for sending and receiving replies. From-address guidance.
Before deactivating, deleting or replacing a Service domain, plan for replies still addressed to its old customer-facing address: deactivation stops it receiving customer email, and removal also ends that inbound route. Deactivating or removing a domain with associated dedicated click tracking also removes that click-tracking domain. Inventory those dependencies, affected addresses, outstanding conversations and previously sent links; obtain the responsible owners' approval and arrange a supported continuity and recovery plan before proceeding. Keep current DNS/configuration evidence and verify the replacement paths before retirement. Do not assume the old domain or tracking configuration will remain available after Klaviyo's automatic transition cleanup, or that restoring a DNS row alone restores the application configuration. Service and tracking migration consequences.
Test delivered messages for every email type
Send authorized representative mail to a controlled external mailbox. Inspect a marketing campaign, transactional message or service reply as applicable, not merely a preview from an unrelated route. Keep the message source and date, with recipient personal information redacted before sharing.
In the recipient-added Authentication-Results, locate SPF, DKIM and DMARC results. Compare smtp.mailfrom with the visible From domain, then inspect DKIM's d= and s=. A passing signature from an unrelated domain is not aligned. A green DNS indicator cannot show whether a particular campaign used the newly activated route. Klaviyo's header-verification guide.
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 this branded DKIM setup, require the intended Klaviyo signature to report dkim=pass and align with the unchanged approved branded From under the effective adkim policy, together with trusted receiver dmarc=pass for that From. Record the expected and observed d= and s=. A rewritten provider From, unrelated passing signature or SPF-only DMARC pass does not complete the intended DKIM deployment. DMARC itself permits either aligned passing method; this is the commissioned signer’s acceptance gate. Query the selector actually used as SELECTOR._domainkey.SIGNING_DOMAIN; do not guess which key signed the message.
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.
Record one acceptance row per email type: account, domain, selector, envelope identity, authentication results, alignment mode and sample date. This prevents a successful newsletter test from silently becoming approval for an untested service-email configuration.
For Service, also conduct a controlled inbound reply check: send an authorized support reply to an approved test mailbox, reply from that mailbox to the intended service address, and confirm the response appears in the expected Helpdesk/Inbox conversation. Record the actual inbound destination separately from the outbound authentication results. Use non-sensitive test content, not a real customer conversation. If changing service domains, include the approved handling of replies to the former address in the migration acceptance plan; outbound DKIM success alone does not prove customer replies still arrive. Service-domain inbound behavior.
Troubleshooting and frequently asked questions
Why is my verification TXT not an SPF record?
They serve different purposes. The Klaviyo ownership token identifies domain control; a policy beginning v=spf1 authorizes SPF senders. Do not merge their contents or replace one with the other.
Why do DNS changes under my Dynamic domain disappear?
Check which server is authoritative. The delegated subtree is hosted by Klaviyo, while its NS delegation remains at your DNS provider. Inspect Manage DNS zone and do not try to overwrite locked provider-managed sending records.
Why does an older guide show different selectors?
Klaviyo distinguishes current send types and supports older Static configurations. Match the active account's generated records and the delivered signature, not a tutorial's sample.
Why does verification pass but DMARC fail?
Check the actual From address, send type, activation state and alignment mode. A different brand domain or a strict-alignment mismatch can explain a failure even when the public records exist.
Should I remove the old domain immediately after switching?
Do not manually remove an old domain simply because a DNS check passes. Inventory outstanding customer replies, dedicated click tracking and delegated-zone integrations before starting the replacement. Klaviyo removes the old domain automatically when the transition completes, ending its inbound Service route and removing associated dedicated click tracking; plan continuity and recovery before that point. Domain replacement and removal.
Does successful authentication guarantee inbox placement?
No. Consent, complaints, engagement and sending practices still matter. Diagnose reputation separately instead of repeatedly changing working DNS.
No customer account configuration, public customer DNS check or delivered-message test was performed for this guide.