SPF, DKIM & DMARC Explained: Stop Email Spoofing

The Problem: Email Has No Built-In Authentication

SMTP, the protocol that carries email, was designed in 1982. It has no built-in mechanism for verifying sender identity. The From: header in an email is just a string - any mail server can put any address there. This is why phishing and business email compromise (BEC) attacks are so effective: an attacker can send an email that appears to come from ceo@yourcompany.com with zero technical barriers.

The three technologies that close this gap - SPF, DKIM, and DMARC - are all implemented as DNS TXT records. They do not change the email protocol itself; instead, they give receiving mail servers a way to check the DNS records of the sending domain and make an informed decision about whether to accept, quarantine, or reject the message.

As of 2024, Google and Yahoo both require SPF or DKIM authentication and a DMARC record for senders sending more than 5,000 messages per day. Configuring all three is no longer optional for any organization that sends business email.

Layer 1: SPF (Sender Policy Framework)

SPF answers one question: is this IP address authorized to send email for this domain? You publish a list of authorized mail servers in a DNS TXT record at your domain root. When a receiving mail server gets a message from you, it checks whether the sending IP is on that list.

SPF Record Syntax

An SPF record is a TXT record at your domain apex (e.g., example.com). The value looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all

Breaking it down:

• v=spf1 - declares this is an SPF record (required)
• include:_spf.google.com - authorizes all Google Workspace mail servers
• include:sendgrid.net - authorizes SendGrid for transactional email
• ip4:203.0.113.10 - authorizes a specific IP (e.g., your on-premise mail server)
• -all - hard fail: reject everything not listed above

Understanding the All Qualifier

The all mechanism at the end of your SPF record is critical and determines how strict your policy is:

• -all (hard fail) - reject mail not matching. Use this when you are confident your record is complete.
• ~all (soft fail) - accept but mark as potentially suspicious. Use this while auditing your senders.
• ?all (neutral) - no policy. Essentially useless from a security perspective.
• +all (pass all) - never use this. It defeats the entire purpose of SPF.

SPF has a critical limitation: it validates the envelope sender (the SMTP MAIL FROM address), not the From: header visible to users. An attacker can pass SPF while still showing a different display address. This is why DMARC is required.

The 10 DNS Lookup Limit

SPF allows a maximum of 10 DNS lookups when resolving your record. Each include:, a:, mx:, and redirect= counts as a lookup, and so do the lookups triggered recursively by include: records. Exceeding 10 lookups causes a permanent error (permerror) and SPF fails. Organizations using many third-party email services (Google, Salesforce, HubSpot, Mailchimp, SendGrid) frequently hit this limit. Solutions include SPF flattening tools or consolidating outbound email to fewer services.

Layer 2: DKIM (DomainKeys Identified Mail)

DKIM answers a different question: was this email cryptographically signed by the domain it claims to be from, and has it been modified in transit? It uses asymmetric cryptography: your mail server signs outgoing messages with a private key, and you publish the corresponding public key in DNS. Receiving servers use the public key to verify the signature.

How DKIM Signing Works

1. Your mail server generates a hash of selected email headers and the message body
2. It encrypts that hash with your DKIM private key and attaches the result as a DKIM-Signature header
3. The receiving server looks up your DKIM public key from DNS (at selector._domainkey.yourdomain.com)
4. It decrypts the signature and compares it to its own hash of the received headers/body
5. If they match, the email was not tampered with in transit and was signed by a key associated with your domain

Publishing Your DKIM Public Key

Your email provider generates the key pair. You publish the public key as a DNS TXT record at the selector subdomain. For example, if your selector is google:

Name:  google._domainkey.example.com
Type:  TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

The p= field contains the Base64-encoded public key. Your email provider (Google Workspace, Microsoft 365, SendGrid, etc.) will give you the exact TXT record value to publish. You never need to generate keys manually.

DKIM Selectors

A domain can have multiple DKIM keys simultaneously, differentiated by selectors. This allows key rotation (publish a new key before revoking the old one) and separate keys for different email streams. If you use both Google Workspace and Mailchimp, each uses a different selector. Check the DKIM-Signature header in any sent email to see which selector was used: s=google or s=k1, etc.

Layer 3: DMARC

(Domain-based Message Authentication, Reporting & Conformance)

DMARC ties SPF and DKIM together and answers: what should the receiving server do if SPF or DKIM checks fail? It also adds a critical alignment check and provides reporting.

DMARC Alignment

This is the concept that SPF alone cannot provide. DMARC requires that the domain in the visible From: header aligns with (matches) either the SPF-authenticated domain or the DKIM-signed domain. Without this alignment requirement, an attacker could send from their own SPF-passing domain while spoofing your address in the From: header.

DMARC Record Syntax

DMARC is published as a TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; pct=100; adkim=s; aspf=s

Key tags explained:

• p=none|quarantine|reject - the policy to apply to failing messages
• rua= - address to send aggregate reports (daily XML summaries)
• ruf= - address to send forensic reports (individual failure samples)
• pct=100 - apply policy to 100% of failing messages (default; start with lower during rollout)
• adkim=s - strict DKIM alignment (domain must exactly match)
• aspf=s - strict SPF alignment
• sp= - policy for subdomains (if omitted, parent policy applies)

Recommended Rollout Sequence

1. Start with p=none and a rua address. This is monitor-only mode - no mail is rejected, but you receive daily reports showing who is sending mail using your domain.
2. Analyze reports for 2–4 weeks. You will likely discover legitimate services sending on your behalf that you had forgotten about (old marketing platforms, partner systems, automated notifications).
3. Ensure all legitimate senders pass SPF or DKIM. Add missing include: entries to your SPF record or configure DKIM signing for services that were missing it.
4. Move to p=quarantine with pct=10. Start applying the policy to 10% of failing messages (they go to spam instead of inbox).
5. Gradually increase pct to 25, 50, 75, 100 while monitoring reports.
6. Move to p=reject once you are confident all legitimate mail is passing. Failing messages are now rejected outright.

How SPF, DKIM, and DMARC Work Together

Here is what happens when a receiving server gets an email claiming to be from alice@example.com:

1. The server checks SPF: is the sending IP authorized by example.com's SPF record?
2. The server checks DKIM: is the DKIM-Signature header valid and does it cover a domain aligning with example.com?
3. The server checks DMARC: does _dmarc.example.com exist? If either SPF or DKIM passes with alignment, DMARC passes. If both fail, DMARC fails and the policy (none/quarantine/reject) is applied.

DMARC passes if at least one of SPF or DKIM passes with alignment. This means if DKIM signing is properly configured, SPF failures (common with forwarded email) will not cause DMARC failures.

Common Configuration Mistakes

• Publishing p=reject before auditing senders: Legitimate mail from forgotten services will be rejected. Always start with p=none.
• No rua address: Without aggregate reports, you cannot see who is sending on your behalf or diagnose failures.
• Multiple SPF records: A domain can have only one SPF TXT record. Multiple SPF records cause a permanent error. Combine all mechanisms into a single record.
• SPF record exceeding 10 DNS lookups: Results in permerror which counts as SPF failure.
• DKIM key not rotated: DKIM private keys should be rotated periodically (annually at minimum). Rotate by publishing a new key with a new selector, updating your mail server to use it, waiting for TTL to expire, then revoking the old key.
• Forgetting subdomains: DMARC applies to your root domain. Subdomains that send email (e.g., notifications.example.com) need their own SPF/DKIM or they inherit the parent DMARC policy. Use the sp= tag to set a separate policy for subdomains.

Frequently Asked Questions

Does SPF alone protect against email spoofing?

No. SPF validates the envelope sender (the address used in the SMTP handshake) not the From: header visible to recipients. An attacker can use a different domain for the SMTP envelope (which passes SPF) while displaying your domain in the From: header. DMARC's alignment requirement closes this gap by requiring the visible From: domain to match the SPF- or DKIM-authenticated domain.

What is the difference between DKIM alignment strict and relaxed?

With adkim=s (strict), the DKIM d= tag must exactly match the From: domain. With adkim=r (relaxed, the default), a subdomain match is allowed - a message from mail.example.com can pass DKIM alignment for example.com. Relaxed is appropriate for most organizations. Use strict only if you specifically need to prevent subdomain spoofing.

Will DMARC break email forwarding?

Forwarding is a known compatibility issue. When email is forwarded, the forwarding server re-sends the message from its own IP, breaking SPF alignment. If the original DKIM signature is preserved (most modern forwarders do this), DMARC will still pass via DKIM. Problems occur when forwarders modify the message body (breaking DKIM). This is an inherent limitation of DMARC with forwarding, and is typically acceptable at p=reject for business domains.

How do I read DMARC aggregate reports?

Reports arrive as XML attachments in gzip format. The raw XML is hard to read. Use a dedicated DMARC reporting service (Postmark's free DMARC analyzer, MXToolbox, DMARC Analyzer) that parses and visualizes reports. These services show you pass/fail rates, unauthorized senders, and IP geolocations of failing sources.

What is BIMI and how does it relate to DMARC?

BIMI (Brand Indicators for Message Identification) is a standard that lets organizations display their logo in supporting email clients (Gmail, Apple Mail, Yahoo) next to authenticated emails. BIMI requires p=quarantine or p=reject DMARC policy as a prerequisite, plus a Verified Mark Certificate (VMC) from an approved CA. It is the reward for getting your email authentication fully configured.

The Bottom Line

SPF, DKIM, and DMARC are complementary layers. SPF defines who can send, DKIM proves the message was signed and unmodified, and DMARC enforces alignment and provides reporting. None of them is optional. The rollout sequence is critical: start with p=none, audit your legitimate senders via DMARC reports, fix any gaps, then progressively enforce quarantine and finally reject.

The entire configuration is DNS records - no application code changes, no infrastructure changes. It is one of the highest-return security improvements available for the time invested.