Do I need to add an SPF include like include:klaviyomail.com to my SPF record?

No. Klaviyo authenticates SPF on the delegated send subdomain (via the send CNAME on Static routing, or the NS delegation on Dynamic routing), so your root SPF is untouched and gains zero DNS lookups. The only TXT Klaviyo gives you for the root is klaviyo-site-verification=..., which proves ownership — it is not an SPF record.

Why do my emails still say "via klaviyomail.com"?

You're still on Klaviyo's shared sending domain. Set up and Activate a branded sending domain under Settings then Domains; once it's verified and active, the "via klaviyomail.com" tag next to your name disappears and mail sends as your own domain.

Dynamic (NS) or Static (CNAME) — which should I choose?

Klaviyo recommends Dynamic for the best deliverability because it lets Klaviyo pick the optimal sending provider and IP per message. Choose Static if your DNS host can't delegate a subdomain by NS record — most commonly Cloudflare and BigCommerce. Both are CNAME/NS delegation with no root SPF include.

What's the difference between the Marketing, Transactional, and Service domain types?

They set the DKIM selectors (km1/km2, kt1/kt2, ks1/ks2) and which mail they authenticate. Service domains (helpdesk replies) on Static routing also require an MX record. Pick the type that matches how you'll send; you can add more than one branded domain to the same account.

Do I add these as CNAME, NS, or TXT records?

It depends on routing. Dynamic = 4 NS records for the send subdomain plus one TXT for ownership verification. Static = 3 CNAMEs (the send host plus km1._domainkey and km2._domainkey) plus the verification TXT. DMARC is always a separate TXT at _dmarc, on either method.

Will Klaviyo's records conflict with Google Workspace or another sender I already use?

No. Klaviyo uses its own send subdomain and its own km/kt/ks DKIM selectors, so it won't overwrite your existing DKIM or your root SPF. The only rule: keep a single SPF TXT and a single DMARC TXT on your root domain.

Is a branded sending domain the same as a dedicated IP?

No. A branded sending domain is about authentication — getting SPF, DKIM, and DMARC to align to your domain — and any account can create one. A dedicated IP is a separate reputation feature for higher-volume senders. Dynamic routing keeps you on shared-but-optimized IPs unless you specifically buy a dedicated one.

SPF setup guide

SPF, DKIM & DMARC for Klaviyo.

Klaviyo authenticates your domain through a branded sending domain (its current name for what used to be called a dedicated sending domain), configured under Settings then Domains — not by pasting a shared SPF line. You pick a sending subdomain (Klaviyo suggests send.yourdomain.com) and delegate it to Klaviyo, either with four NS records (Dynamic routing, recommended) or three CNAME records (Static routing). That delegation carries SPF and auto-rotating DKIM for you, so once the records verify and you click Activate, Klaviyo sends as your own domain: the "via klaviyomail.com" tag disappears, SPF and DKIM align, and DMARC can pass.

CNAME domain authentication

Your DNSAdd the CNAME / TXT records

KlaviyoSigns & sends as your domain

The inboxSPF · DKIM · DMARC pass

Why authenticate Klaviyo?

Setting up a branded sending domain in Klaviyo isn't cosmetic — it decides whether your campaigns reach the inbox. Out of the box Klaviyo puts you on a shared IP and its shared klaviyomail.com domain, so Gmail recipients literally see "via klaviyomail.com" next to your name, your From address doesn't align, DMARC can't pass, and your reputation is pooled with every other unauthenticated sender on that shared infrastructure. Since February 2024, Gmail and Yahoo have required every bulk sender (roughly 5,000+ messages a day) to pass SPF, DKIM, and DMARC with alignment, and Microsoft began enforcing the same on Outlook/Hotmail domains in 2025 — junking then rejecting non-compliant bulk mail. A branded sending domain fixes all of it in one move: SPF and DKIM both align to your domain, the "via" tag goes away, DMARC passes, and the sending reputation you build accrues to your own domain instead of Klaviyo's shared pool. Klaviyo itself now nags most accounts to add one for exactly this reason.

