How to set up SPF, DKIM, and DMARC for newsletter deliverability (2026)
Set up SPF, DKIM, and DMARC so your newsletter lands in the inbox. A step-by-step DNS guide to passing Gmail and Yahoo bulk-sender authentication rules.
SPF, DKIM, and DMARC are three DNS records that tell receiving servers your email is really from you. Skip them and your newsletter lands in spam — or, since Gmail, Yahoo, and Microsoft tightened their rules, gets rejected outright. The requirement became concrete on February 1, 2024, when Google and Yahoo began requiring bulk senders (roughly 5,000+ messages a day to personal accounts) to authenticate with SPF, DKIM, and DMARC, keep spam complaints low, and offer one-click unsubscribe. Enforcement started as temporary errors in February 2024 and moved to rejecting a growing share of non-compliant mail from April 2024 onward.
The three records do different jobs and you need all three working together. SPF says which servers may send for your domain. DKIM cryptographically signs each message so a receiver can prove it wasn't altered. DMARC ties both back to the address your readers actually see — the From header — and tells receivers what to do when a message fails. This walkthrough sets them up in the order that actually works, and spends extra time on alignment, which is where most senders pass SPF and DKIM yet still fail DMARC. If your end goal is turning that newsletter into more than an email, pair this with [turn one newsletter into a week of social posts](/how-to/turn-one-newsletter-into-a-week-of-social-posts).
The steps
Understand what each of the three records proves. Before you touch DNS, get the model straight. SPF (a TXT record) lists the servers allowed to send from your domain and is checked against the hidden Return-Path/envelope sender, not the visible From. DKIM (published as a CNAME or TXT at a selector) adds a signature a receiver verifies against your public key, proving the message is intact. DMARC (a TXT record) checks that SPF or DKIM passed AND that the passing domain aligns with your From address, then applies your chosen policy. SPF and DKIM are the evidence; DMARC is the rule that uses it.
Pin down your sending domain and your email provider. Authentication is per sending domain, so decide which domain your newsletter's From address uses (e.g. news@yourbrand.com) and find the exact SPF include, DKIM keys, and MAIL FROM/Return-Path your email platform gives you. Every ESP — Mailchimp, your own server, anything — publishes its own values on an authentication or sending-domain page. Collect all three before editing DNS; guessing the include or selector is the most common way this goes wrong.
Publish your SPF record. Add one TXT record at your sending domain containing your provider's include and nothing duplicated. A typical value looks like `v=spf1 include:_spf.yourprovider.com ~all`. Critical rule: you may have only ONE SPF record per domain — merge multiple senders into a single `v=spf1 ... ~all` string rather than publishing two, which causes a permerror. Keep the total DNS lookups under ten, or SPF silently breaks.
Add your DKIM keys. Publish the DKIM records your provider generated, usually one to three CNAME entries at `selector._domainkey.yourdomain.com` pointing to your provider's key host, or a TXT record holding the public key directly. Do not route these through an HTTP proxy (disable the orange-cloud/proxy toggle so they resolve as DNS only), and do not paste the full hostname into a form that already appends your zone — that creates a doubled name that never resolves. DKIM is the authentication method most likely to survive forwarding, so it's worth getting right.
Publish a DMARC record starting at p=none. Add a TXT record at `_dmarc.yourdomain.com`. Start in monitor mode: `v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com`. `p=none` satisfies the bulk-sender minimum and tells receivers to take no action yet while sending you aggregate reports, so you can confirm legitimate mail is passing before you tighten anything. Resist jumping straight to `p=reject` — you'll bounce your own newsletter if a sending source isn't aligned yet.
Fix alignment — the step that actually passes DMARC. This is where senders who "set up all three" still fail. DMARC passes only if the domain that passed SPF or DKIM matches your visible From domain (an exact or same-organizational-domain match). If your ESP sends with its own Return-Path, SPF passes for THEIR domain and DMARC fails for yours — so set a custom MAIL FROM/Return-Path on a subdomain of your own domain, or rely on a DKIM signature whose `d=` is your domain. Note too that SPF plus DMARC without DKIM fails Google's bulk-sender rule: you need a passing, aligned DKIM signature, not just SPF.
Send a real test and read the authentication headers. Send a genuine newsletter through your actual sending path to a Gmail account, open it, and use "Show original." You want to see `spf=pass`, `dkim=pass` with your own domain in the signature, and `dmarc=pass`. If DMARC fails while SPF and DKIM pass, it's an alignment problem from the previous step, not a missing record. Testing with real mail beats a lookup tool because it exercises the exact path your subscribers receive.
Monitor reports, then graduate the policy and meet the rest of the bar. Read the DMARC aggregate reports for a week or two until every legitimate source passes aligned, then tighten `p=none` to `p=quarantine` and eventually `p=reject` to block spoofing. Authentication is necessary but not sufficient: bulk senders also need RFC 8058 one-click unsubscribe honored within two days, a Postmaster Tools spam-complaint rate below 0.30% (aim under 0.10%), valid PTR records, and TLS. Relevance and list hygiene carry the rest.
Common gotchas
Publishing two SPF records on the same domain. Only one `v=spf1` TXT is allowed per domain — a second one causes a permerror and SPF fails for everyone. Merge all senders into a single record.
Passing SPF but failing DMARC. This is almost always alignment: SPF authenticated your provider's Return-Path domain, not your From domain. Set a custom MAIL FROM on your own subdomain or lean on an aligned DKIM signature.
Having SPF and DMARC but no DKIM. Google's bulk-sender requirement needs a passing, aligned DKIM signature too — SPF plus DMARC alone does not satisfy it.
Proxying DKIM CNAME records. Running them through an HTTP proxy (the orange-cloud toggle) stops them resolving as DNS, so verification fails. Set DKIM records to DNS-only.
Doubling the DNS name. Pasting the full hostname into a form that auto-appends your zone creates names like `selector._domainkey.yourdomain.com.yourdomain.com` that never resolve. Enter only the part the form asks for.
Jumping to p=reject before monitoring. Enforce too early and any unaligned legitimate source — including your newsletter — gets bounced. Sit at p=none until the reports are clean.
Expecting authentication to fix spam placement by itself. It's the entry ticket, not the whole game; reputation, complaint rate, list hygiene, and relevance decide inbox versus spam after you pass.
Exceeding ten DNS lookups in SPF. Each include and mechanism counts; past ten, SPF returns permerror and silently stops authenticating. Flatten or consolidate includes.
Where Kompozy fits
Be clear on the division of labor: SPF, DKIM, and DMARC are DNS-and-ESP work on your domain, and Kompozy does not touch your DNS zone or configure them for you. That's honest — authentication is the one part of newsletter delivery that lives at your registrar and your email platform, and no content engine should pretend to own it. What Kompozy is a full AI content generation and multi-platform publishing engine for is everything on the other side of a clean setup: once your domain passes, the question becomes what you send and how far it travels.
Kompozy generates [Email Newsletters](/glossary/output-buckets) governed by your [Persona Brief](/glossary/persona-brief) and banned-word filters, and publishes them through your connected Mailchimp account — the same sending identity you just authenticated — so the deliverability you earned here is what every issue rides on. Because the Persona Brief keeps each issue on-voice and on-topic rather than generically padded, it works with, not against, the relevance and low-complaint signals that decide inbox placement after authentication passes; the one-click unsubscribe and complaint-rate bar from the final step stay with your ESP, exactly where this tutorial leaves them.
The bigger reason this setup pays off: the inbox stops being your only distribution. Kompozy turns one newsletter into native posts across the eight social platforms plus blog — a [Carousel](/glossary/output-buckets) of the main framework, text posts for X and LinkedIn, a [Persona Short](/glossary/persona-shorts) reading the lead story — all scheduled from one draft, so a quiet inbox week never zeroes your reach. Each piece waits in a review queue for your sign-off, and [Autopilot](/glossary/autopilot) is opt-in per source when you trust an issue to fan out hands-off. Starter is $199/mo (5,500 credits) for a solo newsletter operator; Pro is $499/mo (18,000 credits) for a brand running email plus multi-platform cadence; Enterprise is custom.
Frequently asked questions
Do I really need all three for a newsletter?
Yes, if you send at bulk volume. Since February 1, 2024, Gmail and Yahoo require senders of roughly 5,000+ messages a day to personal accounts to have SPF, DKIM, and DMARC, with one of SPF or DKIM aligned to the From domain and a DMARC policy of at least p=none. Below that volume you can often pass on SPF or DKIM alone, but configuring all three is the only setup that's safe as your list grows and is best practice regardless.
What is the difference between SPF, DKIM, and DMARC?
SPF lists which servers may send for your domain and is checked against the hidden envelope sender. DKIM adds a cryptographic signature proving the message wasn't altered in transit. DMARC ties both results to your visible From address, requires that a passing method aligns with it, and tells receivers what to do on failure — monitor (p=none), quarantine, or reject. SPF and DKIM are the evidence; DMARC is the policy that acts on it.
Why does my email pass SPF but still fail DMARC?
Almost always alignment. DMARC passes only when the domain that passed SPF or DKIM matches your From domain. Many email platforms send with their own Return-Path, so SPF passes for the provider's domain, not yours, and DMARC fails. Fix it by setting a custom MAIL FROM/Return-Path on a subdomain of your own domain, or by relying on a DKIM signature whose `d=` value is your domain.
What DMARC policy should I start with?
Start with `p=none` plus a `rua` reporting address: `v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com`. That meets the bulk-sender minimum, takes no action on mail, and sends you aggregate reports so you can confirm every legitimate source passes aligned. Once the reports are clean, tighten to `p=quarantine` and then `p=reject` to actually block spoofing of your domain.
How many emails can I send before these rules apply?
Google treats a sender as bulk at roughly 5,000 or more messages to personal Gmail accounts in a 24-hour period; Yahoo applies the same requirements without publishing a hard number, flagging any significant volume. Enforcement began as temporary errors in February 2024 and progressed to rejecting a rising share of non-compliant mail from April 2024, so treat the requirements as live now rather than optional.