Email Security Fundamentals: SPF, DKIM, DMARC

By Taylor Thomas · 2026-08-30

Base SMTP provides no sender authentication. The protocol that moves the world’s email places no check of its own on the envelope sender or From: header a connecting server presents, which means the address a recipient sees proves nothing about who sent the message. SPF and DKIM are the retrofit’s two mechanisms — an IP-based authorization check and a cryptographic signature — each authenticating a different identifier; DMARC is the rule that ties either proof to the visible From: address and adds policy and reporting. How they interlock — through DMARC’s alignment rule — is the part engineers most often miss.

SPF: Which Hosts May Send

SPF (RFC 7208) is an authorization list in DNS. A domain publishes a TXT record naming the hosts permitted to send mail on its behalf; the receiving server checks the connecting IP against the record for the domain in the envelope sender — the RFC5321.MailFrom address used in the SMTP transaction, not the From: header the user reads. (When the reverse path is null, as in bounces, the HELO identity is checked instead.) Pass means the IP was authorized for that envelope domain. Two operational edges matter. First, evaluation is capped at ten DNS-querying terms — include:, a, mx, ptr, exists, and the redirect modifier all count — and busy domains with stacked include: chains exceed that limit and fail SPF evaluation with a PermError result. Second, conventional forwarding commonly breaks SPF: the forwarder’s IP is not in the origin domain’s record, so a legitimately forwarded message arrives looking unauthorized. (Forwarders that rewrite the envelope sender can restore an SPF pass — for their own domain, which typically will not align with the original From:.)

DKIM: A Signature That Travels

DKIM (RFC 6376) lets a domain take responsibility for a message in a way that travels with it. The signer adds a DKIM-Signature header carrying a cryptographic signature over the body and a chosen set of headers; the receiver fetches the public key from DNS — published under a selector inside the signing domain’s namespace — and verifies. A valid signature proves the message passed through infrastructure holding the signing domain’s key and that the signed representation — after the declared canonicalization — is intact. Because the proof rides inside the message, it can survive forwarding untouched. Its weakness is the mirror image: an intermediary that alters what was signed — the classic case is a mailing list adding a subject tag or a footer — commonly invalidates the signature.

DMARC: Alignment With the Address Users See

Here is the gap the first two leave open: SPF authenticates the envelope domain and DKIM authenticates the signing domain, and neither is the From: header a human reads. A message can pass both while displaying an entirely unrelated From: address. DMARC (RFC 7489) closes this with alignment. A message passes DMARC only when SPF or DKIM passes and the passing identifier’s domain aligns with the From: domain. One aligned pass suffices — which is the design’s quiet elegance, since forwarding tends to break SPF while DKIM usually survives it.

Alignment itself comes in two strengths. Relaxed alignment, the default, accepts a match at the organizational-domain level — mail from a subdomain can align with a From: address at the parent domain. Strict alignment demands an exact domain match. Relaxed is where deployments generally stay, because real infrastructure sends from subdomains; strict is an option for domains that can afford the precision, not a required stage.

DMARC also gives the domain owner two levers. A published policy — none, quarantine, or reject — requests a treatment for failing mail; receivers apply it at their own discretion. And aggregate reports flow back to the domain owner from participating receivers, showing the sources those receivers observed sending as the domain. The common staged rollout runs on those reports: publish none and inventory what the reports reveal, get every legitimate sender authenticating with alignment, then step to quarantine and finish at reject. Domains that jump straight to reject discover their own payroll and ticketing systems the hard way — third-party senders that were never configured to sign, whose mail enforcing receivers start refusing.

Where This Sits in a Cisco Security Practice

All three protocols live or die by DNS — the records that publish policy and keys are DNS records, which is one more reason DNS-layer visibility sits so close to email defense. On the exam side, the SCOR 350-701 blueprint does not name the three protocols; what it lists is controls against phishing and social engineering, and configuring email security features — and sender authentication is foundational to the anti-spoofing half of that work. Cisco’s email security platforms implement SPF, DKIM, and DMARC verification and enforcement as core policy machinery, so the engineer who can read an authentication-results header calmly is the one who configures those policies well. For the broader path from fundamentals to the security track, start here.

Frequently Asked Questions

Why do I need all three — isn't SPF enough?

SPF authenticates the envelope sender's domain against the connecting IP, but nothing requires that domain to match the From: address the person reads. An attacker can pass SPF for a domain they control while displaying your domain in the From: header. DMARC closes that gap by requiring the passing identifier to align with the visible From: domain, and DKIM gives messages an authentication that usually survives forwarding, which SPF does not.

What does a DMARC policy of none actually do?

It requests no DMARC-specific action — receivers still apply their other filtering as usual — and, with a reporting address published in the record's rua tag, aggregate reports may begin arriving from participating receivers, which is the point. Reports show the sources participating receivers observe sending as your domain, legitimate and not. Domain owners typically run at none while inventorying senders, move to quarantine once legitimate sources authenticate cleanly, and finish at reject.

Does DMARC stop phishing?

It counters one specific technique: exact-domain spoofing of the protected domain's From: address, at receivers that check and honor the policy. Phishing that uses a look-alike domain, a compromised legitimate account, or a display-name trick is outside its mechanism. That still makes DMARC worth deploying — exact-domain spoofing is the variant that borrows a brand's exact address — but it is one control in a layered defense, not the layer itself.