SPF, DKIM, and DMARC: What They Are, How They Work Together, and Why All Three Matter

Why email authentication exists

When email was invented in the 1970s, the SMTP protocol included no mechanism to verify who was actually sending a message. For decades, this was not considered a serious problem. Today, with phishing attacks, business email compromise, and spam causing billions in annual losses, the lack of built-in verification is one of the most exploited gaps in internet infrastructure.

Three standards were developed — SPF, DKIM, and DMARC — to retrofit sender authentication onto the existing email ecosystem. Each one addresses a different piece of the problem, and they only provide full protection when all three are properly configured.

SPF — Sender Policy Framework

SPF answers the question: "Is this mail server authorized to send email from this domain?"

You publish an SPF record in DNS listing every IP address or mail server that is allowed to send email on behalf of your domain. When a receiving server gets an email claiming to be from you, it checks whether the sending server's IP address is in your SPF record.

The mechanisms in order: Google's mail servers are authorized (include:_spf.google.com), one specific IP is authorized (ip4:203.0.113.10), and all others are rejected (-all).

SPF's limitation: SPF checks the Envelope From (the technical return path), not the From header that users see. It also breaks when email is forwarded, because the forwarding server's IP is not in the original sender's SPF record.

DKIM — DomainKeys Identified Mail

DKIM answers the question: "Was this email really sent by someone who controls this domain, and has it been modified in transit?"

Your mail server generates a cryptographic signature for each outgoing email using a private key. The corresponding public key is published in DNS. Receiving servers fetch this public key and use it to verify the signature.

If the signature validates, the email demonstrably came from a server that holds the private key, and the signed content has not been altered since signing.

DKIM's limitation: DKIM proves integrity and origin but does not tell the receiving server what to do if the check fails or is missing. That policy is DMARC's job. Also, DKIM survives forwarding — making it more robust than SPF for forwarded mail.

DMARC — Domain-based Message Authentication, Reporting and Conformance

DMARC answers the question: "What should receiving servers do with emails that fail SPF or DKIM checks?"

DMARC is a policy record that ties SPF and DKIM together. It requires that at least one of them passes and that the passing domain aligns with the visible From header. Then it tells receivers what to do with failures: nothing (p=none), send to spam (p=quarantine), or reject (p=reject).

How all three work together

When a receiving server processes an incoming email, it runs checks in this order:

1. It checks SPF: is the sending server's IP in the sender domain's SPF record?
2. It checks DKIM: is the signature in the email header valid, and does it match a public key in DNS?
3. It checks DMARC: does the domain that passed SPF or DKIM align with the visible From address? And what does the DMARC policy say to do with failures?

For a message to pass DMARC, at least one of the following must be true: the domain in the SPF pass matches the From header domain (SPF alignment), or the domain in the DKIM signature matches the From header domain (DKIM alignment).

What happens when one is missing

• SPF only, no DMARC: Unauthorized senders might be flagged but not blocked. Receiving servers are not required to act on SPF failures without a DMARC policy.
• DKIM only, no DMARC: Same problem. The signature is checked but failure has no defined consequence.
• SPF + DKIM, no DMARC: Both checks run but there is no enforcement. Domain spoofing is still fully possible.
• All three with p=none: Everything is monitored, nothing is blocked. Still no protection.
• All three with p=reject: Full protection. Spoofed emails are rejected at delivery.

Recommended setup order

1. Configure SPF — list all your authorized senders
2. Set up DKIM — work with your mail provider to enable signing
3. Add DMARC with p=none + rua email — collect reports for 2–4 weeks
4. Review reports — identify any legitimate sources failing authentication
5. Fix those sources — add them to SPF, ensure DKIM is enabled
6. Tighten to p=quarantine, then p=reject