Kit emails going to spam? The 10-minute fix (and the trap that makes it worse)

Short version first: if your Kit newsletter is landing in spam, the most likely cause is that your Verified Sending Domain was never finished. Kit gives you two CNAME records, cka._domainkey and ckespa. Add them in your DNS, click Validate, done. Ten minutes, most of it waiting. You can check whether your domain has them right now, free, no signup.

The longer story is worth five minutes though, because the same mistake that sends newsletters to spam has a nastier cousin, and people walk into it while trying to do the right thing.

The reputation you're actually sending on

When you sign up for Kit, sending just works. That's convenient, and it hides a decision that was made for you: until you verify your own domain, your emails are signed by Kit's shared infrastructure. As far as Gmail is concerned, your newsletter has the same sender pedigree as everything else coming off that shared pool, including the sloppy stuff.

For years nobody really paid for this. Then Gmail and Yahoo changed the rules in February 2024. Bulk senders now have to authenticate with their own domain and publish a DMARC policy, and enforcement has only tightened since. Nobody who skipped verification got a warning about it. Open rates just sagged, slowly, and got blamed on subject lines.

(This is the general shape of deliverability problems, by the way. They almost never announce themselves. Something breaks quietly and you spend three weeks A/B testing the wrong thing.)

What the two records do

They have different jobs.

cka._domainkey.yourdomain.com is your DKIM record. It lets Kit sign every email with a key tied to your domain, which is how receivers confirm a message really is yours and wasn't altered on the way.

ckespa.yourdomain.com handles the envelope, the behind-the-scenes return address that bounce processing and SPF checks care about. Kit delegates all of that through this one record.

Notice what's missing from the list: your SPF record. You never touch it for Kit. A decade of old tutorials says to paste an include into SPF, and that advice is now wrong for Kit; worse, a clumsy SPF edit can break authentication for everything else your domain sends, including your ordinary business email. If a guide tells you to edit SPF for Kit, close the tab.

Also missing: DMARC. Kit can't create it for you. No email tool can, because DMARC lives on your domain and covers every sender you use at once. That record is yours, and it's a single TXT entry.

Fixing it, in the order that matters

1. In Kit: click your account name, then Settings, then Email. Under Verified Sending Domains, click Set up. Kit shows both records with your account's exact values.
2. In your DNS provider, add them precisely as shown. Two things trip people constantly here. Some dashboards silently append your domain to whatever you type, so you end up with cka._domainkey.yourdomain.com.yourdomain.com, a record that exists at a name no receiver will ever ask for. And Cloudflare likes to proxy new CNAMEs by default; these must be set to DNS-only.
3. Back in Kit, click Validate. If it doesn't pass, wait an hour before assuming anything is wrong. It's nearly always propagation.
4. Then, and only then, add DMARC if you don't have it: a TXT record at _dmarc.yourdomain.com with the value v=DMARC1; p=none; rua=mailto:you@yourdomain.com.

The trap

Step 4 says "then" for a reason.

Someone reads that DMARC is required now, which is true. They add it, and since stricter sounds safer, they pick p=quarantine or p=reject. But their Kit domain was never verified. So every newsletter goes out signed by Kit's shared domain, fails alignment against the strict new policy, and gets junked on their own instruction. They published a machine-readable request to spam-folder their own newsletter, with the best intentions in the world.

Verify first. Start DMARC at p=none. Tighten it when your reports show everything passing, not before.

It will break again

I'd love to tell you the fix is permanent. What we see from monitoring sending domains says otherwise: records that were correct at setup drift. A website migration wipes the "unrecognized" TXT records. An agency tidies up the DNS zone. A provider changes its requirements, the way 2024 changed them for everyone at once. DNS doesn't send farewell notes, so the first symptom is the vaguest one there is: reach, quietly declining.

That's the honest limit of any checklist, including this one. Deliverability is a state that decays, not a task you complete.

The free Kit checker verifies both Kit records plus your DMARC, SPF, MX and 24-plus blocklists, and gives you a plain yes or no. And if you'd rather never think about this topic again, that's what Inbox Decay is for: we watch your setup permanently and email you the moment something breaks. The watching is free.