SPF, DKIM, and DMARC Explained: How Email Authentication Works

Anyone could once fake the "From" address on an email -- here is how SPF, DKIM, and DMARC came together to make that much harder.

The email spoofing problem

SMTP, the basic protocol email runs on, was never designed to verify the sender address it carries. That meant anyone could put a bank's or company's address in the "From" field, which became the long-standing foundation of phishing emails.

SPF: a whitelist of sending servers

SPF (Sender Policy Framework) lets a domain owner publish, in a DNS TXT record, a list of servers authorized to send mail on that domain's behalf. A receiving mail server checks whether the IP address that actually sent the message appears on that list to help judge whether it might be spoofed.

DKIM: a digital signature that detects tampering

DKIM (DomainKeys Identified Mail) signs an outgoing message's body and key headers with the sending domain's private key, attaching that signature to the message header. The receiving server verifies the signature using the public key published in DNS, confirming that the content has not been altered since it was sent.

DMARC: turning results into an enforceable policy

DMARC (Domain-based Message Authentication, Reporting & Conformance) builds on SPF and DKIM results by also checking whether the visible "From" address aligns with the domain actually used for authentication. A domain owner can specify a policy for messages that fail authentication -- deliver anyway (none), send to spam (quarantine), or reject outright (reject) -- and also receive aggregated reports summarizing authentication failures.

How the three technologies relate

SPF and DKIM are each independent authentication mechanisms that operate on their own, while DMARC sits above them as a policy layer that decides what to do when authentication fails, based on their combined results. All three need to be in place together for spoofing defenses to actually be effective.

How to check authentication on a received email

Opening an email's raw headers reveals a field called "Authentication-Results," showing each check's outcome, such as spf=pass, dkim=pass, and dmarc=pass. If any of these come back as fail or none, it is worth being more skeptical about whether the message actually came from who it claims to.

Why all three checks matter, not just one

SPF alone can be bypassed by an attacker sending from a server on the domain's approved list but with a spoofed display name, and DKIM alone does not verify that the visible "From" address matches the signing domain. DMARC closes that gap by requiring alignment between the visible sender and the domain that actually passed SPF or DKIM, which is why security-conscious organizations configure all three together rather than relying on just one.

What a strict DMARC policy costs you if it is misconfigured

Setting a DMARC policy to reject too aggressively, before every legitimate sending source (like a third-party marketing tool or CRM) is properly authorized, can cause your organization's own legitimate emails to be silently rejected by other mail servers. Most organizations start with a "none" policy to collect reports and confirm every legitimate sender is accounted for, before gradually moving to quarantine and then reject.

Frequently Asked Questions

If SPF passes, does that mean the email is definitely legitimate?

Not by itself. SPF only confirms the sending server is authorized for that domain; it does not verify the visible "From" address matches, or that the content was not altered in transit. DKIM and DMARC address those gaps, which is why all three are meant to work together.

Why would a legitimate email still fail DMARC?

This often happens when an email is sent through a third-party service, such as a marketing platform or ticketing system, that has not been properly added to the domain's SPF record or set up with its own DKIM signature. Anyone managing a domain's email needs to authorize every legitimate sending source, not just their own mail server.