Kit (ConvertKit) deliverability: what actually moves the needle

Kit (formerly ConvertKit) sends on shared infrastructure by default, and most deliverability problems reported by Kit users trace back to one of three causes: a custom sending domain that was never fully authenticated, a list that has accumulated unengaged or invalid subscribers, or a new domain sending real volume with no warm-up period behind it. The platform itself is not usually the bottleneck.

Check authentication on your sending domain first

If you have connected a custom domain to Kit rather than sending from a shared Kit subdomain, that domain needs its own SPF record authorizing Kit's sending servers, and a DKIM record with the selector Kit's own domain-settings screen gives you - copy that value directly from your Kit account rather than guessing at a selector, since it is specific to your account's setup. A DMARC record at the organizational domain, even a permissive p=none policy with reporting turned on, gives you visibility into whether mail claiming to be from your domain is passing alignment elsewhere.

List hygiene problems that look like platform problems

Kit's own engagement-based sending features help here, but they manage symptoms of a dirty list rather than fixing the underlying acquisition problem. A list built from unverified lead magnets or purchased contacts will keep generating complaints regardless of which ESP sends it.

Sending volume and custom-domain warm-up

A newly connected custom domain on Kit has no sending history at all, even if the Kit account itself is years old - sending history is tied to the domain and IP reputation, not the platform account. Creators who move a large existing list onto a brand-new custom domain and send a full campaign on day one are the group most likely to see an immediate deliverability drop, because the receiving providers have no history to extend trust against.

What Kit's own tools do and do not cover

Kit surfaces delivery and open-rate data per broadcast, which is useful for spotting a sudden drop, but it does not show inbox-versus-spam placement per provider or a domain-level reputation trend over time - those require testing against real seed inboxes independently of the sending platform.

What not to do

Do not connect a custom domain and immediately send your full list on it - ramp volume gradually over two to four weeks the same way you would for any new sending domain, regardless of which ESP sits in front of it. Do not ignore a creeping bounce rate because open rates still look acceptable; bounces affect sender reputation even when the subscribers who do receive mail are engaged.

Measuring whether a fix actually worked

After fixing an authentication gap or cleaning a list, the honest way to confirm it worked is placement testing against real seed inboxes across providers over the following one to two weeks, not a single day's open-rate number. Open rates recover gradually as receiving providers adjust their filtering based on improved sending behaviour - a one-day snapshot immediately after a fix can look unchanged even when the underlying trend has genuinely turned around, because provider-side reputation doesn't reset instantly.

A short diagnostic order worth following

When a Kit account's deliverability drops, check things in this order: authentication records for any connected custom domain first (fastest to verify, and a hard failure point if wrong), recent list growth and import sources second (slower to fix but usually the larger underlying cause), and sending frequency or volume changes third (often the trigger that exposes an existing authentication or list problem rather than a cause on its own). Working through them in that order avoids the common mistake of spending a week on content and subject-line changes when the actual cause was a DKIM record that never finished propagating after a domain move.

One more thing worth checking before escalating

If authentication, list hygiene, and sending volume all check out and placement is still inconsistent, confirm the custom domain isn't also being used to send mail through a second, unrelated tool - a shared domain sending through two platforms without both properly included in a single SPF record is a subtle, easy-to-miss cause that looks exactly like an unexplained platform problem until someone checks the raw DNS record character by character.

Where MailPilot fits

MailPilot warms mailboxes and checks SPF/DKIM/DMARC against live DNS over SMTP/IMAP, including custom domains sending through providers like SendGrid, Amazon SES, Mailgun, Postmark, or custom SMTP, and tracks per-mailbox reputation daily so a creator moving to a custom domain can see placement trend directly rather than guessing from open rates alone.