The SPF reality for Klaviyo

Klaviyo is a delegation-based (CNAME/NS) domain-authentication provider, so there is NO "include:klaviyo..." to add to your root SPF — for anyone. When you set up a branded sending domain, Klaviyo authenticates on a dedicated sending subdomain (it suggests send.yourdomain.com), and how SPF gets satisfied depends on the routing method you pick. With Dynamic routing (recommended), you publish four NS records that hand the entire send.yourdomain.com subdomain to Klaviyo's nameservers (ns1 through ns4.klaviyo.com); Klaviyo then publishes the SPF and DKIM records inside that delegated zone itself, so you add nothing else and Klaviyo can rotate keys and swap sending IPs without you ever touching DNS. With Static routing, you instead add a CNAME (send.yourdomain.com to 1.klaviyodns.com) that becomes the envelope/Return-Path host — because it resolves into Klaviyo's own SPF-authorized space, SPF is satisfied there on the subdomain, again with no root include. Klaviyo explicitly does not hand you a v=spf1 line for your root domain; the single TXT it gives you (klaviyo-site-verification=your-public-API-key) is domain-ownership verification, not SPF. DMARC still passes through relaxed alignment: the sending subdomain shares your organizational domain, so SPF aligns, and DKIM signs with your domain (the km selectors sit at km1._domainkey.yourdomain.com). Bottom line: no shared SPF include, zero DNS lookups added to your root SPF; SPF and DKIM are delegated on the send subdomain either by NS delegation or by CNAME.

Two ways to set it up

Recommended

Dynamic routing — NS delegation (recommended)

Four NS records hand your send.yourdomain.com subdomain to Klaviyo (ns1 through ns4.klaviyo.com); Klaviyo publishes SPF and DKIM inside that delegated zone for you
Klaviyo dynamically picks the best-performing sending provider/IP per message, which Klaviyo says gives the strongest deliverability
Keys rotate and sending infrastructure changes without you ever re-editing DNS
Adds zero lookups to your root SPF — there is nothing to merge into it

Legacy

Static routing — CNAME (fallback)

Three CNAMEs (send to 1.klaviyodns.com, plus km1 and km2._domainkey to km1/km2.domainkey.1.klaviyodns.com) pin you to one static Klaviyo sending host
Use it when your DNS host can't cleanly delegate a subdomain by NS record — most commonly Cloudflare and BigCommerce
Service (helpdesk) domains on this path also require an MX record for inbound routing
Still CNAME-based domain authentication: no root SPF include, and DKIM still auto-rotates via the two CNAMEs

Step by step

In Klaviyo

1
Open Domains settings
Click your company name in the bottom-left corner, choose Settings, open the Domains tab, then click Add Domain.
2
Pick the send type
Choose Marketing (default — campaigns and flows), Transactional (receipts, password resets), or Service (helpdesk replies). This sets the DKIM selectors: km1/km2 for Marketing, kt1/kt2 for Transactional, ks1/ks2 for Service.
3
Set the sending subdomain
Enter the subdomain to brand — Klaviyo suggests 'send', giving send.yourdomain.com. Keep it a subdomain, not your bare root domain.
4
Choose the routing method
Pick Dynamic (NS records, recommended) for best deliverability, or Static (CNAME records) if your DNS host can't delegate a subdomain by NS. Klaviyo then displays the exact records for your choice.

In your DNS

5
Add the records Klaviyo shows
Dynamic routing: add the 4 NS records for send.yourdomain.com pointing to ns1 through ns4.klaviyo.com. Static routing: add the send CNAME (to 1.klaviyodns.com) plus the two km1._domainkey and km2._domainkey DKIM CNAMEs. Copy the values exactly as Klaviyo lists them — they're account-specific.
6
Add the verification TXT
Add the TXT record on your root domain (klaviyo-site-verification=your-public-API-key) so Klaviyo can confirm you own the domain. This is required on both routing methods and is not an SPF record.
7
Turn off the Cloudflare proxy
If your DNS is on Cloudflare (or any host with proxying), set every record to DNS only (grey cloud). A proxied record won't resolve to Klaviyo and verification fails — and it must stay unproxied afterward or ongoing authentication breaks.
8
Add the MX record (Service type only)
If you picked the Service type on Static routing, also add the MX record Klaviyo lists so replies to your helpdesk address route correctly.

