What records does Kit's Verified Sending Domain need?

Two CNAMEs with your account's values from Kit's Settings → Email screen, plus your own DMARC record. The CNAME at host ckespa delegates your envelope/return-path to a subdomain of your domain, with Kit serving SPF through it — so SPF aligns under relaxed alignment. The CNAME at cka._domainkey delegates DKIM signing so Kit signs with d= equal to your domain — DKIM aligned. Your root SPF TXT record is never touched, which is why generic tutorials telling you to add an include for Kit are the wrong platform's instructions. The CNAME targets live under convertkit.com even after the Kit rebrand — do not 'correct' them to kit.com. Kit supplies a default DMARC record in-product to copy to _dmarc, and teaches the p=none to quarantine to reject climb at a couple of weeks per step.

Is Kit's custom domain for landing pages the same as its verified sending domain?

No — they are different features with different settings screens and different records, and confusing them is the classic Kit setup failure. The Verified Sending Domain (Settings → Email) is about authentication: two CNAMEs (ckespa and cka._domainkey) so your broadcasts pass DMARC with your domain. The custom domain for pages (Settings → Domains) points a domain or subdomain at Kit-hosted landing pages and forms using its own set of records (shown in that screen, confirmed by a green tick there). Kit's own page-domain article even contains a stray copy-pasted DMARC paragraph, which deepens the confusion. Rule: email authentication problems are solved in Settings → Email; page hosting problems in Settings → Domains. Records from one screen never fix the other.

Kit (ConvertKit) · Sending domain

Kit verified sending domain: two CNAMEs and your root SPF stays untouched

First published 20 October 2026 · Architecture and records from Kit's Help Center read in full. Kit was formerly ConvertKit — its DNS targets still live under convertkit.com, and that's correct, not a typo (§2).

THE DEFAULT STATE Kit's own words: “the return-path will be a Kit address (kit.com)”

Out of the box, your From looks like you but the envelope belongs to Kit — so under your domain, nothing aligns and DMARC has nothing to pass on. The verified domain moves the envelope onto your subdomain and the signing key under your root: both legs aligned, and your root SPF record never edited.

ckespa → SPF aligned (relaxed)cka._domainkey → DKIM aligned

