SPF, DKIM, and DMARC: How DNS Protects Your Email From Spoofing

Every day, billions of emails cross the internet, and a staggering number of them are fraudulent. Phishing attacks, business email compromise, and domain spoofing cost organizations billions of dollars annually. The first line of defense against these threats does not live in your inbox or spam filter. It lives in your DNS records.

Three DNS-based protocols form the backbone of modern email authentication: SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting, and Conformance). Together, they create a layered verification system that tells receiving mail servers whether an email genuinely originated from your domain or whether someone is impersonating you.

In this guide, I will break down how each protocol works, show you real example records, walk through common configuration mistakes, and explain how to verify your setup using DNS lookup tools.

How Email Spoofing Works and Why Authentication Matters

To understand why SPF, DKIM, and DMARC exist, you need to understand a fundamental weakness of email. The Simple Mail Transfer Protocol (SMTP), which powers email delivery, was designed in the early 1980s with no built-in mechanism for verifying sender identity. Anyone with access to an SMTP server can set the "From" address to any value they choose.

This means an attacker can send an email that appears to come from [email protected] without ever having access to your email systems. The recipient's mail client will display your domain in the "From" field, making the message look legitimate.

Email spoofing enables several attack vectors:

• Phishing campaigns that trick employees into revealing credentials
• Business email compromise (BEC) where attackers impersonate executives to authorize wire transfers
• Brand abuse where scammers use your domain to send spam, damaging your sender reputation
• Credential harvesting via fake password reset emails that appear to come from trusted services

SPF, DKIM, and DMARC were developed to close this gap. They use DNS TXT records to publish authentication policies that receiving servers can check before delivering a message to the inbox.

SPF: Defining Who Can Send Email for Your Domain

SPF allows domain owners to publish a list of IP addresses and mail servers that are authorized to send email on behalf of their domain. When a receiving server gets an email claiming to be from your domain, it checks your SPF record to see if the sending server's IP address is on the approved list.

How SPF Works

1. You publish a TXT record in your domain's DNS that lists your authorized senders.
2. A receiving mail server extracts the domain from the envelope "MAIL FROM" address.
3. The server performs a DNS lookup on that domain to retrieve the SPF record.
4. It compares the sending server's IP address against the SPF record.
5. The result is either pass, fail, softfail, or neutral.

Example SPF Record

v=spf1 ip4:192.0.2.0/24 include:_spf.google.com include:sendgrid.net -all

Let's break down this record:

• v=spf1 -- Identifies this as an SPF record (version 1).
• ip4:192.0.2.0/24 -- Authorizes all IP addresses in the 192.0.2.0/24 range.
• include:_spf.google.com -- Authorizes Google Workspace's mail servers.
• include:sendgrid.net -- Authorizes SendGrid's mail servers (for transactional email).
• -all -- Instructs receivers to reject (hard fail) email from any server not listed above.

Common SPF Mistakes

Too many DNS lookups. SPF has a 10 DNS lookup limit. Each include, a, mx, and redirect mechanism counts as a lookup. Exceeding this limit causes the entire SPF check to return a permanent error, effectively breaking your authentication.

Using ~all instead of -all. The tilde (~) creates a softfail, which means unauthenticated email is accepted but marked suspicious. For stronger protection, use -all (hard fail) once you are confident your SPF record includes all legitimate senders.

Forgetting third-party services. If you use a CRM, marketing platform, or transactional email provider, their sending IPs must be included in your SPF record. Otherwise, their emails will fail SPF checks.

DKIM: Cryptographic Signatures for Email Integrity

While SPF verifies the sending server, DKIM goes further by attaching a cryptographic signature to each outgoing email. This signature proves two things: the email was authorized by the domain owner, and the message content has not been tampered with in transit.

How DKIM Works

1. Your mail server generates a public/private key pair. The private key stays on the server; the public key is published as a DNS TXT record.
2. When sending an email, the server creates a hash of specific message headers and the body, then encrypts that hash with the private key. This encrypted hash is the DKIM signature, added as a header to the message.
3. The receiving server extracts the DKIM signature header, retrieves the public key from DNS, and decrypts the hash.
4. It independently hashes the same headers and body, then compares the two values.
5. If they match, the signature is valid, confirming authenticity and integrity.

Example DKIM DNS Record

DKIM records are published as TXT records under a specific selector subdomain:

selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3QEKyU1fSo6...truncated..."

The key components:

• selector1 -- The selector, which allows you to have multiple DKIM keys (useful for key rotation).
• _domainkey -- A fixed subdomain indicating this is a DKIM record.
• v=DKIM1 -- Version identifier.
• k=rsa -- The key type (RSA is standard; Ed25519 is emerging).
• p= -- The public key data encoded in Base64.

Common DKIM Mistakes

Not rotating keys. DKIM keys should be rotated periodically (every 6-12 months). Selectors make this possible because you can publish a new key under a new selector before deactivating the old one.

Using 1024-bit keys. While still technically valid, 1024-bit RSA keys are considered weak. Use 2048-bit keys for stronger security.

