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.
v=spf1 ip4:203.0.113.10 include:sendgrid.net ~all
This authorizes IP 203.0.113.10 and SendGrid's servers to send email for this domain. The ~all (softfail) means emails from unauthorized IPs should be marked suspicious but not outright rejected. -all (hardfail) means reject emails from unauthorized sources entirely.
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.
SPF verifies that the sending server is authorized to send for the domain — it's about the server identity. DKIM verifies that the email content wasn't modified after it was sent — it's about message integrity. Both can pass independently while a spoofed visible From address still appears. DMARC ties them together and adds the human-visible From address check.
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 Policy | What Happens to Failing Emails | When to Use |
|---|---|---|
| p=none | No action — emails are delivered regardless. Failures are logged and reported to the domain owner. Used for monitoring before enforcement. | Initial deployment — gather data without risking legitimate email |
| p=quarantine | Failing emails are sent to the spam/junk folder. Reduces user exposure without hard rejection. | Intermediate step during tightening |
| p=reject | Failing emails are rejected outright and not delivered. Strongest protection against spoofing. | Mature deployments with all legitimate senders properly configured |
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
ceo@company.comS/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.
| Technology | What It Protects | How It Works | Key Point for Exam |
|---|---|---|---|
| SPF | Prevents unauthorized servers from sending as your domain | DNS TXT record listing authorized IPs | Checks envelope sender / sending server IP |
| DKIM | Proves message integrity — wasn't modified in transit | Cryptographic signature in email headers, public key in DNS | Signs message with private key; verify with DNS public key |
| DMARC | Enforces SPF/DKIM and aligns with visible From address | DNS TXT policy record: none / quarantine / reject | Ties SPF + DKIM to visible From; generates reports |
| S/MIME | Encrypts email content; verifies sender identity | Public-key cryptography using X.509 certificates | End-to-end encryption; requires certificate exchange |
| STARTTLS | Encrypts SMTP traffic in transit between servers | Upgrades plain SMTP connection to TLS | Protects email in transit, not end-to-end |
Exam Scenarios
p=reject instructs receiving mail servers to outright reject emails that fail authentication, preventing them from being delivered at all. Start with p=none to monitor, move to p=quarantine, then p=reject once all legitimate senders are properly configured.