Verify

9
Click Verify
Back in Settings then Domains, click Verify. You'll see 'Verification success', a 'Verification error' (records are wrong), or a conflict notice. DNS propagation is usually minutes but can take up to 48 hours.
10
Activate the domain
Once verified, click Activate so Klaviyo starts sending from the branded domain. Brand-new domains or IPs may still need a short warm-up period before full volume.
11
Set your From address on the root
Send from an address on your root domain (you@yourdomain.com), NOT the send subdomain. Replies go to the visible From, and @send.yourdomain.com isn't a real mailbox — DMARC still aligns because the subdomain is under your organizational domain.

Records to add

Klaviyo generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.

Type	Host	Value
CNAME	send	1.klaviyodns.comStatic routing: the sending subdomain (envelope / Return-Path) — this is what satisfies SPF, with no root include. Dynamic routing replaces this single CNAME with 4 NS records delegating send.yourdomain.com to ns1 through ns4.klaviyo.com. The leading '1' is an account-specific sending-host number.
CNAME	km1._domainkey	km1.domainkey.1.klaviyodns.comDKIM key 1 (auto-rotated). Selector is km1/km2 for Marketing, kt1/kt2 Transactional, ks1/ks2 Service. Static routing only — Dynamic publishes these inside the delegated subdomain zone.
CNAME	km2._domainkey	km2.domainkey.1.klaviyodns.comDKIM key 2 (auto-rotated). Second selector for the same domain.
TXT	@	klaviyo-site-verification=your-public-API-keyDomain-ownership verification on your root domain — this is NOT an SPF record. Added on both routing methods.
TXT	_dmarc	v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comYour DMARC policy — one per domain, on your root. Klaviyo's flow flags whether you already have a DMARC record and suggests a bare v=DMARC1; p=none;, but it can't publish it for you — you add it here yourself. Include an rua so you actually collect reports.

Keep exactly one SPF (v=spf1) TXT record on your root domain — merge every sender into it. Two SPF records is itself an error.

The 10-lookup budget

SPF is capped at a hard 10 DNS lookups — go over and it returns a permerror and stops validating everywhere. Here's what Klaviyo's setup costs against that budget.

SPF 10-lookup budget0 used · 10 free

Klaviyo's recommended setup adds 0 lookups — all 10 stay free for the senders that do need an include.

DKIM

DKIM is delegated to Klaviyo, not a key you paste. On Static routing it's the two CNAME records — km1._domainkey.yourdomain.com and km2._domainkey.yourdomain.com pointing at km1.domainkey.N.klaviyodns.com and km2.domainkey.N.klaviyodns.com (the N is your account's sending-host number). The selectors change with the send type you chose: km1/km2 for a Marketing domain, kt1/kt2 for Transactional, ks1/ks2 for Service — and a second domain of the same type gets the next pair (km3/km4, and so on). On Dynamic routing you add no DKIM records at all: Klaviyo publishes them inside the send.yourdomain.com zone you delegated by NS. Either way Klaviyo holds the private keys and rotates the published DKIM keys behind those selectors, so you never re-edit DNS and there's no TXT key to copy. Because DKIM signs with your domain, it aligns for DMARC. One catch: the _domainkey hosts contain underscores that a few DNS panels reject in CNAME records — the underscore is required, so use a host that permits it or ask Klaviyo support.

DMARC

