Blog · DNS
SPF, DKIM and DMARC explained: why your marketing emails land in spam
If your newsletters and campaign emails keep landing in spam, three DNS records are the first place to look. Here's what SPF, DKIM and DMARC do, and how to set them up without breaking anything.
LS Techno Team5 min readUpdated

You've written the campaign, segmented the list and hit send, and a large share of it goes straight to spam. There are many reasons that can happen, but one of the most common, and most fixable, is missing or broken email authentication.
Email authentication comes down to three DNS records: SPF, DKIM and DMARC. Together they prove to Gmail, Outlook, Yahoo and other inbox providers that an email claiming to come from your domain really does. Without them, your emails look exactly like the spoofed messages spam filters exist to stop.
Key takeaways - SPF lists which servers may send email for your domain. - DKIM adds a tamper-proof signature to each email. - DMARC tells inbox providers what to do when a message fails, and sends you reports. - Since 2024, Google and Yahoo have required authentication from bulk senders, and Microsoft introduced similar rules for Outlook.com mailboxes in 2025. Authentication is now the entry ticket to the inbox.
Why authentication matters now
Email was designed without any built-in way to prove who sent a message. Anyone can put your domain in the "From" line. SPF, DKIM and DMARC were added over the years to close that gap.
For a long time they were recommended but optional. That changed in February 2024, when Google and Yahoo began enforcing requirements for bulk senders (Google defines these as domains sending around 5,000 or more messages a day to Gmail addresses). Those senders need:
- SPF and DKIM set up for their sending domain;
- a DMARC record (a policy of
p=noneis the minimum); - the domain in the visible "From" address aligned with SPF or DKIM;
- one-click unsubscribe for marketing email;
- spam complaint rates kept low (Google's threshold is 0.3%, with 0.1% as the target).
Even if you send far fewer emails, the same signals affect where your messages land. Treat these rules as the baseline for any business that sends marketing email.
SPF: who is allowed to send for you
Sender Policy Framework (SPF) is a TXT record on your domain that lists the services allowed to send email on your behalf: your email provider, your CRM, your newsletter platform, your invoicing tool, and so on.
A typical SPF record looks like this:
example.com. TXT "v=spf1 include:_spf.google.com include:sendgrid.net ~all"
v=spf1marks it as an SPF record.- Each
include:adds a sending service (the value comes from that service's setup instructions). ~allmeans "anything else is suspicious" (soft fail).-allmeans "anything else should be rejected" (hard fail).
Common SPF mistakes
- Two SPF records. You can only have one per domain. If a second tool asks you to "add an SPF record", merge its include: into the existing one instead.
- Too many lookups. SPF allows a maximum of 10 DNS lookups. Each include: can trigger several. Stacks with many tools hit this limit easily, and SPF then fails for everything.
- Forgotten tools. The helpdesk, the booking system and the e-commerce platform all send email as you. If they're not in SPF (or using DKIM with your domain), their emails fail.
DKIM: a signature that proves the email wasn't changed
DomainKeys Identified Mail (DKIM) adds a digital signature to every email. The sending service signs the message with a private key; your domain publishes the matching public key in DNS. Inbox providers use it to check that the email really came from an authorized sender and wasn't altered on the way.
A DKIM record sits on a subdomain called a selector:
s1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
Each sending service gives you its own selector and key (sometimes as a CNAME record pointing to their DNS instead). You add one record per service.
Common DKIM mistakes - Signing with the provider's domain, not yours. Many platforms sign with their own domain by default. That passes DKIM technically but doesn't align with your "From" domain, so it doesn't help DMARC. Always complete the "authenticate your domain" step in each tool. - Short keys. Use 2048-bit keys where the provider supports them. - Old selectors left behind. Remove records for tools you no longer use.
DMARC: the policy that ties it together
Domain-based Message Authentication, Reporting and Conformance (DMARC) does two jobs:
- It tells inbox providers what to do with messages that fail SPF and DKIM alignment: nothing (
none), send to spam (quarantine) or block (reject). - It asks them to send you reports showing who is sending email using your domain.
A starting DMARC record:
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
The key idea in DMARC is alignment: the domain in the visible "From" address must match the domain that passed SPF or DKIM. That's what stops a spammer from passing SPF with their own domain while putting yours in the "From" line.
Moving from monitoring to protection
Don't jump straight to p=reject. You'll block your own legitimate emails from tools you forgot about. Instead:
- Start with
p=noneand collect reports for two to four weeks. - Review the reports. Identify every legitimate service sending as you and fix its SPF or DKIM.
- Move to
p=quarantine, optionally for a percentage of mail first (pct=25, then 50, then 100). - Move to
p=rejectonce reports show only legitimate, aligned traffic.
DMARC reports arrive as XML files that are hard to read by eye. A DMARC reporting tool turns them into something you can act on.
A quick way to check your setup
- Send an email from each tool that emails your customers (newsletter, CRM, helpdesk, store) to a Gmail address.
- In Gmail, open the message, click the three dots and choose Show original.
- Look for
SPF: PASS,DKIM: PASSandDMARC: PASS. Check that the DKIM line shows your domain.
If any tool shows a fail, or DKIM signs with the platform's domain instead of yours, you've found a deliverability problem.
Authentication is necessary, but not the whole story
SPF, DKIM and DMARC get you through the door. Whether you stay in the inbox also depends on:
- List quality. Only email people who opted in; remove bounces and long-inactive contacts.
- Complaint rates. Make unsubscribing easy. A complaint does more harm than an unsubscribe.
- Consistency. New domains, and sudden jumps in volume, look suspicious. Warm up gradually.
- Content and engagement. Emails people open and reply to build reputation.
A good setup also uses a subdomain for marketing email (for example news.example.com), so the reputation of bulk campaigns doesn't affect the day-to-day email your team sends from the main domain.
A note on BIMI
Once DMARC is at quarantine or reject, you can add BIMI, which lets supporting inbox providers show your logo next to your emails. Some providers also require a verified mark certificate. It's a nice extra, but only after the foundations are in place.
FAQ
Do small senders need DMARC?
Yes. Even if you're below the bulk-sender thresholds, DMARC protects your domain from spoofing and improves deliverability. There's no reason not to have at least p=none with reporting.
Will changing SPF or DMARC break our email?
It can, if records are changed carelessly. Merging SPF records incorrectly or moving to p=reject too early are the usual culprits. Change one thing at a time and monitor.
How long do DNS changes take?
Usually minutes to a few hours, depending on the record's TTL (time to live) and your DNS provider.


