Email Security

Trick 1 SPF vs. DKIM vs. DMARC — One Sentence Each

The exam asks you to match these three technologies to scenarios or descriptions. They are often confused because all three are DNS TXT records related to email authentication. The differentiation is clean once you internalize one sentence per technology:

SPF = authorized servers list. “Is this IP allowed to send mail for this domain?” The answer is in the SPF record. It validates the sending server identity. It says nothing about the message content.
DKIM = digital signature on the message. “Did this domain sign this message, and was it modified in transit?” The answer is in the DKIM signature in the message headers, validated against the public key in DNS. It proves message integrity and server authorization. It says nothing about what to do if validation fails.
DMARC = policy + reporting. “What should the receiving server do when SPF or DKIM fails, and please tell me about it.” DMARC is not a validation mechanism itself — it uses SPF and DKIM results and adds two things they lack: disposal policy and aggregate reports.

Exam trigger phrases and answers:

“Authorized sending servers for a domain” → SPF
“Digital signature on outgoing email; public key in DNS” → DKIM
“Policy for failing messages; compliance reports” → DMARC
“Extension of SPF and DKIM” → DMARC
“None/quarantine/reject options” → DMARC

Rule: SPF = who can send (server IP list). DKIM = message was signed (private/public key pair). DMARC = what to do when they fail + report back. All three = DNS TXT records.

Trick 2 DMARC Depends on SPF and DKIM — It Cannot Stand Alone

The exam occasionally tests whether candidates understand the dependency chain. DMARC is described as “an extension of SPF and DKIM” — this means it consumes their results. It does not perform authentication itself.

If SPF is not configured: DMARC has no SPF result to work with. The SPF alignment check fails by default.
If DKIM is not configured: DMARC has no DKIM result to work with. The DKIM alignment check fails by default.
If neither is configured: DMARC is essentially useless as an enforcement mechanism, even if the DMARC record exists. All messages will fail DMARC alignment and be subject to the policy — but you also have no way to identify which failures are legitimate.

The dependency direction:

DMARC requires SPF and DKIM to be deployed first
SPF works independently of DKIM and DMARC
DKIM works independently of SPF and DMARC

Common wrong answer to reject: “Deploy DMARC with p=reject to stop phishing immediately without needing SPF or DKIM first.” This is wrong: p=reject without SPF/DKIM in place will indiscriminately block or discard all email from the domain since nothing will ever pass alignment checks.

Rule: DMARC depends on SPF and DKIM results. Deploy SPF and DKIM first, then DMARC. DMARC alone without SPF/DKIM cannot distinguish legitimate from spoofed email.

Trick 3 The p=none Trap — Why You Cannot Skip Straight to p=reject

The exam presents scenarios where a security professional wants to immediately deploy the strongest email protection. The tempting answer is “deploy DMARC with p=reject immediately.” This is almost always wrong in a real-world scenario and the exam expects you to know why.

The problem with p=reject on day one: Most organizations have multiple systems that send email using their domain — CRM platforms, marketing tools, HR notifications, ticketing systems, cloud services. These may not all be in the SPF record or configured with DKIM keys. If DMARC p=reject is enforced before they are identified, legitimate business email from these services is discarded by receiving servers worldwide.

p=none first, always:

p=none causes no enforcement action — all email is delivered regardless of SPF/DKIM results
But receiving servers still send DMARC aggregate reports
The administrator reviews these reports to find every IP sending email claiming to be from the domain
Known legitimate services that fail authentication are added to SPF and configured with DKIM
Only after the pass rate in reports is high is it safe to escalate to p=quarantine and then p=reject

Rule: p=none first = monitor without blocking. Review reports. Fix SPF/DKIM gaps. Only then escalate to p=quarantine → p=reject. Jumping to p=reject without the audit phase blocks legitimate email.

Trick 4 DMARC Reports as a Phishing Detection Tool

The exam tests whether candidates know what DMARC reports actually contain and what they reveal. DMARC aggregate reports are one of the most operationally valuable tools a domain owner has — they provide a global view of who is sending email using the domain name.

What the reports show: Each report includes the sending IP, the SPF result, the DKIM result, the DMARC policy that was applied, and the message count. Reports come from every mail server that received messages claiming to be from the domain.

What authentication failure patterns mean:

Many failures from known legitimate IPs: those IPs are not in SPF or not configured with DKIM — fix the configuration
Many failures from unknown IPs worldwide: those are attackers spoofing the domain in phishing campaigns — evidence of active domain abuse

The exam scenario: “A domain owner reviews DMARC reports and sees thousands of failed messages from IPs they do not own.” The answer involves two things: this is evidence of domain spoofing, and escalating DMARC policy to p=reject instructs all receiving servers to discard these messages before they reach victims.

