Klaviyo does not want you to add its servers to your own SPF record. Instead you point a branded sending subdomain at Klaviyo using CNAME records, and Klaviyo hosts the SPF policy and DKIM keys for you at the other end of those CNAMEs. This guide shows the exact records for a Klaviyo branded (dedicated) sending domain, why the raw SPF include is a mistake that breaks other senders, and how to add the one record Klaviyo will never create for you: your DMARC policy.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
Why Klaviyo uses CNAMEs instead of an SPF include
Most email platforms tell you to bolt an include: onto your existing SPF record. Klaviyo takes a different path, and it is the better one.
When you set up a branded sending domain, you pick a subdomain such as send.yourdomain.com. Klaviyo uses that subdomain as the return-path (the SMTP MAIL FROM address) and as the DKIM signing domain. Because you delegate that subdomain to Klaviyo through CNAME records, Klaviyo controls the DNS answers behind it. A receiving server that looks up SPF for send.yourdomain.com follows your CNAME to Klaviyo's host and reads the SPF record Klaviyo publishes there.
The practical win: Klaviyo can add, remove, or renumber its outbound IP ranges whenever it needs to, and your DNS never has to change. You publish the CNAMEs once. Klaviyo maintains the actual SPF and DKIM content behind them. This is why you will sometimes see the setup described as CNAME flattening or SPF delegation. If you have ever fought the ten-DNS-lookup SPF limit, this model sidesteps it entirely, because Klaviyo's SPF lives under its own domain and never counts against your root record. See fix SPF too many DNS lookups for why that limit matters.
The records for a Klaviyo branded sending domain
A branded sending domain in Klaviyo comes down to three CNAME records that you copy from the Klaviyo console, plus one TXT record for DMARC that you write yourself. Klaviyo shows the exact target hostnames on the branded domain screen, so treat the values below as the shape of the answer and confirm the precise targets in your account before you save them.
Type Host Value
CNAME kl._domainkey.send dkim.klaviyomail.com
CNAME kl2._domainkey.send dkim2.klaviyomail.com
CNAME send (Klaviyo return-path target)
Replace send with whatever subdomain you chose. If your subdomain is email.yourdomain.com, the DKIM hosts become kl._domainkey.email and kl2._domainkey.email.
The DKIM CNAMEs
The two _domainkey records point Klaviyo's DKIM selectors at keys that Klaviyo generates and rotates. Klaviyo publishes two selectors so it can rotate one key while the other keeps signing, which means mail never goes unsigned during a rotation. You do not paste a public key into a TXT record the way you would for a self-hosted DKIM setup. The CNAME hands that job to Klaviyo. If you want the background on the two ways DKIM records get published, read DKIM CNAME vs TXT record.
The return-path CNAME that carries SPF
The third CNAME, on the bare subdomain itself, is the return-path or bounce domain. This is the address in the SMTP envelope that receivers use for the SPF check. Because it resolves through the CNAME to Klaviyo, the SPF record that gets evaluated is Klaviyo's, and it authorizes Klaviyo's real sending IPs. This single record is what makes SPF pass for your Klaviyo campaigns without you touching your root SPF at all.
Never add a raw Klaviyo SPF include
This is the most common Klaviyo mistake, so it is worth stating plainly. Do not add anything like include:_spf.klaviyo.com to the SPF record on your root domain.
There are two reasons. First, it is unnecessary. SPF for Klaviyo mail is evaluated against the branded sending subdomain, not your root domain, so a root include does nothing useful for campaign deliverability. Second, it is harmful. Your root SPF record has a hard ceiling of ten DNS lookups under RFC 7208. Every include: you stack on burns lookups, and if you already send from Google Workspace, Microsoft 365, or a helpdesk tool, one more include can tip you over the limit and cause a PermError that fails SPF for all of your mail, not just Klaviyo. Adding a broad +all or trying to widen the record to compensate makes it worse, as covered in why +all in SPF is dangerous.
Leave your root SPF alone. The three CNAMEs are the entire SPF and DKIM story for Klaviyo.
DMARC is your job, not Klaviyo's
Klaviyo hosts SPF and DKIM, but it cannot publish a DMARC record for you, because DMARC governs your whole organizational domain and only you should own that policy. If your domain has no DMARC record yet, Google and Yahoo bulk-sender rules now expect one, and Klaviyo will nudge you to add it. This is a TXT record at _dmarc.yourdomain.com that you create in your DNS.
Start in monitoring mode so you can watch reports before you enforce anything:
_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r"
p=none tells receivers to enforce nothing yet but to send you aggregate reports at the rua address. Once you confirm that Klaviyo and every other legitimate sender aligns, you move the policy toward p=quarantine and then p=reject. The full progression, including how long to sit at each stage, is in how to set up DMARC and moving DMARC from none to reject. Note the relaxed alignment tags adkim=r and aspf=r, which matter for the next step.
Validate alignment before you trust the setup
Records that resolve are not the same as records that align. DMARC only passes when at least one of SPF or DKIM both authenticates and aligns with the domain in your visible From address.
With Klaviyo's model, DKIM signs with the branded subdomain, and the return-path lives on that same subdomain, so both share your organizational domain. Under relaxed alignment, send.yourdomain.com and yourdomain.com are treated as the same organization, so alignment passes cleanly. This is exactly why the DMARC tags above use relaxed mode. If you want the mechanics of why a subdomain still counts as aligned, read DMARC relaxed vs strict alignment.
Send yourself a test campaign, then run your domain through the scanner above. You want to see SPF pass on the branded subdomain, DKIM pass with a d= value on your domain, and DMARC report alignment on both. If DKIM authenticates but DMARC still fails, alignment is the usual culprit, and fix DKIM alignment walks through the fix. Getting all three green is what keeps Klaviyo campaigns out of spam and satisfies the Google and Yahoo sender requirements.
Frequently asked questions
Do I need a dedicated sending domain in Klaviyo, or is the shared one fine?
The shared domain works, but mail is signed under a Klaviyo-owned domain, so it does not align with your From address for DMARC and it shares reputation with other Klaviyo senders. A branded sending domain gives you aligned DKIM, aligned SPF, and reputation you control. If you send meaningful volume or you enforce DMARC, use the branded domain.
Why does Klaviyo not want me to edit my SPF record?
Because SPF for your campaigns is checked against the branded subdomain, which is delegated to Klaviyo by CNAME. Klaviyo publishes and maintains the SPF content behind that CNAME. Editing your root SPF adds nothing and risks pushing you over the ten-lookup limit that breaks SPF for every sender on your domain.
Will the Klaviyo CNAMEs make DMARC pass on their own?
They make SPF and DKIM authenticate and align, which is what DMARC evaluates. But DMARC only takes effect once you publish your own _dmarc TXT record. Without that record there is no policy for receivers to apply, even though the underlying authentication is correct.
How long until the records take effect?
DNS propagation is usually minutes to a couple of hours, though it can take up to 48 hours depending on your provider and TTL. Klaviyo will keep showing the branded domain as pending until it can resolve all three CNAMEs, so verify in the console and then confirm with a live test send before you launch a campaign.