Email Security — SPF, DKIM, DMARC & S/MIME

Why Email Is a Prime Attack Vector

Email was designed without authentication in mind. The Simple Mail Transfer Protocol (SMTP) that has carried email since 1982 allows any server to claim to be sending from any domain — meaning a criminal can trivially send an email that appears to come from your CEO, your bank, or a government agency. Without additional controls, there's nothing in the protocol to stop it.

This is why phishing remains the most common initial access technique in breaches — email spoofing is trivially easy without protective controls. SPF, DKIM, and DMARC are the three DNS-based standards that, when deployed together, make domain spoofing dramatically harder. The Security+ exam tests each one and expects you to understand what each does and how they complement each other.

SPF — Sender Policy Framework

SPF is a DNS TXT record that lists every IP address and mail server authorized to send email on behalf of your domain. When a receiving mail server gets an email claiming to be from @company.com, it checks the SPF record in DNS for company.com and verifies that the sending server's IP is in the authorized list.

SPF limitation: SPF only checks the envelope sender (the technical "from" address used during SMTP delivery), not the header "From" address that users see in their email client. An attacker can pass SPF while still displaying a spoofed visible From address — this is why DKIM and DMARC are also needed.

DKIM — DomainKeys Identified Mail

DKIM adds a cryptographic digital signature to outgoing emails. The sending mail server signs the email headers and body with a private key, and includes the signature in a DKIM-Signature email header. The corresponding public key is published in a DNS TXT record. When the receiving server gets the email, it retrieves the public key from DNS and verifies the signature — proving that the email was actually sent by the domain's mail server and that the content wasn't modified in transit.

DMARC — Domain-based Message Authentication, Reporting and Conformance

DMARC is the policy layer that ties SPF and DKIM together and tells receiving mail servers what to do with emails that fail authentication. It also requires that the authenticated domain (from SPF or DKIM) aligns with the visible From address — closing the gap where an attacker could pass SPF while displaying a spoofed From.

DMARC also generates aggregate and forensic reports — the domain owner receives regular reports from receiving mail servers showing how much email is passing and failing authentication, which helps identify legitimate senders that need to be added to SPF records.

How SPF + DKIM + DMARC Work Together

S/MIME — Secure/Multipurpose Internet Mail Extensions

S/MIME operates independently of SPF/DKIM/DMARC and solves a different problem: encrypting email content end-to-end and digitally signing messages. While SPF/DKIM/DMARC protect against domain spoofing at the server level, S/MIME protects the email content itself.

S/MIME uses public-key cryptography: to send an encrypted email, you encrypt with the recipient's public key — only the recipient's private key can decrypt it. Digital signatures use the sender's private key to sign — any recipient can verify with the sender's public key that the message came from the claimed sender and wasn't modified.

Exam Scenarios

Email Header Analysis for Phishing Investigation

When investigating a suspected phishing email, analyzing the email headers is one of the first steps. Headers contain a chronological trail of the message's journey through mail servers, and they can reveal whether authentication controls were bypassed, whether the sending IP matches the claimed domain, and whether the message was modified in transit.

The key headers to examine are: Received: headers (added by each mail server that handled the message — read bottom to top for chronological order), From: (the visible sender — what users see), Reply-To: (where replies go — a different Reply-To than From is a phishing red flag), Authentication-Results: (records SPF, DKIM, and DMARC pass/fail results), and X-Originating-IP: or X-Sender-IP: (the IP that submitted the message).

A classic phishing email pattern: the From address shows CEO Name <ceo@legitimate.com> but authentication results show SPF=fail and DMARC=fail. The Received headers show the message originated from a server in an unexpected country. The Reply-To is a different domain (attacker-controlled). The combination of these signals confirms the email is spoofed. Training users to check these headers — or deploying email security tools that display authentication banners — reduces the effectiveness of display-name spoofing attacks.

Email Security for CompTIA Security+ — What to Know

Email security spans multiple Security+ domain objectives and appears in scenario-based questions throughout the exam. Here is a consolidated reference of the key email security concepts and the exam context in which each appears.

The exam tests your ability to identify which email security control addresses which threat. The threat model for email has three distinct layers: domain spoofing (an attacker sends email appearing to be from your domain), message tampering (an attacker modifies an email in transit), and content confidentiality (unauthorized parties reading email content). Each threat has a different solution: SPF and DMARC address domain spoofing; DKIM addresses message tampering through digital signatures; S/MIME addresses content confidentiality and sender authenticity through end-to-end encryption and digital signatures.

A common exam question type presents a scenario and asks which technology is needed. Key patterns: if the scenario says emails are arriving that appear to come from your CEO's domain but were not sent by your organization, deploy DMARC with p=reject. If it asks how you verify that an email was not modified between sending and receiving, the answer is DKIM (the digital signature). If it asks how to prevent others from reading a confidential email even if it's intercepted on a mail server, the answer is S/MIME encryption.

Port numbers are also tested: SMTP on port 25 (server-to-server), SMTP submission on port 587 (client-to-server with auth), POP3 on port 110 (or 995 with SSL), IMAP on port 143 (or 993 with SSL). The secure variants (SMTPS on 465, POP3S on 995, IMAPS on 993) use implicit TLS. STARTTLS upgrades an existing connection on port 587 or 143.

Additional Email Security Protocols

