Klaviyo · Cloudflare · DMARC alignment Record counts, roles, send types and the NS pattern re-verified against Klaviyo Help Center setup and troubleshooting pages, 20 October 2026.
Klaviyo emails failing DMARC — and your DNS is on Cloudflare? The branded sending domain, set up the current way
First published 20 October 2026 · Verified against Klaviyo Help Center and Cloudflare developer documentation (cited at each step). Klaviyo changed this setup — older guides describe a flow that no longer exists.
DMARC Authentication-Results on a Klaviyo campaign
spf=pass · dkim=pass · dmarc=fail — everything “passes,” and the message still fails. The passes are real; they are just on Klaviyo’s domains, not yours.
DMARC does not ask “did a check pass?” It asks “did a check pass on the domain in your From address?” On Klaviyo’s shared sending setup, nothing passes on your domain — so the moment your domain enforces DMARC, your own campaigns fail it. The fix is Klaviyo’s branded sending domain:
In Klaviyo: your company name (bottom left) → Settings → Domains → Add Domain. The branded domain is always a subdomain (for example send.yourdomain); your From address stays on your root domain.
Choose Dynamic (recommended — you delegate the subdomain with NS records and Klaviyo maintains the authentication records) or Static (the CNAME records Klaviyo lists for your account).
On Cloudflare, every record involved stays DNS only, and CNAME flattening must not touch them — Cloudflare itself warns flattening can fail third-party verification.
Your root keeps exactly one DMARC record. The subdomain inherits it — two records anywhere in the chain means DMARC is not applied at all.
Alignment is the whole story. The branded setup gives Klaviyo a DKIM signature on your domain — and one aligned pass is all DMARC asks for.
First, prove this is your problem (3 minutes)
Send a Klaviyo test or campaign to a Gmail address you control. Open it, choose Show original.
Read the three verdicts and the domains beside them. The shared-setup signature is unmistakable: spf=pass and dkim=pass naming Klaviyo domains, dmarc=fail naming yours.
If instead a verdict names your domain and fails, your problem is a record problem, not the shared setup — the ladder at the end separates the two.
The fix
Step 1 — Add the branded domain in Klaviyo
Open the menu under your company name (bottom left) → Settings → Domains → Add Domain. (Older guides send you hunting through email settings for CNAME screens; the current flow lives here, and the records it issues are per-account.)
Enter a subdomain of the domain your From address uses — Klaviyo’s model is a sending subdomain such as send., with the visible From staying on your root. Do not plan to send From the sending subdomain; Klaviyo explicitly warns against it.
Pick Dynamic if offered: you will add NS records delegating that subdomain, and Klaviyo then creates and maintains its own authentication records — nothing for a DNS edit to break later. Pick Static if you prefer records you control, and copy exactly the CNAMEs Klaviyo lists for your account.
Add the root TXT verification record Klaviyo shows, if asked. Values are account-specific; never copy another store’s.
Klaviyo → Settings → Domains — interface map drawn by Merroway from Klaviyo's documented flow
Open1Your company name (bottom left) → Settings → Domains → Add Domain
Send type2Marketing · Transactional · Service — one subdomain per type
Sending domain3An unused subdomain — e.g. send.yourdomain (never the root)
Routing4Dynamic (NS delegation, recommended) or Static (CNAMEs you control)
Klaviyo issues4 NS or up to 3 CNAME records + 1 root TXT verification — all per-account values
Next →
Do this: keep Klaviyo's record list on screen while you work in Cloudflare in the next step — every value comes from that list, nowhere else.
Step 2 — Cloudflare, without the two traps
Cloudflare behaviour
What it does to this setup
Your setting
Proxy (orange cloud)
Verifiers query the record and meet Cloudflare instead of the target — verification and mail checks fail on records that “look right.”
Every authentication record: DNS only (grey cloud).
CNAME flattening
Cloudflare answers with the target’s A records instead of the CNAME itself. Cloudflare’s own docs warn this “may cause the verification to fail since the CNAME record itself will not be returned directly.”
Do not flatten these records; apex flattening defaults do not excuse subdomain records.
Read-back differences
Cloudflare displays names relative to your zone — a record entered as send is send.yourdomain; a full name typed into the wrong field doubles silently.
After saving, read every record back and compare against Klaviyo’s list character by character.
Cloudflare → DNS → Add record — the Dynamic pattern (×4 records, all DNS only)
Type1NS
Name2send — the subdomain only (Cloudflare shows it as send.yourdomain)
Nameserver3ns1.klaviyo.com — then repeat with ns2, ns3 and ns4.klaviyo.com
ProxyNS records cannot be proxied — and every CNAME in the Static route stays DNS only
Save ×4
Do this: delegation is all-or-nothing — all four NS records, exact names. Static route instead? Same discipline: up to 3 CNAMEs, copied character-perfect from your Klaviyo list, grey cloud on every one. Field map drawn by Merroway; nameserver pattern is Klaviyo's published one.
Step 3 — DMARC: one record, inherited
Your root domain must have exactly one DMARC record — the one your Google Workspace or Microsoft 365 setup already uses counts in full. The sending subdomain inherits the parent policy (tighten it later with an sp= tag or its own record if you ever need to).
If the root has no DMARC record at all, add one TXT at _dmarc: v=DMARC1; p=none; to start, then climb with our safe rollout guide.
Never create a second DMARC record “for Klaviyo.” The specification is blunt: if policy discovery finds multiple records, DMARC processing is not applied — the domain ends up with no DMARC at all.
Step 4 — Activate and wait honestly
Return to Klaviyo and complete the activation step for the domain; Klaviyo verifies the records itself.
Expect DNS propagation time, and expect a warm-up reality on a new sending subdomain: authentication can be perfect while inbox placement builds over the first sends. Authentication is binary; reputation is earned.
Sources: Klaviyo Help Center — branded sending domain setup and verification guidance (help.klaviyo.com) · Cloudflare developer docs — proxy status, CNAME flattening and its third-party-verification warning · RFC 7489 §6.6.3 (single-record rule, subdomain inheritance) · Google DMARC guidance on subdomain inheritance.
Do this: read the domains, not just the verdicts. Two honest passes on Klaviyo's domains plus one fail on yours is the shared-setup signature — nothing is broken; your domain simply isn't in the authentication at all. Sample values; the Klaviyo domain names on yours may differ.
Two choices inside that flow deserve a deliberate answer. Send type — Klaviyo asks whether this domain is for Marketing, Transactional or Service mail, and the professional pattern is a separate subdomain per type (send. for marketing, updates. for transactional), so one stream's reputation never drags the other. Service domains are the exception to remember: Klaviyo also generates an MX record for them, so the domain can receive replies. And know the shape of what you'll be pasting: Klaviyo requires up to 3 CNAME records (Static) or 4 NS records (Dynamic), plus one TXT record at your root — klaviyo-site-verification= followed by your account's public API key. (Some accounts are offered automatic setup through Entri instead; on Cloudflare, the manual records below are the path this guide verifies.)
Don't see Add Domain? Klaviyo only offers branded-domain setup to account roles Owner, Admin, Manager or Campaign Coordinator. Anyone else can look at the Domains page all day — the control simply isn't there. Ask the account owner to run this step, or to raise your role first.
Prove it worked
Klaviyo shows the branded domain as verified/active for the account.
A fresh campaign to Gmail: Show original reads dkim=pass with a signature domain under yours (Klaviyo dual-signs: your domain in addition to a shared Klaviyo domain), and dmarc=pass.
Your normal business email is untouched: nothing in this setup edits your root SPF, your Workspace/M365 DKIM selectors, or your one DMARC record. If business mail broke during a “Klaviyo fix,” someone edited a shared record — check DMARC count first.
Do this: compare with the failing sample — the verdicts look similar, but now a pass carries your domain (Klaviyo dual-signs, so a Klaviyo signature may appear alongside yours; yours is the one DMARC counts). Sample values.
Still failing? Work this ladder in order
Records proxied or flattened. The Cloudflare pair from Step 2 — responsible for most “everything looks right” failures. Grey cloud, no flattening, read back.
Record on the wrong name. Compare the read-back against Klaviyo’s list: a missing subdomain level or a doubled domain is a silent non-match.
Two DMARC records. One added “for Klaviyo” beside the original. Delete the duplicate; keep the established one.
Strict alignment set years ago. If your DMARC carries adkim=s, DKIM must align exactly; subdomain-based sending can fail it. Relaxed (the default, tag absent) is what sender platforms are built for — change it knowingly, not by deleting DMARC.
Verified in Klaviyo but cannot activate. A known pattern in Klaviyo’s own community: records verify, the activation control stays disabled, and the resolution runs through Klaviyo support. Once DNS is proven by read-back and an outside checker, escalate with those screenshots instead of re-editing records.
Authentication passes, inboxing still poor. Not a DNS problem anymore: a cold sending subdomain, list quality, and complaint rates are deliverability work. Do not let anyone sell you more record edits for it.
FAQ — the issues behind this problem, answered
SPF and DKIM both say PASS. How can DMARC fail?
Because DMARC grades the domain on the pass, not the pass itself. Passes on Klaviyo’s domains prove Klaviyo’s mail is genuine — they say nothing about yours. Alignment is the missing leg, and the branded sending domain is what creates it.
Will this fight with my Google Workspace or Microsoft 365 email?
No. Klaviyo’s records live on their own names under a sending subdomain; Workspace and Microsoft selectors live on theirs. The only shared asset is the single DMARC record — which is precisely why it must stay single.
Should the From address use the sending subdomain too?
No — Klaviyo warns against sending From the sending subdomain. The subdomain does the authenticating; your customers keep seeing your root domain.
Sources
Klaviyo Help Center — branded sending domains and verification troubleshooting · Cloudflare Developers — proxy status and CNAME flattening documentation · RFC 7489 §6.6.3 · Google Workspace Admin Help — Set up DMARC (inheritance, alignment modes) · Yahoo Sender Hub — sender best practices.
Verification note: Klaviyo’s current Domains flow (dynamic NS delegation or static CNAMEs), the always-a-subdomain model, Cloudflare’s flattening warning and the single-DMARC rule were checked against the official sources above on 19–20 October 2026. Account-specific record values are never printed in this guide, because yours exist only inside your own Klaviyo account.
Did this fix work for you?
Your reaction tells us whether this guide solved the problem it promised to solve.