How does Klaviyo handle domain authentication without SPF, DKIM, and DMARC records?
Published 3 Jun 2025
Updated 19 Oct 2026
12 min read
Summarize with
Updated on 19 Oct 2026: We clarified Klaviyo's DNS setup, SPF lookup errors, and DMARC policy checks for branded sending domains.
Klaviyo can send mail that passes SPF and DKIM even when no SPF or DKIM TXT record appears at the brand's root domain. Shared sending uses Klaviyo's envelope and signing domains. A branded sending domain, also called a dedicated sending domain, uses CNAME targets or NS delegation to make the required records resolve under the brand's domain. DMARC is separate: the visible From domain needs an applicable DMARC policy, and shared-domain SPF and DKIM do not satisfy brand-domain DMARC alignment.
The useful evidence is not the green "pass" label alone. Check which domain passed SPF, which domain signed DKIM, and whether either domain has DMARC alignment with the visible From domain. Klaviyo's own docs explain that shared sending domain mail is automatically authenticated through SPF and DKIM, while branded sending domains use CNAME or NS setup to enable authentication.
Fast answer
- Direct answer: Klaviyo handles SPF and DKIM through shared domains or a branded DNS setup; the authentication records still exist somewhere in the lookup path.
- Shared domain: SPF and DKIM pass on Klaviyo domains, but those passes alone do not satisfy DMARC for a brand From domain.
- Branded domain: CNAME or NS records let Klaviyo provide brand-aligned DKIM and an authenticated sending path.
- DMARC control: The brand controls the DMARC policy, even when Klaviyo generates a starting p=none record during domain setup.
What SPF, DKIM, and DMARC pass results mean
Gmail's Show original view condenses several header checks into a small table. Treat that table as a starting point, not proof that the brand domain has every record in place. SPF checks the envelope sender domain, usually shown in Return-Path. DKIM checks the signing domain in the DKIM-Signature header. DMARC passes when at least one of those mechanisms passes and has domain alignment with the visible From domain.
DMARC uses relaxed alignment by default, so a subdomain and its organizational domain can match, such as send.example.com and example.com. Strict aspf=s or adkim=s requires an exact domain match for that mechanism. If both passing domains sit under klaviyomail.com while the visible From domain is example.com, shared authentication alone cannot produce a standards-based DMARC pass for example.com. A reported pass means the message also has a brand-aligned authentication result or the visible From domain differs from the one assumed.
Illustrative shared-domain header exampletext
Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=send.ksd1.klaviyomail.com; dkim=pass header.d=ksd1.klaviyomail.com; dmarc=fail (p=none) header.from=example.com From: Brand <marketing@example.com> Return-Path: <bounces@send.ksd1.klaviyomail.com>
In this example, SPF and DKIM both pass for Klaviyo domains, but neither result has DMARC alignment with example.com. The p=none policy requests no DMARC-specific handling of failures. Receivers can still filter or reject the message under their own rules. Delivery under this policy does not turn a DMARC failure into a pass.
|
|
|
|---|---|---|
spf=pass | Authentication-Results: smtp.mailfrom | Passing envelope domain |
dkim=pass | Authentication-Results: header.d | Passing header.d domain |
dmarc=pass | Authentication-Results: header.from | At least one passing mechanism with DMARC alignment |
p=none | DMARC policy | No DMARC handling requested for failures |
Read these clues in the raw header before trusting the summary.
Why Klaviyo SPF and DKIM records look missing
There are two common setups. Shared Klaviyo sending authenticates with Klaviyo domains such as klaviyomail.com. A branded sending domain uses records generated for the account. Klaviyo's current setup uses Dynamic routing with up to four NS records or Static routing with up to three CNAME records, plus a TXT ownership record. The branded sending domain guide explains how these DNS record types give Klaviyo the authentication path it needs.
Shared Klaviyo authentication
This is the default path when the account has not activated a branded sending domain.
- SPF: The pass comes from the Klaviyo envelope sender.
- DKIM: The signing domain is a Klaviyo domain.
- DMARC: Shared authentication alone does not pass DMARC for a brand From domain.
Branded sending domain
This setup puts Klaviyo authentication under a sending domain owned by the brand.
- DNS route: Dynamic uses NS delegation; Static uses CNAME targets.
- SPF: The sending path uses the generated DNS configuration, so a new root SPF include is normally unnecessary.
- DKIM: Klaviyo adds a brand-domain signature and can retain a shared Klaviyo signature.
- DMARC: The brand controls the policy, and Klaviyo can generate a starting p=none record during setup.
Klaviyo branded sending domain setup with NS, CNAME, and TXT authentication records.
A DNS console that shows only an account-verification TXT record and several CNAME or NS records does not prove SPF or DKIM are absent. Query each CNAME target or the delegated zone. With Dynamic routing, Klaviyo hosts the delegated subdomain's DNS; records added for that zone at the original DNS provider do not take effect. A root-domain SPF lookup can also miss the result because SPF checks the message's separate Return-Path domain.
How to configure a branded sending domain
Use a branded sending domain under the same organizational domain as the friendly From address so Klaviyo mail can meet DMARC alignment requirements. Reserve an unused sending subdomain for each send type.
- Create the domain: Open Klaviyo directly, rather than Shopify's app settings. Go to Settings > Domains > Add domain, choose the send type, and enter an unused subdomain such as send.example.com.
- Choose routing: Dynamic routing delegates the subdomain with NS records. Choose Static routing, which uses CNAME records, if your DNS provider does not support subdomain NS delegation.
- Decide on DMARC: If no applicable record exists, Klaviyo can generate v=DMARC1; p=none;. Do not publish a second DMARC record at the same host.
- Publish exact values: Add the generated NS or CNAME records and TXT ownership record. Include any generated service-domain MX record. Keep CNAME records unproxied and avoid duplicating the root domain in hostnames.
- Verify the records: Run Klaviyo's verification after publication. DNS propagation can take up to 48 hours, and every returned value must match the generated value.
- Activate and test: Activate the verified domain, follow any warming prompt Klaviyo displays, then send a live message and inspect its headers.
For marketing, a friendly From address such as marketing@example.com can use send.example.com for authentication while replies go to a working mailbox. Service sending domains are an exception: Klaviyo generates an MX record so those domains can receive customer replies. See Klaviyo's setup instructions.
Do not create a second SPF record
Klaviyo normally authenticates SPF through its Return-Path and generated branded-domain setup. Adding another v=spf1 TXT record at a host that already has one creates an SPF permanent error instead of improving authentication.
How to handle spoofing and SPF lookup errors
A missing root-domain SPF record does not mean Klaviyo authentication is broken. SPF checks the envelope sender; DMARC connects a passing authentication result to the visible From domain. Klaviyo's authentication guidance recommends reviewing all senders before enforcing a stricter DMARC policy.
- Keep Klaviyo's NS delegation intact. Names such as ns1.klaviyo.com identify DNS servers, not outbound mail servers. Do not substitute them for an SPF include or publish a second SPF record to resolve a warning.
- Manage root-domain SPF separately. Authorize services that actually use that domain as their envelope sender in its single SPF record. SPF records are not inherited by subdomains, and Klaviyo's delegated sending setup does not authenticate unrelated senders.
- Investigate an SPF permerror at the actual smtp.mailfrom domain. SPF limits DNS-querying terms to 10 across the evaluation, including nested includes. Adding Klaviyo unnecessarily to a root SPF record can consume that budget without helping Klaviyo mail.
- Review unfamiliar sources in DMARC reports before classifying them as spoofing. Forwarding can break SPF while a valid brand-domain DKIM signature still passes. After verifying legitimate senders, use p=quarantine or p=reject to request handling of messages that fail DMARC.
How to verify Klaviyo authentication
Use this five-step check to separate authentication success from brand-domain protection. Start with a live campaign or flow message rather than a preview because test messages can use a different sending path.
- Send a real sample: Send a live message to Gmail and a second mailbox so the received headers can be compared.
- Open full headers: Read the receiving mailbox provider's Authentication-Results, From, Return-Path, and every DKIM-Signature field. Match each passing DKIM result to its signing domain; two signatures do not require two passes.
- Compare domains: Confirm that at least one passing header.d or smtp.mailfrom domain has DMARC alignment with the visible From domain.
- Query DNS names: Query DKIM at <selector>._domainkey.<signing domain>, using the DKIM-Signature s= and d= values. Query SPF at smtp.mailfrom and check the From domain's applicable DMARC policy, including any inherited policy.
- Record the policy: Note p=none, p=quarantine, or p=reject, plus the rua reporting destination and any strict alignment tags.
Use the selector in the actual message. Current Static marketing domains use km1/km2, transactional domains use kt1/kt2, and service domains use ks1/ks2. Older kl1/kl2 selectors remain valid, and additional domains can use later pairs. Follow Klaviyo's generated records rather than replacing working selectors.
Illustrative DNS queries, replace names with received header valuesbash
# Example header values: smtp.mailfrom=bounce.example.com; d=example.com; s=km1 dig +short TXT bounce.example.com dig +short CNAME km1._domainkey.example.com dig +short TXT km1._domainkey.example.com # Check the sending subdomain delegation and visible From domain policy dig +short NS send.example.com dig +short TXT _dmarc.example.com
For teams running Klaviyo beside another ESP, one brand domain can have several legitimate senders. Each sender needs working authentication and at least one passing mechanism with DMARC alignment. The same principle applies in a broader multi-ESP setup.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A domain check does not replace header analysis. DNS shows what is published; headers show what the message used. Trust the result only when both sources identify the same domains and policy.
After that, run a focused DMARC check on the exact From domain, including any inherited policy. If no applicable valid record exists, publish or correct it. A valid p=none record without rua does not request aggregate reports, so it provides no reporting visibility for the brand.
What to publish if DMARC is missing
If the visible From domain has no applicable DMARC record, publish one at _dmarc followed by that From domain, or at its organizational domain for inheritance. A record only on the Klaviyo sending subdomain does not cover a root-domain From address. Start at p=none while reviewing legitimate senders, and add rua to request aggregate reports before moving to quarantine or reject.
Starting DMARC recorddns
Host: _dmarc.example.com TXT: v=DMARC1; p=none; rua=mailto:dmarc@example.com
On an organizational-domain record, p controls that domain. Existing subdomains without their own applicable policy inherit sp, or p when sp is omitted. If rua points to a different organizational domain, the report destination must publish an external reporting authorization record before receivers send reports there. Replace dmarc@example.com in the example with a report-processing address that you control.
Once reports confirm that Klaviyo and every other sender pass with matching domains, move the policy in stages. Avoid p=reject on a commerce domain until the sending map includes receipts, support mail, and other operational streams, because an omitted sender can create user-visible failures.
DMARC policy stages
A practical path from reporting to enforcement after every legitimate sender is verified.
Monitor
p=none
Collect reports and identify every source.
Contain
p=quarantine
Request quarantine for failures after fixes are complete.
Block
p=reject
Request rejection for messages that fail the policy.
For a clean starting record, use the DMARC record generator and set a reporting address controlled by the brand. Klaviyo can authenticate Klaviyo mail, but the brand's DMARC policy covers every message using that From domain.
Do not stop at campaign delivery rate
A high campaign delivery rate does not prove brand-domain protection or inbox placement. With p=none, DMARC requests no action against unauthorized mail that fails authentication. Receivers still apply their own filtering.
- Header evidence: Read Authentication-Results before changing DNS.
- DNS evidence: Check the exact From domain and its organizational domain.
- Policy control: Review reports before moving to p=reject.
Monitor Klaviyo authentication with Suped
Suped's DMARC reporting product handles ongoing monitoring after the one-message header check. It parses aggregate reports so teams can see which Klaviyo sources pass, which domains meet DMARC alignment requirements, and where another authorized sender is failing, without reading raw XML files.
Suped's DMARC monitoring workflow makes the Klaviyo question measurable: which sources send, which pass, which fail, and which fixes remain open. Hosted DMARC supports staged policy changes after the sending inventory is verified.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Aggregate reports describe authentication at source and domain level. They do not show each message's content or prove inbox placement, so use received headers to investigate a specific campaign.
Practical workflow in Suped
- Baseline: Confirm which passing SPF or DKIM domain meets DMARC alignment requirements for the brand's From address.
- Alerts: Notify the responsible team when failures or new sources appear.
- Policy changes: Stage DMARC enforcement after the source inventory is complete; review SPF changes separately for each envelope domain.
- Reputation: Review blocklist and blacklist signals beside authentication results.
Views from the trenches
Best practices
Check the raw Authentication-Results header before trusting a mailbox UI summary result.
Treat Klaviyo shared SPF and DKIM passes as delivery support, not a brand DMARC pass.
Document every legitimate sender before moving a commerce domain beyond monitoring policy.
Common pitfalls
Checking only root-domain TXT records misses delegated CNAME and NS authentication paths.
Assuming an SPF pass proves DMARC ignores the Return-Path domain and alignment checks.
Moving to reject before receipts and support streams are verified creates avoidable failures.
Expert tips
Use one real delivered campaign message because preview sends can use different routing.
Compare header.d and smtp.mailfrom with the visible From domain before policy edits.
Keep reporting active after enforcement so new senders are caught before volume grows.
Marketer view
Marketer from Email Geeks says Klaviyo often authenticates with its own domains when custom authentication has not been configured, so the pass result needs domain-level inspection.
2022-08-20 - Email Geeks
Marketer view
Marketer from Email Geeks says Gmail's original message view identifies the authentication results, and the raw header gives more detail than the summary table.
2022-08-20 - Email Geeks
Frequently asked questions
SPF checks the envelope sender, not the visible From address. In Klaviyo, that envelope sender can use a Klaviyo domain or a branded sending subdomain, so the root domain's SPF record is not the whole test.
Shared sending uses authentication already published for Klaviyo domains. Branded sending uses the NS or CNAME records generated during setup, which make the required SPF and DKIM data available through that DNS path.
A From subdomain can inherit an applicable DMARC policy even when it has no record of its own. If policy discovery finds no valid record, the receiver cannot return a standards-based DMARC pass. Inspect the raw Authentication-Results header if a mailbox summary suggests otherwise.
Move to p=reject only after reports and header checks confirm legitimate senders pass with DMARC alignment. Review forwarding and mailing-list paths as well. Begin with p=none while investigating, then use quarantine before reject if that fits the domain's mail flows.
CNAME targets and NS delegation let Klaviyo supply the underlying SPF and DKIM data for the branded sending domain. The records can authenticate mail even when the brand's DNS console does not show a new v=spf1 TXT value at the root domain.
