Email Deliverability Setup for Kit (ConvertKit): SPF, DKIM, and DMARC Explained

Your Kit dashboard can show green and still be watching nothing.

Kit deliverability setup is not a one time task you finished when you connected your domain. Kit automates the easy layers. The rest is still worth a look, and most senders never circle back to check it.

Short Answer: Is My Kit Account Fully Authenticated?

Kit's dashboard checkmarks confirm SPF and DKIM are connected, and Kit will hand you a default DMARC record if you go looking for it. Moving to a stricter DMARC policy and reading what the reports say are the two parts that stay manual, the same as they would with any sending platform. Those are usually the parts nobody goes back to finish.

What Does "Via" Mean in Kit?

When an email shows "sender@yourdomain.com via convertkit.com" in someone's inbox, that means the message is not fully authenticated under your own domain. Inbox providers see the mismatch and treat the message with less trust than one sent directly from your domain.

This shows up constantly with accounts that were set up before Google and Yahoo's 2024 email authentication requirements changed what "set up" needed to mean, since verifying a custom domain wasn't part of getting started with Kit before that. But it isn't only a legacy problem. Newer accounts skip it too, because verifying a custom domain is a manual step inside Kit's settings, not something that happens the moment you sign up. Sending keeps working the whole time, so nobody notices the "via" tag until someone points it out. It does not stop mail from delivering. It quietly costs you trust with every inbox provider that reads it.

The Kit Authentication Stack

Full authentication for a Kit sender has four layers. Kit only automates the first two.

• Layer 1 - Custom Domain Connection: Your domain has to be added and verified inside Kit. This is the step that gets skipped or half finished, and it is the reason "via" shows up.
• Layer 2 - SPF and DKIM: Kit's built in authentication tool generates these records for you using CNAME entries, not the plain SPF and DKIM records you might find with some other platforms. If you go looking these records up directly, that's why they don't turn up. Kit walks you through adding the CNAME entries to your DNS, and for most senders, this part is genuinely easy.
• Layer 3 - DMARC Record: Kit provides a default DMARC record you can copy from your account settings and paste into your domain's DNS yourself, a manual copy and paste step unlike SPF and DKIM. That default sits at p=none, the most permissive policy that exists. At p=none, your mail passes DMARC checks, but nothing gets enforced, so someone could still spoof your domain and send mail pretending to be you. Moving up to quarantine or reject closes that gap, but it has to happen slowly and only once you know what your legitimate mail sources look like. No platform walks you through when or how to make that move.
• Layer 4 - DMARC Reporting: Kit's default record is set to p=none and does not appear to include a reporting address. That means most senders using the default record are not receiving any DMARC reports at all, not because the reports are hard to read, but because nothing is set up to generate them in the first place. Getting reports requires adding a reporting address yourself, usually through a separate reporting service that involves another DNS record. Once reports are flowing, they arrive as raw XML files that are difficult to read directly, which is why a monitoring tool that translates them into something readable is worth the extra step.

Common Reasons Senders Are Still Exposed

These show up constantly, in accounts old and new.

1. The custom domain step never got finished. Verifying a custom domain is a manual step inside Kit's settings. It's easy to sign up, connect an integration or two, and never circle back to it. The "via" tag sits there until someone finishes the job.
2. The domain shows "unverified" and nobody chased down why. A handful of specific setup mistakes cause this: including "www" in the custom domain field when it should be left out, DNS records that don't match exactly what Kit provided, or conflicting A and AAAA records left over from a website builder. Any one of these will leave the domain stuck on unverified indefinitely, not just for the 24 to 48 hours DNS normally takes to update.
3. The DMARC record was never manually added. Unlike SPF and DKIM, this one is a manual copy and paste step. Kit hands you a default record inside your account settings and you add it to your domain's DNS yourself. Skip that step, and the record simply does not exist.
4. There's no reporting address to begin with. Kit's default DMARC record doesn't include one. Without a reporting address, no reports get generated at all, so it's not that the reports sit unread, it's that most senders never had any coming in.
5. The default policy never gets tightened. Kit's default DMARC record is set to p=none. That's a fine starting point, but it enforces nothing. Mail that fails authentication still gets delivered. Moving to quarantine or reject is a manual decision, and no platform prompts you to make it automatically.
6. Postmaster Tools gets recommended, not set up. Kit's own help docs point senders toward Google Postmaster Tools as a way to check domain reputation. Almost nobody follows through and sets it up, so the recommendation sits there unused, and nobody catches it when Gmail starts quietly filtering their mail.

