If you manage a domain and send emails – whether transactional, marketing, or internal – understanding SPF and DKIM records is a security essential you can’t afford to skip. These two DNS-based authentication mechanisms determine whether your emails land in inboxes or spam folders, and whether attackers can freely impersonate your business.
I learned this the hard way years ago when a client’s domain ended up on multiple blacklists. The cause wasn’t a breach – it was a missing SPF record that let spammers forge their sender address for weeks before anyone noticed. Cleaning up that mess took months. Since then, I treat SPF and DKIM as day-one priorities for every domain I touch.
What SPF and DKIM Actually Do
SPF (Sender Policy Framework) is a TXT record in your DNS that lists every server authorized to send email on behalf of your domain. When a receiving mail server gets a message claiming to be from you, it checks your SPF record. If the sending IP isn’t listed, the message gets flagged or rejected.
DKIM (DomainKeys Identified Mail) takes a different approach. It attaches a cryptographic signature to every outgoing email. The receiving server verifies this signature against a public key published in your DNS. If the signature doesn’t match – because the message was altered or forged – authentication fails.
Together, they answer two critical questions: “Is this server allowed to send for this domain?” and “Was this message tampered with in transit?”
Why You Can’t Ignore Them in 2025
There was a time when SPF and DKIM were nice-to-have. That time is over. Google and Yahoo now reject emails from domains without properly configured authentication. Microsoft has followed with similar enforcement. If your records are missing or broken, your legitimate business emails simply won’t arrive.
Beyond deliverability, there’s a direct security angle. Without these records, anyone can send emails that appear to come from your domain. Phishing attacks using forged sender addresses remain one of the most effective social engineering techniques. Proper email authentication through DNS configuration is your first line of defense against domain spoofing.
Setting Up SPF: The Basics
An SPF record is a single TXT record on your root domain. A typical example looks like this:
v=spf1 ip4:203.0.113.5 include:_spf.google.com include:amazonses.com ~all
This says: “My mail server at 203.0.113.5, Google Workspace, and Amazon SES are authorized senders. Treat everything else as suspicious.”
The trailing mechanism matters. Use ~all (soft fail) during initial setup so you can monitor without breaking delivery. Once you’re confident your record covers all legitimate senders, switch to -all (hard fail) for strict enforcement.
One critical limitation: SPF allows a maximum of 10 DNS lookups. Every include: statement triggers at least one lookup, and nested includes count too. Exceeding this limit causes your entire SPF record to fail silently – a common misconfiguration that’s surprisingly hard to diagnose. Tools like SPF record flatteners can help, but the real fix is keeping your authorized sender list lean.
Setting Up DKIM: Key Pair and DNS
DKIM setup starts with your email provider generating a key pair. You publish the public key as a TXT record at a specific subdomain, typically something like selector._domainkey.yourdomain.com. The selector name varies by provider – Google uses “google”, SendGrid uses “s1” and “s2”, and so on.
The most frequent DKIM mistake I see is copy-paste errors when adding the public key to DNS. One wrong character and the entire signature validation breaks. Always test after publishing. Send an email to a verification service or check the raw headers of a received message for “dkim=pass.”
Another myth worth busting: rotating DKIM keys is unnecessary. In reality, key rotation is recommended security practice – at minimum annually, or immediately if you suspect a compromise. Stale DKIM keys are a real risk, much like other DNS misconfigurations that create security gaps over time.
The Subdomain Trap
Here’s where many organizations stumble. SPF and DKIM records on your root domain do not automatically protect subdomains. Every subdomain that sends email – marketing.yourdomain.com, support.yourdomain.com, app.yourdomain.com – needs its own authentication records.
In organizations with dozens or hundreds of subdomains, forgotten ones without proper email authentication become easy targets. An attacker who discovers an unprotected subdomain can use it for phishing campaigns that pass basic recipient checks. The hidden risks of forgotten subdomains extend well beyond email, but email spoofing is one of the most immediately exploitable dangers.
Tying It Together with DMARC
SPF and DKIM are the foundation, but DMARC (Domain-based Message Authentication, Reporting and Conformance) is what enforces policy. A DMARC record tells receiving servers what to do when SPF or DKIM checks fail: monitor only (p=none), quarantine, or reject.
Start with p=none and review DMARC reports for a few weeks. These reports reveal every server sending email as your domain – including services you may have forgotten about. Once you’ve accounted for all legitimate senders, move to p=quarantine and eventually p=reject.
The reporting alone makes DMARC invaluable. It’s like running a comprehensive DNS health check specifically for your email ecosystem.
Ongoing Monitoring Is Non-Negotiable
Email authentication breaks more often than people expect. Someone adds a new marketing tool that sends email but forgets to update SPF. A DKIM key expires. A DNS change accidentally overwrites a critical TXT record. These aren’t hypothetical scenarios – they happen constantly.
Regular monitoring catches these issues before they impact deliverability or create security holes. Check your DMARC reports weekly, verify SPF and DKIM records after any DNS change, and audit subdomains periodically for missing authentication.
Frequently Asked Questions
Do I need both SPF and DKIM, or is one enough?
You need both. SPF validates the sending server, DKIM validates message integrity. DMARC requires at least one to pass with domain alignment, but having both provides redundancy and stronger protection. Major providers expect both to be configured.
How do I know if my SPF or DKIM records are broken?
The quickest test is sending an email to a Gmail account and checking the raw message headers. Look for “spf=pass” and “dkim=pass” in the Authentication-Results header. If either shows “fail” or “neutral,” your records need attention. DMARC aggregate reports also highlight authentication failures across all receiving servers.
Can SPF and DKIM prevent all email spoofing?
No. They significantly reduce spoofing risk, but they only protect your domain – attackers can still use lookalike domains (like y0urdomain.com) or display name spoofing. Combined with DMARC enforcement, SPF and DKIM stop direct domain forgery, which is the most common and damaging type.
Proper SPF and DKIM configuration isn’t a one-time checkbox – it’s an ongoing responsibility. Set them up correctly, monitor them regularly, and extend them to every subdomain that sends email. Your domain reputation and your recipients’ security depend on it.