SPF, DKIM and DMARC explained for newsletter writers
SPF, DKIM and DMARC are DNS records that prove your newsletter comes from you. SPF lists who may send for your domain, DKIM signs each message, and DMARC checks that your From address matches and says what to do when it does not. Gmail, Yahoo and Outlook require all three for bulk senders.
Most newsletter writers meet these three acronyms the same way: a warning banner in their platform, or an issue that suddenly lands in spam. They sound like server administration, and they partly are. But what you need to know to set them up correctly for a newsletter fits in one article, and you only have to do it once.
Why they exist
Email was designed without any way to prove who sent a message. Anyone can put any address in the From line, which is how phishing works. SPF, DKIM and DMARC are the patches added over the years to fix that, and since 2024 Gmail, Yahoo and Microsoft have made them a condition for sending in volume.
For you, they do one job: they let the receiving server confirm that a message claiming to come from your domain really does.
SPF: who is allowed to send
SPF (Sender Policy Framework) is a single TXT record in your domain's DNS that lists the servers allowed to send mail for it. When a message arrives, the receiving server checks whether the server that delivered it is on your list.
A typical record looks like this:
v=spf1 include:_spf.google.com include:sendgrid.net ~allEach include: adds a provider's servers. The ~all at the end means "anything else is suspicious".
Three things to know:
- You get one SPF record per domain. If your platform tells you to add one and you already have one for your work mail, you merge them into a single record. Two SPF records is a common error, and it makes SPF fail.
- There is a limit of ten DNS lookups. Every
include:counts, and some count several times. Add too many services and SPF breaks silently. - SPF checks the hidden sender, not the visible one. It looks at the return-path address used behind the scenes, which many platforms set to their own domain. That is why SPF alone often does not help your From address, and why DMARC exists.
DKIM: a signature on every message
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to the headers of each email. Your platform signs with a private key, and you publish the matching public key in your DNS, usually as a CNAME record the platform gives you, something like s1._domainkey.yourdomain.com.
The receiving server fetches the public key and checks the signature. If it matches, two things are proven: the message was signed by someone with access to your domain's key, and it was not altered on the way.
DKIM is the more robust of the two checks, because it survives forwarding, which SPF does not. Yahoo requires keys of at least 1024 bits. Your platform handles the key; your only job is to publish the record it gives you and wait for it to show as verified.
DMARC: tying it to the address readers see
DMARC (Domain-based Message Authentication, Reporting and Conformance) is a TXT record at _dmarc.yourdomain.com. It does two things.
First, it checks alignment: that the domain in your visible From address matches the domain that passed SPF or DKIM. If your newsletter says it comes from [email protected] but the DKIM signature belongs to your platform's domain, DMARC fails even though DKIM technically passed.
Second, it tells receivers what to do with mail that fails, through the policy:
p=none: do nothing special, just send me reports.p=quarantine: put failing mail in spam.p=reject: refuse failing mail.
A starting record looks like this:
v=DMARC1; p=none; rua=mailto:[email protected]Gmail and Yahoo accept p=none as the minimum for bulk senders, and that is the right place to start. The rua address receives daily reports from providers listing who sent mail as your domain and whether it passed. Once the reports show that everything legitimate passes, you can move to quarantine.
Alignment is where newsletters fail
In my experience, missing records are rarer than misaligned ones. The pattern is always the same: the newsletter uses a custom From address on your own domain, but the platform sends and signs with its shared domain. SPF passes for the platform, DKIM passes for the platform, and DMARC fails for you.
The fix is to verify your sending domain inside your newsletter platform. Each platform has a page for it, usually under settings and domains, and it gives you the exact records to add: a DKIM key, sometimes a return-path record for SPF, and a DMARC check. Once those are in place, the signature carries your domain and alignment passes.
If you would rather not manage DNS at all, the alternative is to send from the platform's own domain. Alignment then works out of the box, at the cost of your address not being on your own domain.
How to check your setup
Before trusting a green tick in your platform, check the result on a real message:
- Send an issue to a Gmail address you control.
- Open it, click the three dots and choose "Show original".
- Look for three lines near the top: SPF, DKIM and DMARC. All three should say PASS.
If DMARC fails while DKIM passes, you have an alignment problem. If SPF fails, look for a duplicate record or too many lookups. For a fuller check across providers, an inbox placement test covers authentication and placement in one go.
Frequently asked questions
Do I need all three records for a small newsletter?
Gmail's minimum for low-volume senders is SPF or DKIM, but bulk senders need both plus DMARC, and the bar keeps rising. Setting up all three takes about an hour and removes one whole category of problems, so there is no good reason to skip any of them.
Can a wrong DMARC policy block my own newsletter?
Yes. Publishing p=reject before every service that sends as your domain is aligned will cause providers to refuse those messages. Start with p=none, read the reports for a few weeks, and tighten the policy only when everything legitimate passes.
Why does DMARC fail when SPF and DKIM both pass?
Because they passed for a different domain. DMARC only counts a check that passed for the same domain as your visible From address. Verifying your custom sending domain in your newsletter platform usually fixes it.
How long do DNS changes take to work?
Usually minutes to a few hours, occasionally up to a day or two depending on the TTL of the record. Wait until your platform shows the domain as verified, then confirm with "Show original" on a real message.
Sources
- Google, Email sender guidelines FAQ
- Yahoo, Sender best practices
- Microsoft, Outlook's new requirements for high-volume senders