Beyond the core trio of SPF, DKIM, and DMARC, several additional email security mechanisms appear on the Security+ exam and in enterprise email security discussions.

MTA-STS (Mail Transfer Agent Strict Transport Security) is a DNS-based standard that allows mail server operators to declare their support for STARTTLS and require that connecting mail servers authenticate the TLS certificate. Without MTA-STS, a downgrade attack could force SMTP connections to proceed without TLS even if the server supports it. MTA-STS specifies a policy (via HTTPS) that tells sending servers "this mail server supports TLS and you must verify my certificate" — preventing opportunistic downgrade to plaintext SMTP.

BIMI (Brand Indicators for Message Identification) is an emerging standard that allows organizations with strong DMARC enforcement to display their brand logo in supporting email clients' inboxes next to authenticated emails. BIMI requires a verified DMARC policy of p=quarantine or p=reject and a Verified Mark Certificate (VMC). While BIMI is primarily a brand trust feature rather than a security control, it incentivizes organizations to properly implement and enforce DMARC — which is the genuine security benefit.

Email header analysis is a practical skill for investigating suspicious emails. Email headers contain a chronological record of every mail server the message passed through, with timestamps and IP addresses at each hop. The "Received:" headers are added by each server that handled the message, with the oldest at the bottom and the most recent at the top. Analyzing headers can reveal whether the sending IP matches the claimed domain's SPF record, whether DKIM signatures are present and valid, and whether the message passed or failed DMARC alignment — all without needing specialized tools. Many free online tools (MXToolbox, Google Admin Toolbox) can parse and visualize email headers.

Email Gateway and Spam Filtering

A Secure Email Gateway (SEG) is a dedicated appliance or cloud service that sits in the path of email traffic — both inbound and outbound — and applies multiple security controls before messages reach users' inboxes. Think of it as a combined spam filter, malware scanner, DLP engine, and policy enforcer for email. On-premises SEGs (such as Cisco IronPort, Proofpoint, or Mimecast) were the traditional deployment; cloud-based SEGs are now increasingly common for organizations using cloud email (Microsoft 365, Google Workspace).

Inbound email controls on a SEG include spam filtering (scoring emails against known spam patterns, header analysis, and reputation checks), anti-malware scanning (scanning attachments for known malware signatures), sandboxing (executing suspicious attachments in an isolated virtual environment to detect zero-day malware that evades signature scanning), and URL rewriting (replacing links in emails with proxied versions that are checked at click-time for newly-identified malicious URLs — important because links can become malicious after delivery).

Outbound email controls include DLP (Data Loss Prevention) — scanning outbound emails for sensitive data patterns (credit card numbers, Social Security Numbers, healthcare data) and blocking or quarantining messages that violate policy. Outbound DLP is a compliance requirement for industries subject to PCI-DSS and HIPAA.

SMTP Security — Port Numbers and Protocols

Understanding SMTP port numbers and the security implications of each is directly tested on Network+ and Security+.

STARTTLS is an important concept to understand correctly. It is not a protocol in itself but an SMTP command that upgrades an existing plaintext SMTP connection to an encrypted TLS connection. Port 587 connections start unencrypted and use STARTTLS to negotiate encryption. This is different from implicit TLS (used on port 465) where the connection starts encrypted from the first byte. For exam purposes: STARTTLS = opportunistic TLS upgrade on an existing connection; implicit TLS = encryption from the start.

Business Email Compromise (BEC)

Business Email Compromise (BEC) is one of the most financially damaging cyberattack categories, costing organizations billions annually. BEC attacks target organizations by compromising or spoofing executive or finance employee email accounts to authorize fraudulent wire transfers, gift card purchases, or data theft.

Common BEC scenarios include the CEO Fraud pattern: an attacker spoofs the CEO's email address (or gains access to the actual account) and emails the CFO or finance team requesting an urgent wire transfer to a new vendor. Because the request appears to come from a senior executive, employees may comply without verifying through a secondary channel. Another variant is vendor impersonation — attackers intercept legitimate business communications and modify payment details in invoices to redirect funds.

SPF, DKIM, and DMARC help prevent external spoofing, but BEC attacks where an attacker has actually compromised the legitimate email account bypass these controls entirely — the email really is coming from the real server. Defence in depth is required: mandatory secondary verification for wire transfer requests (phone call to a known number), multi-person approval workflows for large transactions, and user awareness training to recognize urgency and pressure tactics.

Email Encryption in Transit vs End-to-End

A common exam topic is the distinction between email encryption in transit (server-to-server) and end-to-end encryption (sender to recipient). These solve different problems and have different guarantees.

TLS encryption in transit (SMTP with STARTTLS or implicit TLS) encrypts the connection between mail servers. The email is encrypted while moving between the servers, but it is decrypted and re-encrypted at each hop. The email is readable in plaintext at every mail server it passes through. This protects against passive network interception but not against a compromised or curious mail server administrator.

End-to-end encryption (S/MIME or PGP) encrypts the email content with the recipient's public key before it leaves the sender's device. Only the recipient's private key can decrypt it. Even the mail servers carrying the message see only encrypted ciphertext and cannot read the content. This provides true confidentiality against all intermediaries — but requires that both sender and recipient have enrolled in the same system, which is the practical barrier to widespread adoption.

Related Articles