SPF, DKIM and DMARC: Complete Guide for CISSP

Anyone in the world can put any name they like on the From line of an email, and email itself will do nothing to stop them. Not the sending mail server, not the receiving mail server, not the protocol underneath. The system that carries most business correspondence on earth was specified with no mechanism to verify who sent a message, and it still has none.

SPF, DKIM and DMARC are the three controls added afterwards to close that gap. All three are published as public DNS records, all three are read by receiving mail servers in the seconds before a message is accepted, and all three are regularly misread as doing more than they do. Understanding exactly what each one checks, and exactly which lie each one cannot see, is what separates a candidate who can name the acronyms from one who can reason through a scenario.

This guide walks the topic from first principles: why the gap exists at all, what each of the three records checks and proves, where each one breaks, and how alignment finally ties a technical pass to the name a human being reads. It maps to Domain 4, Communication and Network Security, and it connects directly to the message integrity and digital signature material in Domain 3.

What is email authentication?

Email authentication is a set of DNS-published controls that let a receiving server decide whether a message genuinely originated from the domain it claims to come from. It authenticates a domain, never a person, and it says nothing about whether the contents of a message are safe.

The server doing that deciding is a mail transfer agent, or MTA: the software that accepts a message and relays it onward. Every organisation runs them at both ends, one sending and one receiving. All of the checks in this guide happen inside the receiving MTA.

The gap the protocol left open

Simple Mail Transfer Protocol was designed for one job: delivery. Getting the message there. Nothing in that original design asks whether the sender is who they claim to be, because the early network was small and its participants were known to one another. That assumption did not survive contact with the open internet, but the protocol did.

The fix could not be a change to SMTP itself, because no single party can upgrade every mail server in the world at once. Instead, each control was built on a system every mail server already consults: the Domain Name System. A domain publishes a small public record, and any receiver anywhere can look it up without the two ever having communicated before.

The two From addresses in every message

Before any of the three controls make sense, one structural fact has to be clear, and it is the single most important idea in the topic. Every email carries two separate sender identities, and nothing requires them to agree.

Think of a paper letter inside an envelope. The letter has a letterhead at the top, the name the reader sees. The envelope has a separate name written on the outside, used by the postal service to route and return it. Nobody checks that the two names match.

Email works the same way:

• The envelope sender, defined in RFC 5321 and set by the MAIL FROM command, is used by servers to route the message and return bounces. It is also called the return-path. This is written for machines, and most recipients never see it.
• The From header, defined in RFC 5322, is the address displayed in a mail client. This is written for people, and it is the only identity a recipient actually reads.

The sender writes both. Nothing in email’s original design checks either.

That distinction is worth committing to memory, because it explains every result that follows. SPF authenticates the envelope. DKIM authenticates whichever domain chose to sign. Neither one looks at the From header. Only DMARC does.

SPF: authorising the sending server

The Sender Policy Framework, defined in RFC 7208, works like a guest list at a private event. The host writes down in advance exactly which servers are allowed to send on the domain’s behalf, and the person at the door checks every arrival against that list.

How SPF works: publish, look up, evaluate

There are three moving parts:

1. The domain owner publishes a TXT record naming authorised sources. These can be IP ranges belonging to its own mail servers, plus include entries that delegate to third parties such as a marketing platform or a payroll system.
2. A receiving server looks up that record, using the domain in the envelope sender.
3. The receiver evaluates the IP address of the server currently connecting against the authorised list.

If the connecting address is authorised, the result is a pass. If it is not, the record’s own qualifier tells receivers how firmly the domain disowns it. Most receivers do not act on an SPF result alone: they feed it into a wider decision, which is where DMARC eventually takes over.

What an SPF pass actually proves

An SPF pass proves that the message arrived from a server address the envelope domain approves. That is the whole of it.

It does not prove that the brand in front of the reader is genuine, because SPF never reads the From header. This is the gap the rest of the topic exists to close, and a scenario that turns on it is testing whether a candidate can separate the two identities described above.

Where SPF breaks: forwarding

SPF’s structural weakness follows directly from what it checks, and the first victim of it is entirely honest.

Forwarding is everywhere in email: an old address that relays to a new one, a mailing list, a shared team alias. When a message is forwarded, the forwarder becomes the new connecting server. That server was never listed in the original domain’s SPF record, so the check fails on genuine, unaltered mail.

