Kit (ConvertKit) SPF, DKIM and DMARC setup

Kit (formerly ConvertKit) authenticates a sending domain with CNAME records rather than with TXT records you maintain by hand. You publish a small set of CNAMEs that point into Kit's zone; Kit then serves the DKIM key and the SPF data behind them. The practical consequence: you never republish a public key, you never hit the 255-character TXT string limit, and Kit can change its sending infrastructure without you editing DNS.

What you need before starting

1. Access to the Kit account with permission to add a sending domain.
2. Access to your domain's DNS — the registrar or wherever the nameservers point. Note that if your domain uses a CDN or proxy, DNS records live there, not at the registrar.
3. A real mailbox on the domain you intend to send from. Verification mail has to arrive somewhere a human reads.
4. A decision about which domain goes in From.

On that last point: use a domain you control. A gmail.com, yahoo.com or other free-mail address in From will be rejected or junked by DMARC-enforcing receivers, because those providers publish p=reject on their own domains precisely to stop third-party platforms sending as their users. No setting on your side overrides someone else's DMARC policy.

SPF delegation by CNAME, explained

A normal SPF setup means your own TXT record carries an include: for every sender. SPF delegation inverts it: you create a CNAME at a subdomain, and the vendor publishes the SPF record that lives behind it.

dig +short CNAME <the host Kit gave you>
dig +short TXT   <the host Kit gave you>

The first command shows the delegation; the second shows the v=spf1 ... record the resolver found by following it. Why this matters: the envelope sender (the Return-Path) is set to that delegated subdomain, so the SPF evaluated is the vendor's record, under a name on your domain. That means the SPF pass *aligns* with your From domain under relaxed alignment — which a vendor's own bounce domain would not — and your apex SPF record stays untouched, with its full budget of 10 DNS-querying mechanisms intact.

Publishing the records

Take the exact host and target values from Kit's sending-domain screen. They are account-specific and cannot be copied from an article. The shape is a handful of CNAMEs: one or two for DKIM under _domainkey, and one for the Return-Path or SPF delegation.

Two rules that cause most failures:

• Enter only the relative host if your DNS panel appends the zone automatically. Otherwise you create selector._domainkey.yourdomain.com.yourdomain.com, which resolves to nothing.
• A CNAME cannot coexist with other record types at the same name, and cannot be placed at the apex. If the panel refuses to save, you probably have a leftover TXT or A record at the same host.

Then verify each one from outside Kit:

dig +short CNAME <selector>._domainkey.yourdomain.com
dig +short TXT   <selector>._domainkey.yourdomain.com

The TXT query should return v=DKIM1; k=rsa; p=... even though you published a CNAME. That is the resolver chasing the delegation into Kit's zone, and it is the proof the chain works end to end. If the CNAME resolves but the TXT is empty, Kit has not provisioned the key yet — wait, then re-check.

Confirm it with a real send

Send a broadcast to a test address on Gmail and one on Outlook, open the raw source, and read two headers:

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=<selector>; ...
Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=<delegated subdomain>.yourdomain.com;
  dkim=pass header.i=@yourdomain.com;
  dmarc=pass (p=NONE) header.from=yourdomain.com

d= in the signature is the signing domain. If it shows your domain, you are aligned. If it shows Kit's domain, the signature is valid but unaligned, DMARC has nothing of yours to pass on, and tightening the policy later would break your broadcasts.

DMARC, in stages

_dmarc.yourdomain.com   TXT   "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1"

Leave that for a week. Aggregate reports arrive roughly daily as gzipped XML, so send them to a parser or a dedicated address rather than a mailbox you read. Confirm from the reports that your newsletter traffic shows aligned DKIM, then move to p=quarantine, watch for a week, then p=reject.

Add sp= when you tighten p=. Without it, subdomains inherit the apex policy, which is right for a locked-down domain and wrong mid-rollout if something else sends from a subdomain.

If rua points at a mailbox on another domain, that domain has to authorise the reports with a v=DMARC1 record at yourdomain.com._report._dmarc.<their-domain>. Missing that record is the most common reason DMARC is published and no reports ever arrive.

Troubleshooting

• Kit says unverified, DNS looks right. Check for a conflicting record at the same host, and query a public resolver with @8.8.8.8 to rule out your own cache.
• A proxy or CDN is "orange-clouding" the record. Authentication CNAMEs must be DNS-only. A proxied record returns the proxy's address, not the delegation.
• It worked and then stopped. A DNS migration dropped the underscore-prefixed names. _domainkey and _dmarc records are the ones zone transfers and manual re-entry lose most often.
• `dkim=fail` with "body hash did not verify". Something modified the message after signing, typically a list or appliance appending a footer. The signature is working and reporting a real change.

What not to do

• Do not paste another account's selector values. DKIM keys are per-account.
• Do not add a second v=spf1 record at your apex "to be safe". Two SPF records produce PermError and disable SPF entirely.
• Do not proxy authentication records through a CDN.
• Do not set p=reject the same week you connect a platform. Verify in headers, then in reports, then enforce.
• Do not treat the green tick in the dashboard as proof of alignment. It means Kit can send; the headers tell you whether receivers credit it to your domain.

MailPilot checks SPF, DKIM and DMARC for each connected mailbox's sending domain and measures real per-provider inbox placement with a seed-inbox network, so a broken delegation shows up as a failing check rather than as a quietly declining open rate.