SPF, DKIM, and DMARC Explained

Introduction: Why Email Authentication Matters

Email was designed in an era when trust was implicit. The original SMTP protocol includes no built-in mechanism to verify that a sender is who they claim to be. This fundamental design gap means that anyone with access to a mail server can send messages that appear to come from any domain -- a practice known as email spoofing.

For decades, this weakness has been exploited by spammers, phishers, and attackers. Business Email Compromise (BEC) attacks alone accounted for over $2.9 billion in losses reported to the FBI in 2023. Spoofed emails erode trust, damage brand reputation, and expose recipients to fraud.

Three authentication protocols were developed to address this: SPF, DKIM, and DMARC. Together, they form a verification chain that allows receiving mail servers to confirm that a message genuinely originated from an authorized sender for the claimed domain.

In February 2024, Google and Yahoo jointly enforced new requirements for bulk senders (those sending more than 5,000 messages per day to their users). The requirements mandate that all bulk senders must:

• Authenticate email using SPF and DKIM
• Publish a DMARC policy for the sending domain
• Align the From: header domain with the SPF or DKIM domain
• Support one-click unsubscribe for marketing messages
• Maintain a spam complaint rate below 0.3%

Messages that fail to meet these standards are increasingly rejected or routed to spam. This is not optional guidance -- it is enforced at the infrastructure level. If you send email from your own domain, properly configuring SPF, DKIM, and DMARC is now a baseline requirement for reaching the inbox.

SPF: Sender Policy Framework

What SPF Does

SPF allows a domain owner to publish a list of mail servers that are authorized to send email on behalf of that domain. When a receiving server gets an email claiming to be from example.com, it looks up the SPF record for example.com to check whether the sending server's IP address is on the authorized list. If it is not, the message fails the SPF check.

SPF works at the envelope sender level (the MAIL FROM address used in the SMTP transaction), not the From: header that recipients see. This distinction is important and becomes relevant when we discuss DMARC alignment later.

How SPF Works

SPF is implemented as a DNS TXT record on your domain. When an email arrives, the receiving server:

1. Extracts the domain from the MAIL FROM (envelope sender) address
2. Queries DNS for a TXT record starting with v=spf1 on that domain
3. Evaluates the sending server's IP against the mechanisms listed in the record
4. Returns a result: pass, fail, softfail, neutral, or permerror

Setting Up SPF

To create an SPF record, you add a TXT record to your domain's DNS zone. The record specifies which IP addresses and servers are allowed to send mail for your domain. Here is an example for a domain that sends email through its own servers, Google Workspace, and a transactional email service:

Breaking this down:

• v=spf1 -- identifies this as an SPF record (required prefix)
• ip4:198.51.100.0/24 -- authorizes all IPs in the 198.51.100.x range
• include:_spf.google.com -- authorizes Google Workspace mail servers
• include:sendgrid.net -- authorizes SendGrid's mail servers
• -all -- fail any server not listed above (hard fail)

Common SPF Mistakes

Too many DNS lookups. SPF has a hard limit of 10 DNS lookups per evaluation. Each include:, a:, mx:, and redirect= mechanism counts as one lookup. Nested includes count toward this limit as well. Exceeding 10 lookups causes a permanent error (permerror), and most receivers treat this as a failure. If you use multiple third-party senders, you can hit this limit quickly. Consider using ip4: and ip6: directives (which do not count as lookups) or flattening your record.

Forgetting third-party senders. Every service that sends email on your behalf needs to be included in your SPF record: your marketing platform, your transactional email provider, your CRM, your helpdesk system, and any other tool that sends from your domain. A common oversight is setting up SPF for your primary mail server and forgetting that your invoicing software also sends from the same domain.

Using +all or ?all. Using +all authorizes every server in the world to send as your domain, defeating the entire purpose of SPF. The ?all (neutral) result provides no meaningful protection either. Always use ~all (soft fail) at minimum, and -all (hard fail) once you are confident your record is complete.

Publishing multiple SPF records. A domain must have exactly one SPF TXT record. If you have two records starting with v=spf1, the result is a permerror. Merge all your authorized sources into a single record.

DKIM: DomainKeys Identified Mail

What DKIM Does

DKIM adds a cryptographic signature to every outgoing email, allowing the receiving server to verify that the message was not altered in transit and that it was authorized by the domain owner. Unlike SPF, which checks the sending server's IP, DKIM validates the message content itself.

How Cryptographic Signing Works

DKIM uses public-key cryptography. The process works as follows:

1. The domain owner generates a public/private key pair
2. The private key is stored securely on the sending mail server
3. The public key is published in a DNS TXT record
4. When an email is sent, the mail server computes a hash of selected message headers and the body, then signs that hash with the private key
5. The signature is added to the email as a DKIM-Signature header
6. The receiving server retrieves the public key from DNS and uses it to verify the signature
7. If the signature is valid, the message passes DKIM; if the content was tampered with, verification fails