There is no attacker in this scenario at all. The check is simply too blunt: it judges the address a message arrived from, and forwarding changes that address by design. Some forwarders work around it by rewriting the envelope to their own domain, which does restore an SPF pass, but that pass then belongs to the forwarder rather than the original sender, so it fails DMARC alignment instead.

The ten lookup limit

One operational detail is worth carrying into an exam and into practice. SPF evaluation is capped at ten DNS lookups. Every include, a, mx, ptr and exists mechanism consumes part of that budget, and nested includes consume it recursively.

Exceed the cap and the result is a permanent error rather than a pass, which receivers commonly treat as a failure. Because each new SaaS platform that sends on a domain’s behalf usually arrives as another include, a record that worked for years can be tipped over the limit by a business unit buying a tool. It is a quiet failure mode that presents as legitimate mail suddenly failing authentication with no change to the mail itself.

CISSP Exam Note

Keep SPF’s boundary sharp. It authenticates the path, specifically the connecting server, against the record of the envelope domain. A scenario in which legitimate mail fails authentication after being forwarded or passed through a mailing list is pointing at SPF, and the mechanism that survives that journey is DKIM. A pass proves an approved server sent the mail, never that the displayed sender is real.

DKIM: signing the message itself

Where SPF checks the server the mail arrived from, DomainKeys Identified Mail checks the letter. It works like a tamper-evident seal.

How DKIM works: sign, publish, verify

Before a message leaves, the sending organisation’s mail system computes a hash of the message, always covering the From header and the body, and signs that hash with a private key that never leaves the sending system. It attaches the result as a DKIM-Signature header, which names the signing domain in its d= tag and a key label in its s= tag.

The matching public key is published in the signing domain’s DNS. There is no certificate and no certificate authority involved, which is the main way DKIM differs from the certificate model behind TLS and public key infrastructure. Because DNS is public, any receiver in the world can fetch the key without prior arrangement.

On arrival, the receiving server reads which domain signed, fetches that domain’s public key, and recomputes the hash from the message it actually received. If the two match, the receiver has cryptographic evidence of two things at once: the signed content was not altered in transit, and the named domain took responsibility for it. Change a single character and the hashes diverge, and verification fails.

Selectors and key rotation

A domain is not limited to one signing key. Each published key is found through a label called a selector, so several can be live at once.

This is what makes safe rotation possible: the domain publishes a new key under a new selector, begins signing new mail with it, and withdraws the old selector only after mail signed with it has cleared the system. Selectors are also how a domain delegates signing to a third party, by issuing that provider its own selector and key rather than handing over the primary private key.

DKIM signs, it does not encrypt

This is worth stating plainly because it is one of the most commonly confused points in the topic. DKIM provides integrity and authenticity, never confidentiality. The message travels in the clear, and anyone able to read the traffic can read the mail.

Confidentiality is a separate control operating at a different layer: TLS protects the connection between mail servers, while S/MIME or PGP protects the message itself end to end. A scenario that asks for confidentiality of message content is not asking for DKIM.

Nor does a DKIM signature deliver legal non-repudiation in the way an individual’s digital signature does. DKIM keys are held and rotated by a domain, not by a person, so a signature attests that a domain took responsibility for a message, not that a named individual cannot deny sending it.

Why the signature survives a forward

Recall the honest mail that forwarding caused to fail SPF. Now give it a DKIM signature and send it through the same forwarder.

At the receiving door, the SPF result is unchanged: the connection comes from the forwarder, that address is not on the original domain’s list, and SPF fails. But there is now a second question available. The signature rode inside the message, and a plain relay never touched it, so the receiver fetches the original domain’s public key, checks the signature, and it holds.

Mail that would have been refused now has a verifiable claim behind it. This is the clearest illustration of why the two controls are paired rather than alternatives: SPF depends on the path, DKIM travels with the message.

The caveat is that a forwarder which modifies the message does break DKIM. A mailing list that appends a footer to the body or rewrites the subject line changes the signed content, and the signature fails as designed. The Authenticated Received Chain, defined in RFC 8617, exists precisely to let a downstream receiver evaluate a message that an intermediary had to alter, by having that intermediary vouch for the authentication results it saw.

DKIM’s blind spot

