SPF, DKIM and DMARC Explained: Stop the Spam and Land in the Inbox
Three DNS records decide whether your mail reaches the inbox or gets spoofed by scammers. Here's how SPF, DKIM and DMARC actually work for email deliverability — and how to set them up right.
Key takeaways
- SPF, DKIM and DMARC work as a set: SPF lists who can send, DKIM signs the message, and DMARC enforces a policy and reports failures.
- Since February 2024, Google and Yahoo require all three from bulk senders (5,000+/day) plus a spam rate under 0.3% — or mail gets throttled.
- Always roll out DMARC in stages: p=none to monitor, then p=quarantine, then p=reject. Don't jump to enforcement before fixing legitimate senders.
- Watch the gotchas: one SPF record only, stay under 10 DNS lookups, use 2048-bit DKIM keys, and make sure passes also align with your From domain.
- Every new sending tool can silently break authentication — a host that manages these records for you keeps mail in the inbox.
Why SPF, DKIM and DMARC Matter for Email Deliverability
Email was designed in the 1980s with zero authentication. By default, anyone can put your domain in the "From" field — which is exactly how phishing and spoofing work. SPF, DKIM and DMARC are the three DNS records that fix this. Together they prove a message genuinely came from you and tell receiving servers what to do when it doesn't.
Getting all three right isn't optional anymore. Since February 2024, Google and Yahoo require bulk senders (5,000+ messages a day to their users) to publish SPF, DKIM and DMARC, keep spam complaints under 0.3%, and support one-click unsubscribe. Miss these and mail gets throttled or rejected outright.
The payoff for the spf dkim dmarc email deliverability trio is concrete: fewer messages in spam folders, protection against criminals impersonating your domain, and the data you need to see who's sending mail as you.
Secure business emailOn the fastest servers in the North — free migration, 24/7 human support.Secure business emailSPF: Who Is Allowed to Send for Your Domain
SPF (Sender Policy Framework) is a single TXT record listing the servers and services permitted to send email using your domain. When a receiving server gets your message, it checks the sending IP against this list.
A record looks like: v=spf1 include:_spf.google.com include:servers.mcsv.net -all. Each include authorizes a provider (Google Workspace, Mailchimp, your own mail server). The ending matters: -all means "hard fail anything not listed," while ~all is a softer "suspicious but accept." Use -all once you're confident every legitimate sender is included.
- One SPF record per domain only — multiple TXT SPF records break it.
- Hard limit of 10 DNS lookups; exceed it and SPF returns "permerror" and silently fails.
- SPF alone breaks on forwarding — which is exactly why you also need DKIM.
DKIM: A Tamper-Proof Signature on Every Message
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each outgoing message. Your mail server signs the headers and body with a private key; receivers fetch your public key from DNS and verify the signature hasn't been altered in transit.
Setup is two steps: your provider generates a key pair, and you publish the public key as a TXT (or CNAME) record at a selector like selector1._domainkey.yourdomain.com. Use at least a 2048-bit key — 1024-bit is now considered weak. Because DKIM travels with the message and survives forwarding, it's the more robust of the two authentication checks.
DKIM proves the message is intact and tied to your domain, but on its own it doesn't tell receivers what to do with mail that fails. That's DMARC's job.
DMARC: The Policy That Ties It Together
DMARC (Domain-based Message Authentication, Reporting and Conformance) is the rulebook. It checks that SPF and/or DKIM not only pass but also "align" with the visible From domain, then tells receivers how to handle failures — and emails you reports on what's happening.
A starter record: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. The policy escalates in three stages, and you should walk through them deliberately rather than jumping straight to enforcement.
- p=none — monitor only. Collect reports, fix legitimate senders that fail alignment. Run for 2-4 weeks.
- p=quarantine — failing mail goes to spam. Often paired with pct=25 to ramp gradually.
- p=reject — failing mail is blocked entirely. This is the goal; it's what actually stops spoofing.
- rua= sends aggregate XML reports so you can see every source sending as your domain before tightening the policy.
A Practical Rollout Checklist
Order matters. Authenticate first, monitor, then enforce — rushing to p=reject before fixing your senders will bounce legitimate mail.
Most DNS changes propagate within an hour, though TTL can stretch it to 24-48. Budget a few weeks end to end, mostly spent reading DMARC reports.
- 1. Publish one SPF record with every legitimate sending service, ending in -all.
- 2. Enable DKIM (2048-bit) in your mail provider and publish the public key.
- 3. Add DMARC at p=none with a rua= reporting address.
- 4. Read aggregate reports for 2-4 weeks; fix any real sender that fails alignment.
- 5. Move to p=quarantine (optionally pct=25), then to p=reject once reports are clean.
- 6. Re-test after any change with a tool like a mail-tester or by checking the Authentication-Results header in a received message.
Make Deliverability Someone Else's Problem
SPF, DKIM and DMARC are not set-and-forget. Add a new newsletter tool or CRM and you've quietly created an unauthenticated sender that fails your own policy. Keeping records correct across every service is ongoing work — and the failure mode is invisible: your mail simply stops arriving.
This is where your email host earns its keep. NordicVentures business email hosting ships with SPF, DKIM and DMARC configured correctly from day one, sensible defaults for keys and alignment, and human support that actually understands DNS — backed by the same NVMe infrastructure and 24/7 support behind the fastest servers in the North.
If your mail is landing in spam, your domain has been spoofed, or you just want authentication handled properly without becoming a DNS expert, take a look at NordicVentures secure business email hosting at /business-email-hosting. We'll migrate you for free and get all three records right.
FAQ
Do I really need all three of SPF, DKIM and DMARC?
Yes. SPF and DKIM are authentication checks, but neither tells receiving servers what to do when mail fails — and DMARC won't enforce anything without at least one of them aligned. Google and Yahoo now require all three from bulk senders, and even small senders see better inbox placement and spoofing protection with the full set.
What's the difference between SPF and DKIM?
SPF checks whether the sending server's IP address is on your approved list. DKIM adds a cryptographic signature that proves the message wasn't altered and genuinely came from your domain. SPF can break when mail is forwarded; DKIM survives forwarding, which is why you need both.
Will turning on DMARC block my own email?
Only if you skip the monitoring phase. Start at p=none, which changes nothing about delivery and just sends you reports. Use those reports to find and authenticate every legitimate sender, then move to p=quarantine and finally p=reject. Done in that order, no legitimate mail is blocked.
How long until SPF, DKIM and DMARC start working?
DNS records usually propagate within an hour, though older TTL settings can take 24-48 hours. Authentication itself works immediately once records resolve. The longer part is the DMARC monitoring window — plan on 2-4 weeks of reading reports before moving to an enforcement policy.
How to Set Up Business Email With Domain
A clear, step-by-step guide to getting professional email on your own domain — from choosing a provider to the DNS records that keep your mail out of spam.
GuideDomain vs Email Hosting vs Web Hosting Explained
Three separate services people constantly confuse. Here's what each one actually does, how they connect through DNS, and what you really pay for each.
GuideTypes of Web Hosting: Shared vs VPS vs Cloud vs Dedicated
Four hosting models, four very different trade-offs in performance, control, and cost. Here's how shared, VPS, cloud, and dedicated actually differ — with real numbers — so you can match the plan to your workload instead of overpaying or outgrowing it in six months.