Broken signatures from email forwarding. When intermediary servers modify the message (e.g., mailing lists that add footers), the DKIM body hash may no longer match. This is expected behavior, and DMARC alignment helps handle these cases.

DMARC: Tying SPF and DKIM Together With Policy Enforcement

DMARC builds on top of SPF and DKIM by adding two critical features: alignment checking and policy enforcement with reporting. It tells receiving servers what to do when an email fails authentication and provides a mechanism for domain owners to receive reports about authentication results.

How DMARC Works

1. You publish a DMARC TXT record at _dmarc.yourdomain.com.
2. When a receiving server gets an email, it checks both SPF and DKIM results.
3. DMARC requires alignment: the domain in the "From" header must match the domain used in SPF (envelope sender) or DKIM (signing domain).
4. If neither SPF nor DKIM passes with alignment, the receiving server applies your DMARC policy: none (monitor only), quarantine (send to spam), or reject (block entirely).
5. The receiving server sends aggregate and/or forensic reports back to the addresses you specified.

Example DMARC Record

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=s; aspf=s; pct=100"

Breaking this down:

• v=DMARC1 -- Version identifier.
• p=reject -- Policy: reject emails that fail authentication.
• rua=mailto:... -- Aggregate report delivery address (daily XML summaries).
• ruf=mailto:... -- Forensic report delivery address (individual failure details).
• adkim=s -- Strict DKIM alignment (the "From" domain must exactly match the DKIM signing domain).
• aspf=s -- Strict SPF alignment.
• pct=100 -- Apply the policy to 100% of failing messages.

The DMARC Rollout Strategy

Do not jump straight to p=reject. Follow this gradual approach:

1. Start with p=none to collect reports without affecting email delivery. Monitor reports for 2-4 weeks.
2. Move to p=quarantine; pct=10 to quarantine 10% of failing emails. Gradually increase the percentage.
3. Advance to p=quarantine; pct=100 once you are confident all legitimate senders are authenticated.
4. Finally, set p=reject to instruct receivers to block unauthenticated email entirely.

This phased approach prevents legitimate email from being blocked while you identify and fix authentication gaps.

How SPF, DKIM, and DMARC Work Together

These three protocols are designed to complement each other, not replace one another:

A robust email authentication setup requires all three working in concert:

• SPF establishes which servers may send email for your domain.
• DKIM proves the email was genuinely sent by an authorized party and has not been altered.
• DMARC ensures the visible "From" address aligns with the authenticated domain and tells receivers how to handle failures.

Without DMARC, a spoofed email could fail SPF but still reach the inbox because there is no policy telling the receiver to reject it. Without DKIM, forwarded emails that break SPF have no fallback authentication method. All three together create a resilient system.

Checking Your Email Authentication Records With DNSChkr

Setting up these records correctly is only half the battle. You need to verify that they are published properly and propagating across DNS servers worldwide.

Use the DNSChkr DNS Inspector to look up your domain's TXT records. The tool will display all TXT records for your domain, including SPF, DKIM, and DMARC entries. You can verify the syntax, check for errors, and confirm that your records contain the expected values.

To check SPF, query your domain's TXT records and look for the entry starting with v=spf1. For DKIM, query the TXT record at selector._domainkey.yourdomain.com (replacing selector with your actual DKIM selector). For DMARC, query the TXT record at _dmarc.yourdomain.com.

After making changes to any of these records, use the DNSChkr Propagation Checker to monitor how the updates spread across global DNS servers. This is especially important when transitioning DMARC policies, as you want to confirm the new policy is visible worldwide before assuming it is active.

You can also use command-line tools to perform quick checks:

# Check SPF record
dig +short TXT example.com | grep "v=spf1"

# Check DKIM record (replace 'selector1' with your selector)
dig +short TXT selector1._domainkey.example.com

# Check DMARC record
dig +short TXT _dmarc.example.com

Key Takeaways

• SPF defines which IP addresses and servers are authorized to send email for your domain by publishing a TXT record with v=spf1.
• DKIM attaches a cryptographic signature to each email, allowing receivers to verify the message was genuinely sent by your domain and was not altered in transit.
• DMARC ties SPF and DKIM together with alignment checks and a policy that tells receiving servers whether to accept, quarantine, or reject unauthenticated email.
• All three protocols are implemented through DNS TXT records, making DNS the foundation of email security.
• SPF has a 10 DNS lookup limit that can silently break your authentication if exceeded.
• Always roll out DMARC in phases: start with p=none, progress to p=quarantine, and only move to p=reject after confirming all legitimate senders pass authentication.
• Major email providers including Google and Yahoo now require SPF and DKIM for bulk senders, making these records essential for email deliverability.
• Use tools like the DNSChkr DNS Inspector to verify your records are published correctly and the Propagation Checker to confirm changes have spread globally.

Email authentication through DNS is not optional in today's threat landscape. Whether you are managing a personal domain or an enterprise mail infrastructure, properly configured SPF, DKIM, and DMARC records are fundamental to protecting your brand, your users, and your email deliverability.

Ready to check your domain's email authentication setup? Head to the DNSChkr DNS Inspector and look up your domain's TXT records to see exactly what is published today.