DKIM has the same structural weakness as SPF, one level up, and it appears the moment an attacker stops trying to forge and starts playing by the rules.

Anyone can generate a key pair, not only honest senders. An attacker registers a domain, publishes the public half in that domain’s DNS, and signs a forged message with the private half. The signature is entirely genuine. The receiver reads the signing domain, fetches its key, verifies the signature perfectly, and passes it.

Meanwhile the From header still displays somebody else’s brand, because that field is free text and the signature check never compares the two.

A true signature under a false name. Two controls, each sound on its own terms, and the same forgery walks through both, because each one speaks for a domain the reader never sees.

CISSP Exam Note

A DKIM pass proves integrity and domain authentication, and nothing more. It does not prove confidentiality, it does not identify a human sender, and it does not prove the displayed brand is genuine. Candidates lose marks by treating a valid signature as evidence that a message is safe. A spammer who signs their own mail correctly earns a valid DKIM pass.

DMARC: alignment, policy and reporting

Domain-based Message Authentication, Reporting and Conformance, defined in RFC 9989 (which obsoletes the original RFC 7489), is the layer that finally asks the missing question: whatever passed, does it match the From address the reader sees?

DMARC authenticates nothing by itself. It consumes the SPF and DKIM results and adds three things those checks lack.

Alignment

Identifier alignment is the central idea and the one most worth understanding. DMARC takes the domain that actually earned a pass, either the envelope domain SPF checked or the signing domain DKIM verified, and compares it with the domain in the visible From header.

If they match, the message is aligned. If they do not, someone is using a name they did not earn.

This is the check that catches the honest attacker from the previous two sections. Their envelope domain, their signing domain and their DNS records are all genuinely theirs, so SPF and DKIM both pass. But the From header displays a domain they do not own, so alignment fails, and for the first time in the chain a control has actually seen the lie.

A DMARC pass requires only that one of SPF or DKIM passes and aligns. A domain with correctly aligned DKIM and no SPF record at all still passes DMARC.

Alignment comes in two modes. Relaxed, the default, accepts an organisational domain match, so a signature from mail.example.com aligns with a From address at example.com. Strict requires an exact match. Relaxed is the practical choice for most organisations, because subdomains are how sending services are normally separated.

Policy: the ladder from none to reject

Alignment alone changes nothing. The policy tag tells receivers what to do with mail that fails, and it has three settings that form a ladder a domain climbs one step at a time.

• p=none is monitor only. Receivers report but deliver anyway. Nothing about delivery changes, and the exact domain remains spoofable.
• p=quarantine tells receivers to treat failures with suspicion, typically routing them to the junk folder.
• p=reject tells receivers to refuse failing mail at the door. This is the only setting that actually stops exact-domain spoofing.

The distinction between publishing a record and enforcing one is where a great many organisations quietly sit. A domain can truthfully say it “has DMARC” while its policy has never left none, which means it has documentation rather than protection. When a scenario mentions a DMARC record, the value of p= is the detail that decides the answer.

Two further tags close common gaps. sp= sets a separate policy for subdomains, and leaving it weaker than p= is a well-worn route for spoofers to slip past a top-level policy. np= sets a policy for subdomains that do not exist at all, which is worth publishing at reject because there is no legitimate mail to break.

Enforcement can also be ramped across a percentage of mail rather than switched on for everything at once, which gives a domain a controlled way to test a tightening policy.

Reporting

p=none looks useless until you understand what it buys. Every time a receiver runs a DMARC check it can send a report back to the domain owner, and those reports are the entire reason a staged rollout works.

• Aggregate reports, requested with the rua tag, summarise pass, fail and alignment results by sending source. They are the inventory tool: for the first time, a domain can see every system in the world sending mail under its name, including the ones nobody remembered buying.
• Failure reports, requested with ruf, give per-message detail. They carry message content, so they raise privacy considerations and many large receivers decline to send them.

CISSP Exam Note

DMARC is rolled out in stages, and the reports are the reason. A domain that jumps straight to p=reject before reading its aggregate reports will refuse its own forgotten legitimate mail, turning a security improvement into an outage. The managerial answer is almost always: start at none, use the reports to find and authorise every legitimate sender, then climb one step at a time. Enforcing before the inventory is complete tends to be the most common self-inflicted incident in this area.

How the three fit together

