SPF, DKIM, DMARC: A Practical Guide to Hardening Email Deliverability and Stopping Spoofing
Anyone can send mail that claims to come from your domain, and that's how most spoofing and Business Email Compromise (BEC) starts. SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting & Conformance) are three DNS records that let receivers check whether a message really came from you.
This guide explains how each one works, how to roll them out, and the practices that hold up at enterprise scale. DMARC is now defined by RFC 9989 (May 2026), which replaced RFC 7489.
The Email Security Trio: Understanding SPF, DKIM, and DMARC
Think of SPF, DKIM, and DMARC as three layers of verification for your email, each confirming a different aspect of its authenticity.
1. SPF: Who Can Send For Your Domain?
SPF answers a deceptively simple question: which servers are allowed to send mail for your domain? You publish a list of authorized mail servers, by IP address or by include: reference, in a DNS TXT record. When a receiving mail server gets a message claiming to be from you, it checks that list and confirms the sending IP is on it. If a random server somewhere starts blasting mail with your domain in the envelope, SPF gives the recipient a clean reason to distrust it.
2. DKIM: Has This Email Been Tampered With?
DKIM is the cryptographic signature on top of the message itself. Your sending mail server signs outgoing emails with a private key, and you publish the matching public key as a DNS TXT record. The receiving server fetches that public key and verifies the signature, which proves two things at once: the message really came from a server that held your private key, and the headers and body weren't modified in transit. Forwarding breaks SPF, but DKIM usually survives it, because the signature travels with the message.
3. DMARC: What Should Be Done With Unauthenticated Email?
DMARC is the policy layer that ties SPF and DKIM together and tells receivers what to actually do when authentication fails. You publish a DMARC record telling receiving servers to take no action (p=none), quarantine to spam (p=quarantine), or reject outright (p=reject). Just as important, DMARC turns on aggregate reporting through the rua tag, so participating receivers send you XML reports of the IPs sending mail as your domain. That's how you discover the legitimate sender you forgot about, and the spoofer you didn't know existed.
Getting Started: Implementing Email Authentication
Roll these out in order: SPF first, then DKIM, then DMARC in monitoring mode before you ever turn on enforcement. Skipping the monitoring step is how teams block their own payroll emails on a Friday afternoon.
Phase 1: Implement SPF (Sender Policy Framework)
SPF is usually the easiest of the three to configure, but only if you know every system that sends mail as you. Start there. Inventory everything: your own mail servers, Google Workspace or Microsoft 365, transactional providers like Mailgun or SendGrid, marketing platforms like Mailchimp, your CRM, your helpdesk, your CI pipeline if it emails build notifications. The senders you forget about are exactly the ones that will fail later.
Once you have the list, build a TXT record that starts with v=spf1, pulls in each provider with include: (such as include:_spf.google.com or include:mailgun.org), and adds any direct IP ranges with ip4: or ip6:. End the record with a qualifier. Use ~all (soft fail) for the initial rollout so unlisted senders get flagged as suspicious without being blocked, and switch to -all (hard fail) once you're confident the inventory is complete.
# Example SPF Record (TXT Type)
# Name: @ (or your domain, e.g., example.com)
# Value: v=spf1 include:_spf.google.com include:mailgun.org ~all
This example authorizes Google Workspace and Mailgun, and soft-fails any other sender.
Phase 2: Implement DKIM (DomainKeys Identified Mail)
DKIM takes a bit more coordination because the keys live with your email service providers. Each ESP generates a private/public key pair on their side, hands you a selector name (something like google or s1) and the public key, and expects you to publish that public key in DNS at selector._domainkey.yourdomain.com. The provider keeps the private key and uses it to sign every outgoing message, and receivers fetch the public key from your DNS to verify.
# Example DKIM Record (TXT Type) for Google Workspace
# Name: google._domainkey (where 'google' is the selector)
# Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...
Each ESP will provide its own specific instructions for this record.
Phase 3: Implement DMARC (Policy and Reporting)
DMARC is where SPF and DKIM finally come together. Publish a TXT record at the _dmarc subdomain, and start in monitoring mode.
# Example DMARC Record (TXT Type) - Monitoring Mode
# Name: _dmarc
# Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com;
The v=DMARC1 tag declares the version, p=none tells receivers to take no action on failures (you just want data right now), and rua=mailto:dmarc-reports@yourdomain.com is the one tag you cannot skip. That's the address that will receive aggregate XML reports showing SPF and DKIM pass and fail rates for everything claiming to be your domain, including the senders you forgot about and the ones impersonating you.
Run that for at least 30 to 60 days and feed the reports into a DMARC reporting service. Free and paid options both exist. What matters is having something that parses the XML into something readable so you can identify every legitimate sender and fix any alignment failures before enforcement.
Once legitimate traffic is consistently passing, move to p=quarantine (optionally with t=y first, which receivers treat like p=none). Failed messages now go to spam folders instead of inboxes, which gives you a safety net: if you misjudged something, recipients can still fish the mail out of junk. After another monitoring window with low legitimate failures and clear spoof activity getting caught, move to p=reject. At that point unauthenticated mail is blocked outright at the receiver, which is the goal.
Deep Dive: Enterprise Implementation & Best Practices
SPF Best Practices
A few things go wrong with SPF more often than anything else, and they all come back to the same handful of rules. You can only publish one SPF record per domain. A second one doesn't get merged, it breaks both. The record itself has a hard limit of 10 DNS lookups during evaluation, so every include:, a, mx, exists and redirect= counts, and chained includes can blow the budget without you realizing. Make sure every sending source is in the record, because the one you missed is the one that fails on a customer-facing email. Start with ~all while you're validating, switch to -all for real protection once the inventory is stable, and put a calendar reminder to audit the record at least once a quarter so dead providers get pruned and new ones get added.
DKIM Best Practices
Generate 2048-bit RSA keys. 1024-bit keys are technically still accepted but considered weak now and some providers will start to mark them down. Rotate keys on a schedule, annually at minimum, and use distinct selectors for each sending service so rotation and revocation can be scoped per provider instead of taking everything down at once. Watch your DMARC aggregate reports for DKIM-specific failures, which usually point at either a key mismatch, a missing selector, or a relay that's modifying message bodies in ways that break the signature.
DMARC Best Practices
The phased rollout is the single most important practice here. p=none first, then p=quarantine, then p=reject, and don't skip steps. Watch for alignment, which is the rule that the domain in the visible From: header has to match the domain that SPF or DKIM validated. A message can pass SPF and still fail DMARC if the alignment domains don't line up, and that's the failure mode people get tripped up on most.
Point your rua aggregate reports at an inbox you actually read, or better, at a DMARC reporting service that parses them. ruf forensic reports give per-message failure detail, but receivers send them less reliably and privacy rules limit what's in them, so treat them as a nice-to-have. RFC 9989 removed the old pct tag. For a staged rollout, add t=y (testing mode): receivers then apply one policy level below what you publish, so p=reject; t=y is treated like quarantine. And define a subdomain policy with sp= if you have subdomains that should be treated differently from the parent.
# Example DMARC Record for Enforcement (TXT Type)
# Name: _dmarc
# Value: v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; sp=reject; adkim=s; aspf=s;
Integrating Email Security into Your Enterprise Strategy
Email authentication won't stop every email attack on its own. It's one layer of your email security.
1. Multi-Layered Email Security
Authentication is the foundation: SPF, DKIM, DMARC, and BIMI on top to surface your brand logo in supporting inboxes once DMARC is at enforcement. Around that you want a reputation layer that tracks how your domains and sending IPs are scored across major blacklists and feedback loops. Content filtering handles the other half of the problem: spam scoring, attachment sandboxing, URL rewriting, and phishing detection on inbound mail. And on top of all of that, behavioral analytics and threat intel catch the anomalies that pass every static check, like a finance team member suddenly emailing a brand-new wire instruction at 2 a.m.
2. Compliance and Regulatory Considerations
Email security shows up in several regulatory frameworks. GDPR covers data protection, lawful basis for marketing email, and breach notification timing. HIPAA requires transmission security for ePHI (encryption is addressable), which in practice means TLS plus authentication for any clinical communication. PCI DSS requires secure transmission of payment card data, which rules out cleartext email entirely for cardholder information, and PCI DSS v4.0.1 req. 5.4.1 (mandatory since 31 March 2025) names SPF, DKIM and DMARC as examples of anti-phishing mechanisms. SOX touches email retention and archiving for financial controls. The other regulations don't name the three records, but having them deployed gives auditors evidence of email integrity controls.
3. Continuous Monitoring & Maintenance
These policies aren't set-and-forget. Track DMARC authentication pass and fail rates in something you actually look at weekly, so a new sending source or a quietly broken provider shows up before it becomes a deliverability incident. Re-verify the published records themselves periodically, because DNS changes get made for unrelated reasons and SPF includes get clobbered by accident more often than you'd expect. Rotate DKIM keys on schedule. And revisit your policies whenever the sending stack changes or a new regulation lands, because the record you wrote two years ago probably doesn't reflect the providers you use today.
Where Barrion Fits
We check your SPF, DKIM and DMARC records on every scheduled scan (up to daily) across every domain you add, and alert you when one is missing or misconfigured. Barrion doesn't read your DMARC aggregate reports, so it won't see new sending sources. A DMARC reporting service covers that. When a record breaks, the finding tells you what to fix.
Conclusion: Safeguarding Your Digital Communication
SPF, DKIM and DMARC together make spoofing your domain much harder, protect your brand, and improve deliverability as a side effect.
Roll them out in phases, keep watching the reports, and recheck the records whenever your sending stack changes.
Check Your Email Records
Start your free security scan with Barrion today to see how your SPF, DKIM and DMARC records are configured.
Email records are one part of your external surface. For the web app itself, an AI pentest tests whether the issues a scan hints at can actually be exploited.
For detailed analysis and continuous monitoring of your email security, visit the Barrion dashboard.