Klaviyo is not sending unauthenticated mail. If you have not published visible SPF, DKIM, and DMARC TXT records for the exact brand domain you are checking, the pass result usually comes from one of two places: Klaviyo's shared sending domain, or a branded sending domain where CNAME or NS delegation lets Klaviyo publish and control the underlying authentication records.
The part that matters is not the green "pass" label alone. The part that matters is which domain passed SPF, which domain signed DKIM, and whether one of those domains matches the visible From domain for DMARC. Klaviyo's own docs explain that shared sending domain mail is automatically authenticated through SPF and DKIM, and that branded sending domains use CNAME or NS setup to enable authentication.
Fast answer
- Direct answer: Klaviyo can authenticate mail with its own domains when custom authentication is not configured.
- Branded domain: CNAME or NS records can place the working SPF and DKIM records under Klaviyo control.
- Main risk: SPF or DKIM pass on Klaviyo domains is not the same as brand-domain DMARC protection.
- Next step: Inspect full headers and publish a brand-domain DMARC record if it is missing.
What the pass result means
Gmail's Show original view condenses several header checks into a small table. I read that table as a starting point, not as proof that the brand domain has every record in place. SPF checks the envelope sender domain, often the Return-Path. DKIM checks the signing domain in the DKIM-Signature header. DMARC checks whether SPF or DKIM passed with a domain that matches the visible From domain, then applies the policy found at _dmarc.
That means a message can show SPF pass and DKIM pass for Klaviyo-owned domains while the brand domain has no direct SPF include, no DKIM TXT at the selector you checked, and no DMARC record. If DMARC also shows pass, I check the full Authentication-Results line before drawing a conclusion. Sometimes the visible From domain is a Klaviyo-controlled subdomain. Sometimes the branded sending domain is delegated. Sometimes Gmail's summary is less clear than the raw header.
Header fields to inspecttext
Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=send.ksd1.klaviyomail.com; dkim=pass header.d=ksd1.klaviyomail.com; dmarc=pass header.from=example.com From: Brand <marketing@example.com> Return-Path: <bounces@send.ksd1.klaviyomail.com>
In that example, SPF and DKIM pass, but both authentication domains sit under Klaviyo. DMARC only protects example.com if the DMARC result truly uses example.com as the header From domain and at least one passing mechanism matches it. When the row says header.from=example.com, look for the exact result text next to dmarc and the policy tags. If it says bestguesspass or has no policy, treat the domain as poorly monitored until you publish a real record.
|
|
|
|---|---|---|
spf=pass | Return-Path | Envelope domain |
dkim=pass | Signature | header.d |
dmarc=pass | From domain | Domain match |
p=none | Policy | _dmarc |
Read these clues in the raw header before trusting the summary.
Why the DNS records look missing
There are two common setups. The first is shared Klaviyo sending, where Klaviyo authenticates with domains such as klaviyomail.com. The second is a branded sending domain, where you add the records Klaviyo provides and Klaviyo uses that setup to make SPF and DKIM work. The official branded sending domain guide says the setup requires DNS access and uses TXT, NS, or CNAME records depending on the method.
Shared Klaviyo authentication
This is the default path when the account has not finished custom authentication for a branded sending domain.
- SPF: The pass comes from the Klaviyo envelope sender.
- DKIM: The signing domain is often a Klaviyo domain.
- DMARC: The pass only protects the brand when the passing domain matches the visible From domain.
Branded sending domain
This is the preferred setup when the brand wants Klaviyo mail to authenticate with the brand's own sending domain.
- DNS shape: CNAME or NS records can point authentication names into Klaviyo.
- SPF: The bounce domain can be authenticated through delegated DNS.
- DKIM: Selector records can resolve through Klaviyo-managed names.
- DMARC: The policy still belongs at the visible From domain or relevant subdomain.
Klaviyo email domains settings screen for branded sending domain authentication.
If a DNS console only shows a TXT record with an account ID and a few CNAME or NS records, that does not prove SPF or DKIM are absent. Query the final target of the CNAME or the delegated zone. A root-domain SPF lookup also misses mail sent with a subdomain Return-Path.
How to verify the exact domains
I use a four-step check because it separates authentication success from brand-domain protection. Start with one real campaign or flow email, not a preview message, because previews and test sends use different paths in some platforms.
- Send a real sample: Send a live message to Gmail and a second mailbox so you can compare headers.
- Open full headers: Collect Authentication-Results, From, Return-Path, and DKIM-Signature.
- Compare domains: Confirm header.d or smtp.mailfrom matches the visible From domain.
- Query DNS names: Check _dmarc on the From domain, the DKIM selector, and the Return-Path domain.
- Record the policy: Note p=none, p=quarantine, or p=reject, plus any reporting address.
For teams running Klaviyo beside another ESP, this matters more. A single brand domain can have several legitimate senders, and each sender needs a clean path through SPF, DKIM, and DMARC. 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.
The domain check should not replace header analysis. DNS tells you what is published; headers tell you what was actually used by the message. I only trust the result when both sources tell the same story.
After that, use a focused DMARC check on the exact From domain. If the record is missing, malformed, or stuck at p=none with no reporting address, the domain has weak policy visibility even if Klaviyo campaign delivery looks strong.
What to publish if DMARC is missing
If the visible From domain has no DMARC record, publish one. Start at p=none if you have not reviewed every sender yet. This does not block mail, but it starts reporting and gives you the data needed to move toward quarantine or reject without breaking legitimate streams.
Starting DMARC recorddns
Host: _dmarc.example.com TXT: v=DMARC1; p=none; rua=mailto:dmarc@example.com
Once reports confirm Klaviyo and every other sender are passing with matching domains, move the policy in stages. I do not jump straight to reject on a commerce domain unless the sending map is complete, because one forgotten receipt system or support sender can create user-visible failures.
DMARC policy stages
A practical way to move from visibility to blocking after senders are verified.
Monitor
p=none
Collect reports and identify every source.
Contain
p=quarantine
Send failing mail to spam after fixes are complete.
Block
p=reject
Reject mail that fails the policy.
If you need a clean starting record, use the DMARC record generator and then adapt the reporting address to your domain. The important part is ownership: Klaviyo can help authenticate Klaviyo mail, but it cannot own the full DMARC decision for every message that uses your brand domain.
Do not stop at campaign delivery rate
A 98-99% campaign delivery rate is useful, but it does not prove brand-domain protection. A domain can deliver well while spoofed mail still has no enforceable policy.
- Header truth: Read Authentication-Results before changing DNS.
- Domain truth: Check the exact From domain and the sending subdomain.
- Policy truth: Monitor reports before moving to p=reject.
Where Suped fits
Suped's product is relevant when this stops being a one-message investigation and becomes an ongoing control. Suped combines DMARC monitoring, SPF and DKIM visibility, hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, real-time alerts, and blocklist monitoring (blacklist monitoring) in one place. That matters for Klaviyo because the same domain often sends through commerce, support, transactional systems, and marketing systems.
Suped's DMARC monitoring workflow makes the Klaviyo question measurable: which sources send, which pass, which fail, and which fixes are still open. Hosted DMARC also helps when teams want policy staging without repeated DNS tickets.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
For most teams, Suped is the best overall DMARC platform because it gives plain fix steps, parses raw aggregate reports, and connects those findings with hosted controls. MSPs also get multi-tenant dashboards, so Klaviyo checks can sit beside every client domain without mixing data.
Practical workflow in Suped
- Investigation: Confirm whether Klaviyo, the brand domain, or another sender is passing.
- Alerts: Get notified when failures or new sources appear.
- Hosted controls: Stage DMARC and SPF changes without repeated manual DNS edits.
- Reputation: Monitor blocklist and blacklist signals alongside authentication results.
Views from the trenches
Best practices
Check the raw Authentication-Results header before trusting a mailbox UI summary result.
Treat Klaviyo shared-domain passes as delivery support, not brand-domain policy proof.
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 SPF pass means DMARC protection ignores the Return-Path domain check entirely.
Moving to reject before receipts and support streams are verified creates avoidable failures.
Expert tips
Use one real delivered campaign message because preview sends often use different routing.
Compare header.d and smtp.mailfrom against the visible From domain before policy edits.
Keep reporting active after enforcement so new senders are caught before volume grows.
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 from Email Geeks says Gmail's original message view gives the domains that passed DKIM and DMARC, and the raw header is more reliable than the summary table.
2022-08-20 - Email Geeks
Keep the brand domain in control
Klaviyo can send authenticated mail without obvious SPF, DKIM, and DMARC TXT records because authentication can happen through Klaviyo-owned domains or through delegated branded sending-domain DNS. That is normal. The risk is assuming the visible brand domain has a real DMARC policy just because Gmail shows pass.
The practical fix is direct: inspect one real message, identify the exact SPF, DKIM, and DMARC domains, publish a DMARC record if the brand domain lacks one, monitor reports, and tighten policy only after every legitimate sender is accounted for. That keeps Klaviyo deliverability strong while giving the brand domain enforceable protection.