The architecture (mirror image of SendGrid's)

Piece	How Kit does it
Return-path / SPF	CNAME host `ckespa` delegates an envelope subdomain of your domain to Kit, which serves SPF there. Envelope and From share your organisational domain → SPF aligned (relaxed). It's SendGrid's subdomain trick (Article #31) run in reverse: instead of you publishing their records, you delegate a name and they serve everything behind it
DKIM	CNAME host `cka._domainkey` (selector `cka`) delegates signing at your root; Kit signs with `d=` your domain → DKIM aligned
Root SPF	Never touched. Any tutorial telling you to add `include:` something for Kit is another platform's instructions wearing Kit's name
Root or subdomain as the verified domain?	Your choice — Kit, verbatim: “Do I need to set up a subdomain? No… Your authentication records will not interfere with your top-level domain.” Verified-at-root is the common creator setup; Article #40's inheritance rules still govern what your root DMARC policy does to it

The record set

Record	Host	Target (your values, from Kit's screen)
CNAME	`ckespa`	`spf.dm-<your token>.sg<N>.convertkit.com` — pattern corroborated from real published DNS; copy YOUR value from Settings → Email
CNAME	`cka._domainkey`	`dkim.dm-<your token>.sg<N>.convertkit.com` — same instruction: the screen's value, character-for-character
TXT (DMARC)	`_dmarc`	Kit supplies a default record in-product to copy; then it's yours to climb (§DMARC)

Rebrand trap: the targets end in convertkit.com because the infrastructure kept its name. “Fixing” them to kit.com breaks both delegations instantly. Similarly, if a host truncates the host field, Kit's own warning names both records — enter ckespa and cka._domainkey relative to your domain, never the full dotted name doubled.

The ladder

Settings → Email → add your sending domain. Kit offers automatic setup (“Set this up for me,” via the same Entri-style registrar login Brevo uses, Article #35) or manual records.
Manual path: publish the two CNAMEs with your screen values (at Cloudflare: DNS only, as with every delegated key in this series).
Validate in Kit; both records must show verified before the domain sends as verified. (Kit's DMARC validation notes 24–48 hours for a new DMARC record to take effect — judge by readback, Article #20.)
Publish/confirm DMARC at _dmarc (Kit's supplied default if you have none).
Send consistently. Kit's documented post-setup reality: open rates normalise after two to three weeks of consistent sending on the new domain identity (Kit suggests suppressing cold subscribers for the first two weeks as the accelerator). There is no numeric warm-up ramp in Kit's help — any article printing daily volume ladders for Kit is inventing them.

§DMARC — Kit's stance, quoted fairly

Kit mandates nothing of its own beyond a non-freemail sender address (“true for all emails sent via Kit”). What it does is relay the Gmail/Yahoo regime with unusual bluntness — “These new requirements are NOT recommendations” — supply the default record, validate it in-product, and teach the p=none → quarantine → reject ladder at “a couple of weeks” per step, starting from a full sender inventory. That is precisely this site's method (Articles #4/#36) arriving from a creator platform — follow it there or here, but follow it. One Kit-documented inconsistency to navigate: its guides cite the bulk threshold as both “more than 3k messages a day” and “5,000 emails in a day” in different articles; the receiver-side truth (Article #12) is ~5,000/day to a single provider — plan to the stricter reading.

The OTHER Kit “custom domain” — do not cross the streams

	Verified Sending Domain	Custom (page) domain
Screen	Settings → Email	Settings → Domains
Purpose	Authentication for broadcasts	Hosting landing pages/forms on your domain
Records	Two CNAMEs (`ckespa`, `cka._domainkey`)	Its own record set shown in that screen (confirmed by its green tick)
Fixes	Spam placement, DMARC failure	Page URLs/branding

Kit's page-domain article even contains a stray copy-pasted DMARC paragraph — vendor-side confusion that propagates into user DNS. If your problem is authentication, the Domains screen cannot help you, and vice versa.

Verify

Kit: the domain shows verified (both CNAMEs validated).
Headers: a broadcast shows Return-Path on your ckespa subdomain, dkim=pass with d= your domain, spf=pass aligned, dmarc=pass — the full house this feature exists to produce.
Reports: Kit appears in your aggregate reports (Article #36) as an aligned source on both legs.

Traps

Trap	Reality
“Correcting” convertkit.com targets	Post-rebrand infrastructure kept its DNS names. Your edit breaks the delegation (§2)
Leaving Kit later, records staying	Kit's “remove our records” hygiene advice is written for page domains — apply it to the sending CNAMEs too: a dangling `ckespa`/`cka` delegation is exactly the abandoned-badge risk of Article #40
Expecting instant metrics	Two-to-three-week normalisation is Kit's documented reality — judge the migration at week three, not day two
Guessing Kit's sending vendor from the DNS	The shard names look SendGrid-shaped; a current third-party guide claims Mailgun; Kit names no vendor. It doesn't affect your setup — and this guide prints neither claim

FAQ

Do I need a verified domain if I send under 5,000/day?

Kit's only hard rule is non-freemail. But “not mandated” ≠ “not needed”: without it your DMARC literally cannot pass under your domain (the default state, §hero). Any list you care about deserves the two CNAMEs.

Will verifying break my existing root SPF or website?

Kit's assurance covers the root SPF (untouched by design). The CNAME hosts (ckespa, cka._domainkey) are names nothing else should occupy — check for strays there before publishing (Article #18's discipline).

Sources

Kit Help Center — verified sending domain articles (architecture; the return-path sentence; the subdomain answer; truncated-host warning naming both records) · DMARC articles (the “NOT recommendations” framing; default record + validation; the ladder; the 3k-vs-5k threshold contradiction) · post-setup deliverability guidance (2–3-week normalisation) · custom (page) domain article (the separate feature). CNAME target patterns are corroborated from two independent real-world DNS publications and flagged as such; Kit publishes the values only in-product.

Verification note: Kit's architecture, requirement stance and record hosts were confirmed from Kit's help on 20 October 2026. The exact bullet list of verified-domain benefits in Kit's help is a non-text element that could not be extracted — §1 rests on the documented mechanism, not on that list.

Did this guide work for you?

Your reaction tells us whether this guide solved the problem it promised to solve.