Read as a sequence, the design becomes hard to forget. Each control closes the hole the previous one left open.

The bottom two rows are the ones worth dwelling on, because they are where the whole mechanism reaches its limit.

Where email authentication falls short

Two dangerous messages still arrive at an inbox protected by all three records at full enforcement, and recognising them matters more than being able to expand the acronyms.

Lookalike domains. An attacker stops forging and simply registers a domain that reads similarly to yours, then publishes correct records for it and sends as themselves. Every check passes, and it should, because every claim the message makes is true. The three records defend one exact domain and nothing else. Note the quiet detail: your domain’s records are never even consulted. The controls for this are brand and domain monitoring, user awareness, and defensive registration of close variants.

Compromised accounts. If an attacker takes over a real mailbox on the domain, the mail comes from the real account, through the real server, signed with the real key, perfectly aligned, with a malicious link inside. Every check passes because the message genuinely is what it claims to be. This is why business email compromise losses stay high at organisations with fully enforced authentication, and why the controls that address it are different in kind: phishing-resistant multi-factor authentication, out-of-band verification of payment changes, and incident response capability.

Two further limits are worth naming. Display-name spoofing puts a trusted person’s name in the friendly-name portion of the From header while the address beside it is unrelated, and it is especially effective on phones, where many clients show only the name. And none of the three controls inspect content at all: links and attachments are outside their scope entirely.

CISSP Exam Note

SPF, DKIM and DMARC authenticate a sending domain. They do not judge content, and they do not address lookalike domains or compromised accounts. If a scenario describes either of those, the answer lives elsewhere: awareness training, content filtering, brand monitoring or incident response. Treating a DMARC pass as proof that a message cannot be phishing is the same over-read as trusting a bare SPF or DKIM pass.

Conclusion

The three records answer a question email was never designed to ask. SPF names the servers that may send for a domain. DKIM lets any receiver verify a signature over the message itself. DMARC ties both back to the From line a person actually reads, and states what should happen when neither holds.

The thread running through all of it is the distinction between identities. Two of the three controls authenticate a domain the reader never sees, which is why each can return a perfectly valid pass on a message that is lying about its sender. Alignment is the only check that closes that gap, and a policy of reject is the only setting that acts on it.

Carry three things out of this guide, because they resolve most scenarios in the area. Forwarding breaks SPF and DKIM survives it. DKIM signs but does not encrypt. And a DMARC record left at p=none is monitoring, not protection.

Quick reference for the CISSP exam

What each control checks

• SPF: the connecting server’s IP address, against a TXT record published by the envelope domain (RFC 5321). Defined in RFC 7208.
• DKIM: a cryptographic signature over the message, verified with a public key published in DNS under a selector. Provides integrity and domain authentication.
• DMARC: whether a passing SPF or DKIM result aligns with the From header domain (RFC 5322), plus a policy and reporting. Defined in RFC 9989.

The two identities

• Envelope sender (RFC 5321, MAIL FROM, return-path): used for routing and bounces. What SPF checks.
• From header (RFC 5322): what a person reads. What DMARC aligns against. Free text that nothing else verifies.

Policy values

• p=none: monitor only, reports flow, delivery unchanged. Not protection.
• p=quarantine: failures treated as suspicious, typically junked.
• p=reject: failures refused. The only setting that stops exact-domain spoofing.
• sp=: separate policy for subdomains. np=: policy for non-existent subdomains.
• rua: aggregate reports. ruf: per-message failure reports.

Failure modes to recognise

• Forwarding breaks SPF because the connecting server changes. DKIM survives a plain relay.
• A list that rewrites the subject or appends a footer breaks DKIM too. ARC (RFC 8617) exists for that case.
• SPF is capped at ten DNS lookups; exceeding it produces a permanent error, not a pass.
• A weaker sp= than p= leaves subdomains spoofable.
• Enforcing before the sender inventory is complete blocks legitimate mail.

Common exam mistakes

• Believing DKIM encrypts. It signs. Confidentiality needs TLS, S/MIME or PGP.
• Believing SPF or DKIM validates the visible From address. Only DMARC alignment does.
• Believing a published DMARC record means enforcement. Check the p= value.
• Believing DMARC requires both SPF and DKIM to pass. It requires one to pass and align.
• Believing full enforcement stops phishing. It stops exact-domain spoofing only.