Rule: DMARC reports = global visibility into who is using your domain. Unknown IPs failing authentication = phishing campaign. p=reject = instruct all receiving servers worldwide to discard these spoofed messages.

Practice Scenarios

Scenario A: A security analyst receives a complaint that employees at a partner organization are receiving phishing emails that appear to come from the company’s CEO (ceo@example.com). The analyst checks example.com’s DNS and finds an SPF record listing five authorized mail servers, but no DKIM TXT record and no DMARC record. The phishing emails are originating from a server not on the SPF list. Why are the phishing emails still being delivered to the partner organization’s employees, and what configuration changes would stop this?

Answer: SPF exists and would cause the SPF check to fail for the phishing emails (the sending server is not on the authorized list). However, without a DMARC record, there is no instruction for the partner organization’s mail server about what to do when SPF fails. Each receiving mail server makes its own policy decision in the absence of DMARC — many are configured to accept mail even when SPF fails, especially with a soft-fail policy, to avoid blocking legitimate email. The phishing emails are being delivered because the partner’s mail server has no authoritative policy from example.com telling it to quarantine or reject authentication failures. The configuration changes needed: First, add a DKIM configuration to the sending mail server and publish the public key as a DNS TXT record. Second, deploy a DMARC TXT record starting with p=none to collect aggregate reports and identify all legitimate sending sources. Third, review the reports to confirm SPF is complete and DKIM is functioning correctly. Fourth, escalate to p=quarantine and then p=reject. Once p=reject is in place, any receiving mail server that checks DMARC will discard the phishing emails before delivery.

Scenario B: A company has deployed SPF, DKIM, and DMARC with p=reject for two years with no problems. The company adds a new cloud-based HR notification system that sends automated emails (onboarding, payroll, benefits updates) to employees. Within hours, employees report that none of these HR emails are arriving. The mail gateway logs show them being discarded. What caused this, what should be done immediately to restore delivery, and what should be done to prevent it from recurring for future systems?

Answer: The HR notification system sends emails using the company’s domain in the From address, but its sending servers are not listed in the company’s SPF record. DMARC p=reject is enforced — when the receiving server checks SPF for the company’s domain, the HR system’s IP is not found. SPF fails. DMARC policy applies p=reject. The email is discarded before delivery. Immediate fix: Add the HR notification system’s sending IP addresses (or its include-domain reference if it is a SaaS platform) to the company’s SPF TXT record in DNS. If the HR platform supports DKIM signing with a custom domain key, configure that as well and publish the public key. Once the SPF record is updated, subsequent emails from the HR system will pass SPF, satisfy DMARC, and be delivered. Prevention for future systems: Before any new email-sending service is deployed, the IT/security team should: (1) Identify the IP ranges or include-domains used by the service for outbound email. (2) Add them to the SPF record before the service goes live. (3) Configure DKIM signing if the platform supports it. (4) Review DMARC aggregate reports after launch to confirm authentication is passing. This prevents the p=reject policy from discarding legitimate email during every new service deployment.

Scenario C: A threat analyst at a financial institution reviews the organization’s DMARC aggregate reports and observes the following pattern: over a 72-hour period, 47,000 emails claiming to be from the institution’s domain were sent worldwide. Of these, 46,200 failed both SPF and DKIM validation and came from IP ranges in three foreign countries the institution does not operate in. 800 passed both SPF and DKIM and came from the institution’s known mail servers. The institution’s current DMARC policy is p=quarantine. The analyst proposes changing the policy to p=reject. What is the analyst’s interpretation, is the proposed change correct, and what is the effect on the 46,200 failing messages?

Answer: The analyst’s interpretation is correct. The pattern — 46,200 messages from foreign IP ranges failing SPF and DKIM, with no legitimate sending source having that IP pattern — is classic evidence of an active domain spoofing or phishing campaign. Attackers are sending emails impersonating the financial institution, likely targeting customers or business partners, using the institution’s domain name in the From address without authorization. The proposed change to p=reject is correct and appropriate at this point. The 800 messages that pass SPF and DKIM are from the institution’s known mail servers and will continue to be delivered normally under p=reject — the policy only affects messages that fail authentication. The current p=quarantine policy is sending the 46,200 spoofed messages to recipients’ spam folders, which means they may still be read. p=reject instructs every receiving mail server worldwide that checks DMARC to discard the failing messages before delivery, preventing them from reaching any recipient at all. The effect on the 46,200 failing messages: under p=reject, receiving servers will return a rejection response to the sending server and the messages will not be delivered to any inbox or spam folder. The phishing campaign becomes effectively blocked at the SMTP layer for all recipients whose mail servers honor the DMARC policy. The institution should also report the offending IP ranges to their ISP and threat intelligence feeds.

Email Security — Exam Tricks