What Your DMARC Reports Look Like

Kit's help documentation walks you through adding a DMARC record. What it doesn't really cover is what happens next, since the default record has no reporting address attached, and without one, no reports ever arrive.

If you add a reporting address to your DMARC record, mailbox providers like Gmail and Yahoo start sending aggregate reports back to it, usually once a day. Those reports arrive as compressed XML files, built for software to parse, not for a person to open and read.

For most Kit senders, none of this ever happens, since there's no reporting address in the default record to trigger it. For the senders who do add one, the reports that come in are still hard to use without help, since raw XML isn't something you can skim in an inbox. The record gets added, and the validate button turns green inside Kit. Watching who's sending mail as your domain is the part that never happens.

A dedicated DMARC monitoring tool turns those XML files into a dashboard that's easy to read. It shows which sending sources are passing, which are failing, and whether anything unfamiliar is sending mail as your domain at all. That's a layer outside what any sending platform is built to handle, since Kit's job is getting your email delivered, not auditing every other service that might be sending as you.

What Most Coaches Get Wrong

How to Diagnose This Issue

Frequently Asked Questions

Does Kit set up DMARC for me automatically?

No, not automatically. Kit gives you a default DMARC record inside your account settings, but you copy it and add it to your domain's DNS yourself, the same way you would for any DNS record. It's a manual step, unlike SPF and DKIM, and it's optional rather than required.

What does it mean if my Kit emails still show "via" in the inbox?

It means your custom domain was never fully verified inside Kit, so the message is sending under Kit's shared domain instead of your own. Inbox providers see that and trust the message less than one sent directly from your domain.

What DMARC enforcement level should I start with?

Start at p=none with a reporting address in place, always. That's true the first time you set this up, and it's true again any time you make a real change to how you send, a new platform, a new domain, a new sending tool. Monitor at p=none until the reports confirm your legitimate mail is passing, then move to p=quarantine, then p=reject. Skipping straight to a stricter policy risks blocking your own legitimate mail before you know what's sending on your behalf.

Do I need Google Postmaster Tools if I already use Kit's built in authentication?

Yes, and Kit's own help docs recommend it as a way to check your domain reputation. The gap is not that Kit hides this option, it's that most senders never go set it up. Postmaster Tools shows spam rate and reputation trends that Kit's own dashboard does not surface.

Can I just ignore DMARC if SPF and DKIM are already set up?

You can, but you will have no visibility into who else is sending mail as your domain, and no record of whether your authentication is holding up over time. DMARC with reporting is what turns authentication from a one time setup into something you can monitor.

If I have a DMARC record, why can't I understand the reports it sends?

Because most senders never receive one to begin with. DMARC aggregate reports only get generated if your record includes a reporting address, and Kit's default record does not. If you add one yourself, the reports that come back arrive as compressed XML files built for software to parse, not for a person to open in their inbox. A DMARC monitoring tool converts those files into a readable dashboard instead.

Will fixing my domain verification hurt my open rates?

You may see a temporary dip, and that's normal, not a sign something went wrong. Once your domain is verified, you stop borrowing Kit's shared domain reputation and start relying entirely on your own. Mailbox providers recalculate your reputation whenever a change like this happens, and it typically settles back to normal within two to three weeks of consistent sending. Suppressing your cold subscribers during that window speeds up the recovery.

How do I know if my Kit setup is the reason my emails go to spam?

Check for the "via" tag first, then check whether a DMARC record exists at all. If either is missing, that is a real gap. If both are in place and you are still landing in spam, the cause is more likely engagement or list hygiene than authentication.

If You Only Fix One Thing

If you already have Kit's default DMARC record in place, check whether it includes a reporting address. It probably doesn't, which means it's monitoring nothing. Add one, then either read what comes back yourself or set up a monitoring tool that reads it for you. The record existing and the record being useful are two different things.

Final Thoughts

Kit made the easy part easy. SPF and DKIM take a few clicks inside their dashboard, and Kit will even hand you a default DMARC record if you go looking for it. The parts that stay manual, on Kit or any platform, are verifying the custom domain, deciding whether p=none is still the right policy, checking the reports for anything unfamiliar, and moving the policy up when the data says it's safe.

If you are not sure where your own setup stands, do not guess.