Research · Deliverability guide · Living page
Email newsletter deliverability: why newsletters go to spam and what to set up
The short version: most newsletters land in spam for one of three reasons: missing authentication records (SPF, DKIM, DMARC), a dirty or disengaged list, or both. Authentication is now a regulatory requirement enforced at the SMTP level by Gmail, Yahoo, and Microsoft — missing records mean rejected mail, not a spam-folder detour. On Kit, DKIM and SPF are handled when you set up a Verified Sending Domain; DMARC is a separate step you add to your own DNS. List hygiene is the non-technical side: only mail people who asked, remove non-openers regularly, and never buy a list.
Delivery rate and inbox placement are different things
A high delivery rate means the receiving mail server accepted the message. It says nothing about whether the message landed in the inbox, the spam folder, or a filtered tab. The distinction matters because most email platforms report delivery rate, and inbox placement can be far lower.
Validity, which operates the Sender Score reputation database, puts the typical inbox placement benchmark at: at least 85% is good, 98 to 99% is ideal, below 70% signals a broken program. By their estimate, roughly one in six emails never reaches the inbox globally.
Kit publishes a 99.8% delivery rate: "Last month, Kit sent over a billion messages with a delivery rate of 99.8%." That reflects the platform's sending infrastructure. Whether your newsletter hits that rate depends on your domain authentication and list quality.
Why authentication is now mandatory
As of November 2025, Gmail, Yahoo, and Microsoft reject non-compliant email at the SMTP level — enforcement is most strict for bulk senders (Google and Microsoft apply mandatory requirements at 5,000+ emails/day), but SPF and DKIM are checked by all major mailbox providers regardless of volume. The message never enters a spam folder. It bounces. The trigger is missing or misaligned authentication records.
For newsletter senders, the threshold requirements are: an SPF record confirming Kit is authorized to send from your domain, DKIM signatures on every outgoing message, a DMARC policy record on your domain, and a spam complaint rate below 0.3%.
There is a useful convergence documented in email compliance research: compliant programs and deliverable programs are built from the same parts. The behaviors ISPs penalize with spam filtering (hidden sender identity, hard-to-find unsubscribe, purchased lists) are the same behaviors regulators penalize under CAN-SPAM, GDPR, and CASL. One checklist covers both.
The three authentication records: what each does
SPF (Sender Policy Framework) is a DNS record on your domain listing which mail servers are authorized to send email from your address. Without it, receiving servers have no way to verify the message is legitimate. On Kit, SPF authentication is established through the Verified Sending Domain setup: you add a CNAME record Kit provides, rather than a traditional SPF TXT record on your root domain.
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing email. The receiving server checks the signature against a public key in your DNS. If they match, the message passed in transit without tampering. Kit configures DKIM automatically when you set up a Verified Sending Domain.
DMARC (Domain-based Message Authentication, Reporting and Conformance) sits on top of SPF and DKIM and tells receiving servers what to do when a message fails those checks: nothing (p=none), quarantine it (p=quarantine), or reject it outright (p=reject). DMARC also generates aggregate reports showing who is sending mail from your domain, which surfaces spoofing attempts.
On Kit, DKIM and SPF are set up together through Verified Sending Domain. DMARC is a separate step you add as a TXT record at your domain host. Kit's blog is clear on this split: "Kit authenticates DKIM and SPF automatically; DMARC requires manual setup through your domain host."
Kit-specific setup: what Kit handles and what you add
The setup divides into two buckets:
| Authentication step | Who handles it | Where |
|---|---|---|
| SPF configuration | Kit (via CNAME) | Settings → Email → Verified Sending Domain |
| DKIM signing | Kit (automatic) | Settings → Email → Verified Sending Domain |
| DMARC record | You (manual DNS entry) | Your domain registrar or DNS host |
| Double opt-in enforcement | Kit (default on) | Form settings — leave it on |
| Hard bounce handling | Kit (automatic) | Suppressed automatically after a hard bounce |
| One-click unsubscribe | Kit (built-in) | Every email footer — required by Gmail and Yahoo rules |
| List hygiene (removing cold subscribers) | You (manual or via automation) | Subscribers view, filtered by engagement |
Setting up a Verified Sending Domain in Kit
Go to Settings, then Email, in your Kit dashboard. Under the Verified Sending Domains section, click "Set up your Verified Sending Domain." Enter your domain or subdomain. Kit offers two paths: automatic setup via Entri, which detects your DNS provider and configures the CNAME records, or manual setup where you copy the provided records and add them at your registrar. After adding the records, click Validate.
Worth knowing before you start: Kit flags that you may see a temporary drop in open rates after setting up a Verified Sending Domain. Mailbox providers re-evaluate sender reputation when major sending configuration changes occur, and recovery typically takes two to three weeks of consistent sending. This is expected behavior.
Adding DMARC as a separate step
Once your Verified Sending Domain is live and passing SPF and DKIM, add a DMARC record at your domain registrar. Kit recommends starting with p=none, the monitoring-only policy that generates reports without affecting email delivery. Once you have reviewed a few weeks of reports and confirmed legitimate mail passes authentication, move toward p=quarantine and eventually p=reject.
Kit's guidance is explicit: "If you decide to use a DMARC record on your domain, you need to set up a Verified Sending Domain in your Kit account in order for your emails to reach the inbox." Set up Verified Sending Domain first, DMARC second. And once added: do not remove either one.
List hygiene: the non-technical side of deliverability
Authentication solves the identity problem: it proves you are who you say you are. List hygiene solves the engagement problem: it proves your subscribers want your mail. Both matter. Spam complaint rates above 0.3% damage sender reputation regardless of how clean your authentication records are.
The high-risk failures, per Kit's deliverability documentation: importing contacts who never opted in, mailing previously unsubscribed addresses (which become traps), and sending to disengaged lists without a re-engagement step or list pruning. The specific signals mailbox providers track are "unopens, deletes, opt-outs, and marking emails as spam." A list that stops opening eventually becomes a deliverability liability.
The practical steps are: enable double opt-in on every form (Kit has this on by default, keep it there), suppress bounces and unsubscribes before any list import, and run a re-engagement sequence for subscribers who have not opened in 90 days before removing them. The subscribers you remove lower your complaint risk more than they lower your reach.
What we set up on our own account
We launched the Field Tested newsletter on Kit in July 2026. The authentication setup we ran through, documented for replication:
We set up a Verified Sending Domain through Settings → Email, using Cloudflare as our DNS provider (supported by Kit's Entri integration). The flow added two CNAME records — one for SPF delegation via Kit's subdomain method, one for DKIM — and validated within a few minutes. We then added a DMARC TXT record at _dmarc.fieldtestedhq.com with p=none to start collecting reports before tightening enforcement.
Double opt-in was on by default on our Kit forms. We have not hit the list-hygiene phase yet: our list is in early growth and every subscriber is recent enough that engagement rate is a meaningful signal. The re-engagement and pruning piece of deliverability is one we cannot report from first-hand experience yet.
What this page does not cover yet
Inbox placement testing requires dedicated tools (GlockApps, MXToolbox, or similar seed-list services) that we have not run yet. The setup above covers authentication compliance; it does not guarantee inbox placement for any specific subscriber's mailbox provider.
Dedicated IP addresses are a separate question. Kit offers a dedicated IP option, but their guidance recommends evaluating it carefully: a dedicated IP starts with zero reputation, which can hurt deliverability for smaller lists. Shared IPs benefit from Kit's established sending reputation. For a new or growing newsletter: start on shared IPs, move to dedicated only once you are sending consistently at high volume.
Looking for platform comparison rather than setup guidance? Our email marketing tools compared page covers 16 platforms on free tiers, pricing, and affiliate-link policies. If your main concern is what your platform's own terms allow you to put inside your emails, that is covered in our affiliate-programs-in-email comparison.
Sources
Changelog
This page updates when Kit's authentication requirements change or when we have first-hand inbox placement data to add.