SPF vs DKIM vs DMARC: What the Difference Actually Means for Your Email

If you have ever dug into your domain's DNS records trying to stop spoofed emails or fix a deliverability problem, you have almost certainly encountered three acronyms thrown together as if they are interchangeable: SPF, DKIM, and DMARC. They are not the same thing. Each one solves a different part of the email authentication puzzle, and deploying all three correctly is the only way to properly protect your domain from spoofing, phishing, and spam filtering failures. This guide breaks down what each standard actually does, why the distinctions matter, and exactly how to implement and verify each one.

Why Email Authentication Exists at All

SMTP, the protocol that has carried email since 1982, was designed with zero authentication. Any server on the internet can claim to be sending mail from any address. That design flaw is the root cause of phishing, business email compromise, and a huge chunk of the world's spam. SPF, DKIM, and DMARC are DNS-based mechanisms layered on top of SMTP to fill that gap. They work by publishing verifiable information in your domain's DNS records so that receiving mail servers can check whether an incoming message is legitimate before delivering it to the inbox.

SPF: Authorizing Which Servers Can Send Your Mail

Sender Policy Framework (SPF) is the oldest and simplest of the three. You publish a DNS TXT record on your domain that lists every IP address or mail server hostname that is allowed to send email on your behalf. When a receiving server gets a message claiming to be from your domain, it checks the SPF record to see if the sending server's IP is on the list. If it is not, the message fails SPF.

What an SPF Record Looks Like

An SPF record is a single TXT record on the bare domain (e.g., example.com). A typical record for a domain that sends through Google Workspace and a third-party CRM looks like this:

The mechanisms from left to right tell receiving servers: trust Google's sending infrastructure, trust SendGrid's infrastructure, trust the single IP 203.0.113.42, and treat everything else as a soft fail (~all). Using -all instead of ~all is a hard fail and is slightly more aggressive but better for domains that never send from unexpected sources.

SPF's Critical Limitation

SPF only checks the envelope sender, also called the Return-Path or MAIL FROM address, not the From header that your recipients actually see. An attacker can keep your domain in the visible From header, use a throwaway domain in the envelope, and pass SPF while still appearing to come from you. This is why SPF alone is not enough.

Common SPF Mistakes

• Too many lookups: SPF allows a maximum of 10 DNS lookups during evaluation. Stacking too many include mechanisms breaks SPF silently. Use a tool like our DNS Lookup tool to inspect your current SPF record and count your includes.
• Multiple SPF records: You must have exactly one TXT record with v=spf1 on a given name. Two records cause a permanent error (PermError) and SPF fails for everyone.
• Forgetting subdomains: SPF on example.com does not cover mail.example.com or newsletters.example.com. Each sending subdomain needs its own record.

DKIM: Cryptographic Proof That the Message Was Not Tampered With

DomainKeys Identified Mail (DKIM) takes a completely different approach. Instead of listing authorized servers, it uses public-key cryptography. Your mail server signs outgoing messages with a private key. The corresponding public key is published in a DNS TXT record. Receiving servers retrieve the public key and use it to verify the signature embedded in the email headers. If the signature checks out, the message content has not been altered in transit and it genuinely originated from a server that holds your private key.

What a DKIM DNS Record Looks Like

DKIM records are published at a specific subdomain format: selector._domainkey.yourdomain.com. The selector is a label chosen by you or your mail provider. Google Workspace uses google as its selector by default. A typical record looks like this:

The p= value is the base64-encoded public key. You never touch this value manually; your mail provider generates the key pair and gives you the DNS record to publish.

What DKIM Actually Validates

DKIM signs specific headers (typically From, Subject, Date, To) and the body. If any of those change in transit, the signature breaks. Importantly, DKIM validates the d= domain in the signature, which should match your sending domain. This is the domain that appears in the From header, making DKIM more relevant to what users see than SPF is.

DKIM Does Not Prevent Replay Attacks

A signed message can be re-sent by anyone who intercepts it. DKIM signatures do not expire by default (though you can add a timestamp). This is a known limitation that DMARC partially addresses through policy enforcement.

DMARC: The Policy Layer That Ties SPF and DKIM Together

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is the mechanism that actually tells receiving servers what to do when SPF or DKIM checks fail. Without DMARC, a receiving server that sees an SPF failure might still deliver the message to the inbox. DMARC changes that by publishing an explicit policy.

The Alignment Concept