DMARC is a separate policy TXT at _dmarc.yourdomain.com — not one of the CNAMEs — and it lives on your root/organizational domain, outside the send subdomain Klaviyo controls, so Klaviyo can't publish it for you even on Dynamic routing. Its setup flow will flag whether you already have a DMARC record and suggest a value, but you add the record yourself in your DNS. Start with a monitor-only v=DMARC1; p=none;, which is enough to satisfy the Gmail/Yahoo requirement for a DMARC record without affecting delivery, and add an rua so you actually receive the aggregate reports, e.g. v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Watch those reports for a week or two to confirm Klaviyo is passing SPF and DKIM aligned to your domain, then tighten to p=quarantine and eventually p=reject. Keep exactly one _dmarc record for the whole domain no matter how many senders you run — it governs every source, so don't add a second one just for Klaviyo.

Check it actually worked

Don't trust the green checkmarks alone — confirm it on a real message. Send yourself a campaign or flow test from an address on the branded domain, open it in Gmail, and choose the three-dot menu then Show original: you want SPF: PASS and DKIM: PASS both showing your domain (and the "via klaviyomail.com" note gone), plus DMARC: PASS. In Klaviyo, Settings then Domains should show the domain as Verified and Active. Run your domain through Qualisend's domain health check to confirm the send subdomain (NS or CNAME), the km/kt/ks DKIM selectors, and your DMARC record all resolve, and once aggregate reports start arriving, drop one into the DMARC report analyzer — Klaviyo should show up as an aligned, passing source. You can also spot-check the individual records with the SPF/DKIM/DMARC checker.

Domain health check DMARC report analyzer

Common gotchas

DNS setup
Cloudflare proxy breaks it: set every Klaviyo record to DNS only (grey cloud) and keep it unproxied. A proxied record won't resolve to Klaviyo, so both verification and ongoing authentication fail.
DNS setup
Cloudflare (and some registrars, plus BigCommerce) can't cleanly delegate a subdomain by NS record, so Dynamic routing often fails on those hosts — use Static (CNAME) routing there instead.
Coverage
Don't send from the send subdomain: keep your visible From on the root domain (you@yourdomain.com). @send.yourdomain.com isn't a mailbox, so replies would bounce; DMARC still aligns because the subdomain is under your organizational domain.
DNS setup
Host-field doubling: many registrars auto-append your domain, so entering send.yourdomain.com produces send.yourdomain.com.yourdomain.com. Enter just the label (send, km1._domainkey, km2._domainkey) if the panel adds the domain for you.
DNS setup
Underscores in CNAMEs: the km1._domainkey / km2._domainkey hosts contain underscores that a handful of DNS panels reject in CNAME records — they're required, so use a host that allows them or contact Klaviyo.
Breaks auth
There is no SPF include to add — the klaviyo-site-verification TXT is ownership verification, not SPF. Inventing an include:klaviyo... on your root does nothing useful and needlessly consumes one of your 10 SPF lookups.
Coverage
Pick the send type up front: Marketing, Transactional, and Service use different DKIM selectors (km/kt/ks), and Service domains also need an MX record. You can't silently repurpose a Marketing domain as a Service domain without redoing records.
Breaks auth
Keep exactly one SPF TXT and one DMARC TXT on your root. Klaviyo adds nothing to your root SPF, but if you already send via other providers, leave a single merged SPF record — two SPF records is itself a PermError.

Build your SPF record

Klaviyo doesn't need an SPF include: on your root domain — use the generator to assemble one clean record for your other senders, and keep it to a single line.

Sending sources

Search for each platform you send email through and tick it.

Search for your email platform above, or .

This domain's own servers

Authorize the domain itself, if it sends mail directly (not through a platform above).

a — the domain's own A recordmx — the domain's MX hosts

Other senders & IPs

Anything not in the list — another provider's SPF host, or specific IP addresses.

Additional includes

We add the include: prefix — enter the hostname your provider documents.

IPv4 addresses

IPv6 addresses

Policy for everyone else

What receivers should do with mail from any server not listed above (the all mechanism).

-all (fail)Strict — receivers should reject mail from any server not listed.~all (softfail)Recommended default — unlisted senders are accepted but marked suspicious.?all (neutral)No opinion — provides almost no protection; use only while testing.

Your SPF record0/10 DNS lookups

v=spf1 ~all

No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.

Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.

Authentication published? The next step is sending to a clean, verified list.

Verify a list