The DKIM-Signature header includes several important fields: d= (the signing domain), s= (the selector, used to look up the public key), h= (the list of headers that were signed), and b= (the actual signature).

Setting Up DKIM

DKIM setup involves two steps: generating the key pair on your mail server (or through your email provider), and publishing the public key as a DNS TXT record. The record is published at a specific subdomain using the format selector._domainkey.example.com.

The s1 in this example is the selector. You can have multiple selectors (e.g., s1, s2, google, sendgrid) to use different keys for different sending services. Each service provides its own public key, and you publish each one under a unique selector.

If you use a hosted email service like Google Workspace, Microsoft 365, or a transactional email provider, they will generate the DKIM keys for you and provide the DNS records to publish. You typically just need to add the TXT records to your domain's DNS and then enable DKIM signing in the provider's admin console.

Key Rotation Best Practices

DKIM keys should be rotated periodically to limit the exposure window if a private key is compromised. Recommended practices include:

• Rotate keys every 6 to 12 months. This is generally considered sufficient for most organizations. High-security environments may rotate more frequently.
• Use 2048-bit RSA keys. The older 1024-bit keys are still common but increasingly considered weak. Most modern DNS providers support the longer TXT records required for 2048-bit keys.
• Implement a two-phase rotation. First, publish the new public key under a new selector while continuing to sign with the old key. Then switch signing to the new key. Finally, remove the old public key record after allowing time for DNS caches to clear (24-48 hours minimum).
• Never delete the old public key immediately. Emails signed with the old key may still be in transit or queued for retry. Removing the public key too early causes those messages to fail DKIM verification.

DMARC: Domain-based Message Authentication, Reporting & Conformance

What DMARC Does

DMARC builds on top of SPF and DKIM. It solves a critical gap: without DMARC, even if an email fails SPF and DKIM checks, the receiving server has no instructions from the domain owner about what to do with it. DMARC provides that policy. It also introduces the concept of alignment, ensuring that the domain in the visible From: header matches the domains verified by SPF and DKIM.

How DMARC Ties SPF and DKIM Together

A message passes DMARC if it passes either SPF or DKIM (not necessarily both), and the passing protocol is aligned with the From: header domain. This is a crucial point: an email could pass SPF but still fail DMARC if the SPF-authenticated domain does not align with the From: header domain.

For example, if a message has From: sales@example.com but was sent by a server authorized under emailservice.com (the envelope sender domain), the SPF check might pass for emailservice.com, but DMARC alignment fails because emailservice.com does not match example.com.

Alignment Modes

DMARC supports two alignment modes, configured separately for SPF (aspf) and DKIM (adkim):

Most organizations start with relaxed alignment, which accommodates subdomains and third-party senders more easily. Strict alignment is more secure but requires that every sending source signs messages with the exact domain used in the From: header.

Policy Levels

The DMARC p= tag tells receiving servers what to do with messages that fail DMARC evaluation:

Reporting: rua and ruf

DMARC includes two reporting mechanisms that give domain owners visibility into how their domain is being used (and abused) across the email ecosystem:

• Aggregate reports (rua) -- XML reports sent daily by receiving servers. They contain statistics about messages claiming to be from your domain: how many passed/failed SPF, DKIM, and DMARC, which IPs sent them, and what disposition was applied. These are essential for understanding your email flows and identifying unauthorized senders.
• Forensic reports (ruf) -- Detailed reports about individual messages that failed DMARC. These can include message headers and sometimes body content. Due to privacy concerns, many large receivers (including Google and Yahoo) do not send forensic reports. They are less commonly available but can be useful for investigating specific spoofing incidents.

Recommended Rollout Strategy

Deploying DMARC should be a gradual process. Jumping directly to a reject policy without thorough monitoring will almost certainly cause legitimate email to be lost. Follow this phased approach:

1. Phase 1: Monitor (2-4 weeks minimum). Publish a p=none DMARC record with a rua address. Collect and analyze aggregate reports to identify all legitimate sending sources for your domain. Make sure every authorized sender is covered by your SPF and DKIM configurations.
2. Phase 2: Quarantine with percentage (2-4 weeks). Move to p=quarantine; pct=10, applying the quarantine policy to only 10% of failing messages. Gradually increase the percentage (25%, 50%, 100%) while monitoring reports for false positives.
3. Phase 3: Reject with percentage (2-4 weeks). Switch to p=reject; pct=10 and incrementally increase to 100%. Continue monitoring reports throughout.
4. Phase 4: Full enforcement. Once you are confident that all legitimate sources pass DMARC, set p=reject without a pct tag (100% is the default).

This entire process typically takes 6 to 12 weeks. Rushing it is one of the most common mistakes organizations make.

Example DMARC Record

How They Work Together

SPF, DKIM, and DMARC form a layered authentication system. Here is the sequence that occurs when a receiving server processes an incoming message:

When Checks Fail

Understanding the failure scenarios helps with troubleshooting:

• SPF fails, DKIM passes, DKIM aligns: DMARC passes. The message is delivered normally. This is common when email is forwarded, since forwarding changes the sending IP but preserves DKIM signatures.
• SPF passes, DKIM fails, SPF aligns: DMARC passes. The message is delivered normally. This can happen when mailing lists modify message content (breaking DKIM) but preserve the envelope sender.
• Both SPF and DKIM fail: DMARC fails. The receiving server applies the DMARC policy (none, quarantine, or reject).
• SPF passes but does not align, DKIM passes but does not align: DMARC fails despite both individual checks passing. This is a common misconfiguration with third-party senders that use their own domain in the envelope sender and sign with their own DKIM domain rather than yours.

Common Mistakes

Even experienced email administrators make configuration errors that undermine authentication. Here are the most frequent problems and how to avoid them:

1. Incomplete SPF Records

The most common SPF mistake is failing to include all authorized sending sources. Organizations often configure SPF for their primary mail server and then add a marketing platform months later without updating the SPF record. Every service that sends email using your domain -- CRM, helpdesk, billing system, HR platform, monitoring alerts -- must be accounted for. Audit your sending sources at least quarterly.

2. Not Rotating DKIM Keys

Many organizations set up DKIM once and never touch it again. If a private key is compromised (through a server breach, employee departure, or vendor incident), an attacker can sign spoofed emails that pass DKIM verification indefinitely. Establish a key rotation schedule and treat it like any other credential rotation.

3. Jumping to p=reject Too Quickly

Moving to a reject policy without sufficient monitoring is the single most damaging DMARC mistake. Legitimate email from forgotten or undocumented sending sources will be silently rejected, and you may not discover the problem until business-critical messages are reported as missing. Always start with p=none, collect at least four weeks of aggregate reports, and escalate gradually.

4. Ignoring DMARC Reports

Publishing a rua address but never reviewing the reports defeats the purpose of the monitoring phase. DMARC aggregate reports are XML files that can be difficult to read raw, but numerous free and paid tools can parse and visualize them. Set up automated processing or use a DMARC reporting service to review your reports weekly.

5. Misunderstanding Subdomain Policies

DMARC applies to the exact domain and, by default, to its subdomains. However, you can set a separate subdomain policy using the sp= tag. If your organization uses subdomains for different services (e.g., marketing.example.com, support.example.com), make sure your DMARC policy accounts for all of them. A common gap is enforcing p=reject on the organizational domain while leaving subdomains unprotected.

6. SPF Record Exceeding the DNS Lookup Limit

As mentioned earlier, SPF allows a maximum of 10 DNS-based mechanisms per evaluation. This limit exists to prevent denial-of-service attacks through recursive DNS queries. Monitor your lookup count whenever you add a new sending service. If you are near the limit, consider replacing include: mechanisms with direct ip4: or ip6: entries where possible.

Testing Your Setup

After configuring SPF, DKIM, and DMARC, you need to verify that everything works correctly before relying on it for production email. Here are the most effective methods:

Check DNS Records Directly

Use dig or nslookup to verify that your records are published and syntactically correct:

Send Test Emails

Send a test email to a Gmail address and inspect the original message headers (in Gmail: click the three dots menu, then "Show original"). Look for the Authentication-Results header, which shows the SPF, DKIM, and DMARC verdicts:

Use Online Validation Tools

Several free tools can validate your configuration without requiring you to send test emails:

• MXToolbox -- Checks SPF, DKIM, and DMARC records for syntax errors, lookup limits, and common misconfigurations
• Google Admin Toolbox Check MX -- Validates MX records and email authentication settings for domains sending to Gmail
• Mail-Tester -- Send a test email to a generated address and receive a detailed deliverability score including authentication results
• dmarcian -- Offers a free DMARC record checker and can parse DMARC aggregate reports

Monitor Aggregate Reports

Once your p=none DMARC record is live, aggregate reports will start arriving within 24-48 hours. Review them carefully for:

• Legitimate sending sources that are failing SPF or DKIM
• Unexpected IP addresses sending as your domain (potential spoofing)
• Alignment failures where SPF or DKIM passes but the domain does not match
• High volumes of unauthenticated messages from specific regions or networks

How SpamAnalyzer Helps

SpamAnalyzer uses AI to analyze your email content for spam triggers, deliverability issues, and compliance gaps. While SPF, DKIM, and DMARC handle the authentication layer, SpamAnalyzer focuses on the content layer -- the words, formatting, and structure that spam filters evaluate after authentication passes.

Even with perfect authentication, emails with spammy subject lines, excessive links, misleading content, or missing compliance elements (like unsubscribe links or physical addresses) can still land in the spam folder. SpamAnalyzer catches these issues before you send, giving you a spam score, specific suggestions for improvement, and an AI-revised version of your email optimized for deliverability.