Chapter 93 · Flashcards

Email Security — Flashcards

Ten cards covering why SMTP enables spoofing, the mail gateway role, SPF authorized-server validation, DKIM digital signatures and public-key verification, DMARC policy options and reporting, how all three technologies depend on DNS TXT records, and the correct deployment order. Click any card to flip it.

Why is email spoofing so easy, and what fundamental protocol weakness enables it?

SMTP (the protocol that transfers email between servers) was designed without sender authentication. The “From:” field in an email header is a free-text field the sending server can set to anything. Nothing in SMTP requires the sending server to prove it is authorized by the domain it claims to represent. Any server can claim to be any sender — the receiving server by default just accepts the claim. This enables phishing, BEC, malware distribution, and credential theft campaigns at massive scale.

What is a mail gateway, what does it do, and where should an on-premises mail gateway be placed?

A mail gateway is the organizational gatekeeper for all inbound email. It intercepts every message before it reaches users and evaluates it for legitimacy. It can block, quarantine, flag, or allow messages based on SPF/DKIM/DMARC results, anti-malware scanning, URL filtering, and spam scoring. An on-premises mail gateway must be placed in a screened subnet (DMZ) because it needs to accept connections from the internet. Cloud-based mail gateways process email before forwarding it to the internal mail server.

What does SPF do, what DNS record type is it stored in, and what does the receiving server check?

SPF (Sender Policy Framework) lets a domain owner publish a list of all servers authorized to send email on behalf of the domain. It is stored as a DNS TXT record. When a receiving server gets a message claiming to be from @example.com, it performs a DNS lookup for the example.com SPF record and checks whether the sending server’s IP address is on the authorized list. If it is not, the receiving server can flag, quarantine, or reject the message. SPF validates the sending server identity, not the message content.

What does DKIM do, what is the role of the private key vs. the public key, and where is the public key stored?

DKIM (DomainKeys Identified Mail) adds a server-level digital signature to outgoing email. The sending mail server uses its private key to compute a signature over the message headers and body; this signature is added to the email’s headers. The corresponding public key is published in a DNS TXT record by the domain owner. The receiving server retrieves the public key, validates the signature, and confirms: (1) the message was authorized by the domain, and (2) the message content was not modified in transit. End users never see this process.

What is DMARC, what two things does it add that SPF and DKIM lack, and what are its three policy options?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an extension of SPF and DKIM that adds two capabilities: (1) Policy enforcement — the domain owner specifies what receiving servers should do when SPF or DKIM fails. (2) Compliance reporting — receiving servers send aggregate reports back to the domain owner. The three DMARC policy options are: none (accept all, monitor only), quarantine (send failing messages to spam), reject (discard failing messages entirely). All published as a DNS TXT record.

All three email authentication technologies share one infrastructure dependency. What is it, and why does that make DNS accuracy critical?

All three — SPF, DKIM, and DMARC — are published as DNS TXT records and read by receiving mail servers via DNS lookup at the time of validation. This is fully decentralized: no bilateral agreements, no certificate authority, no enrollment. Any receiving server in the world can validate any domain that publishes these records. DNS accuracy is critical because misconfigured records cause legitimate emails to fail validation and be quarantined or rejected. Adding a new sending service without updating the SPF record immediately breaks delivery for that service.

What is the correct deployment order for SPF, DKIM, and DMARC, and why must DMARC start at p=none?

Step 1: Deploy SPF (list authorized sending servers; start with soft-fail ~all to avoid blocking). Step 2: Deploy DKIM (configure server to sign outgoing mail; publish public key in DNS). Step 3: Deploy DMARC with p=none (monitor only; review aggregate reports to find all legitimate sending sources not yet in SPF). Step 4: Escalate to p=quarantine, then p=reject once reports show high pass rates. Starting at p=reject risks discarding legitimate email from services that were not identified during the audit phase.

What does a DMARC aggregate report contain, and what two security problems does it help the domain owner detect?

DMARC aggregate reports are XML files sent by receiving mail servers to the address in the DMARC record. They show: sending IP addresses, SPF pass/fail per IP, DKIM pass/fail per message, DMARC policy disposition applied, and message volume. They help detect two problems: (1) Active domain spoofing — high volumes of authentication failures from IPs the domain does not own indicate a phishing campaign abusing the domain name. (2) Missing authorized senders — legitimate IPs appearing in failure reports that are not yet in the SPF record need to be added.

What is Business Email Compromise (BEC), and which email security technology does it most directly exploit?

BEC (Business Email Compromise) is a targeted attack where an attacker spoofs an email to appear as though it comes from a company executive, financial officer, or trusted vendor. The goal is to trick employees into transferring money, sharing credentials, or changing payment details. BEC directly exploits SMTP’s lack of sender authentication — the absence of SPF, DKIM, or DMARC allows the forged From address to reach recipients with no warning. Organizations with all three properly configured and enforced are significantly harder to target with BEC because spoofed messages are quarantined or rejected before delivery.

A company adds a new marketing platform that sends email on their behalf. Emails from the platform immediately go to spam. What is the cause, and what is the fix?

Cause: The marketing platform’s sending servers are not in the company’s SPF TXT record. When a receiving server checks SPF for the company’s domain, it does not find the platform’s IP. SPF fails. DMARC (if set to quarantine or reject) applies its policy — emails go to spam or are discarded. Fix: Add the marketing platform’s authorized sending IPs (or its include-domain reference) to the company’s SPF TXT record in DNS. The platform may also need to be configured to sign emails with DKIM using a key published in the company’s DNS.