DMARC introduces a concept called alignment. For a message to pass DMARC, at least one of the following must be true:

• SPF passes and the domain in the Return-Path aligns with the From domain (SPF alignment).
• DKIM passes and the d= domain in the DKIM signature aligns with the From domain (DKIM alignment).

This alignment requirement is what closes the SPF loophole described earlier. An attacker using a throwaway envelope domain will not achieve alignment with your From domain, so DMARC fails even if SPF technically passes on the throwaway domain.

What a DMARC Record Looks Like

DMARC records are TXT records published at _dmarc.yourdomain.com:

Breaking down the key tags:

• p= sets the policy: none (monitor only), quarantine (send to spam), or reject (block outright).
• rua= is the email address for aggregate reports (XML summaries of pass/fail statistics).
• ruf= is the address for forensic reports (redacted copies of failing messages).
• pct= applies the policy to a percentage of failing messages (useful for gradual rollout).
• adkim= and aspf= set alignment strictness: s for strict (exact domain match) or r for relaxed (subdomain match counts).

The Recommended Rollout Path

1. Start with p=none and a rua address. Collect aggregate reports for two to four weeks to understand what is sending on your behalf.
2. Fix any legitimate mail streams that are failing SPF or DKIM (common culprits: CRMs, marketing platforms, helpdesk tools).
3. Move to p=quarantine; pct=10 and gradually increase the percentage.
4. Once you are confident, move to p=reject; pct=100. This is the target state that actually stops spoofing.

How SPF, DKIM, and DMARC Work Together in Practice

Here is what happens when a legitimate email from your domain arrives at Gmail's servers:

1. Gmail checks the sending IP against your SPF record. It passes because your ESP's IP is listed. The Return-Path domain matches your From domain, so SPF alignment passes.
2. Gmail retrieves your DKIM public key from DNS using the selector in the signature header. The signature verifies correctly. The d= domain matches your From domain, so DKIM alignment also passes.
3. Gmail checks your DMARC record. Since at least one aligned mechanism passed, DMARC passes. The message is delivered normally.

Now consider a phishing email spoofing your domain:

1. The attacker's server is not in your SPF record, so SPF fails. Even if they control a domain that passes SPF on its own, it does not align with your From header.
2. The attacker cannot sign with your DKIM private key, so DKIM either fails or is absent.
3. DMARC checks both mechanisms. Neither passes with alignment. With p=reject, Gmail refuses the message entirely.

Step-by-Step Implementation Guide

Step 1: Create Your SPF Record

Log into your DNS provider and add a TXT record at the root of your domain. If you use Google Workspace as your only mail sender:

Add additional include statements or ip4 entries for every service that sends mail on your behalf before publishing.

Step 2: Enable DKIM Signing

DKIM is configured in your mail platform, not just in DNS. In Google Workspace: Admin Console → Apps → Google Workspace → Gmail → Authenticate email. Generate a key (2048-bit recommended), then copy the DNS TXT record it gives you and publish it in your DNS. In Microsoft 365: go to the Defender portal → Email and Collaboration → Policies and Rules → Threat Policies → DKIM. Enable signing for your domain and publish the CNAME records Microsoft provides.

Step 3: Publish Your DMARC Record

Start here, monitor for a few weeks, then increase the policy as described above.

How to Verify Everything Is Working

Send a test email to a Gmail or Yahoo address you control. In Gmail, open the message and click the three-dot menu, then "Show original." Look for these lines in the headers:

All three should show pass. If any shows fail, the raw headers will give you the reason code to debug. You can also send a test message to check-auth@verifier.port25.com and it will auto-reply with a full authentication report.

Quick Reference: SPF vs DKIM vs DMARC

• SPF: Authorizes sending IPs. Checks the envelope sender. Does not protect the visible From header alone.
• DKIM: Cryptographic signature on message content and headers. Validates message integrity and the signing domain. Checks the From header domain.
• DMARC: Policy engine. Requires SPF or DKIM to align with the From domain. Tells receiving servers what to do on failure. Provides reporting visibility.

None of the three is optional if you want robust email security. SPF without DKIM means a forwarded message will often fail SPF (forwarding changes the envelope) but would still pass DKIM because the signature travels with the message. DKIM without SPF leaves a vector for spoofing. Both without DMARC means there is no enforcement policy and no reporting. Run all three, move DMARC to p=reject, and your domain becomes a dramatically harder target for impersonation.