At 8:41 on a Tuesday, an accounts payable clerk receives an email from ceo@example.com asking her to wire $48,000 to a new supplier before noon. The address is exactly right, down to the domain, and the CEO never sent it. SMTP, the protocol that moves mail between servers on port 25, works like the postal system: the sender writes whatever return address they like on the envelope, and the message is delivered anyway.
Email authentication closes that gap by letting a domain publish, in DNS, which servers may send its mail and how to prove a message is genuine. On the CompTIA Security+ SY0-801 exam, email security sits under objective 4.1, which expects you to choose and apply mitigating controls in a scenario. This lesson covers SPF, DKIM, DMARC and BIMI: what each record says, how a receiving server checks it, how to reach enforcement without blocking your own mail, and how to troubleshoot legitimate messages that fail.
Every message has two sender addresses, and attackers forge the one people see
A message carries two sender identities. The envelope sender is given in the SMTP MAIL FROM command and recorded in the Return-Path header; it tells servers where to send bounces, and users rarely see it. The header From address is what the mail client displays. SMTP verifies neither one, so an attacker's server can put your domain in both.
SPF, DKIM and DMARC, all published as DNS TXT records, let receiving servers check those claims, and BIMI builds on them to display a brand logo.
These records protect in two directions. Publishing them for your domain lets other organizations reject mail that forges it. Checking them on inbound mail, at your own gateway, protects your users from mail that forges someone else. A complete answer to "stop spoofed email" includes both.
Authentication has limits. A lookalike domain such as examp1e.com can publish perfect records of its own and pass every check, and a compromised real mailbox sends fully authenticated mail. Content filtering in a secure email gateway and phishing awareness training handle those cases, and they are taught in their own sections.
SPF lists the servers allowed to send for a domain
Sender Policy Framework is a TXT record published on the sending domain's own name. When a message arrives, the receiving server takes the connecting IP address, looks up the SPF record for the envelope sender's domain, and checks whether that address is on the list.
example.com. 3600 IN TXT "v=spf1 ip4:203.0.113.25 ip4:198.51.100.0/28 include:spf.protection.outlook.com include:_spf.mailer.example.net -all"
The record reads left to right. v=spf1 marks it as SPF. The ip4 and ip6 mechanisms list single addresses or ranges. a and mx authorize the hosts in the domain's own A or MX records. include: pulls in another domain's SPF record, which is how you authorize a cloud mail service. all at the end matches every sender not already listed.
A qualifier in front of a mechanism sets the result when it matches: + pass (the default), - fail, ~ softfail, ? neutral. The qualifier on all decides how strict the record is. With -all, anything not listed is unauthorized and the receiver may reject it. With ~all, receivers usually accept unlisted senders' mail but mark it as suspicious, which is common while an organization is still finding all its senders. On the exam, "only these servers may send; reject everything else" describes -all. A record ending in +all authorizes the entire internet and is a misconfiguration.
Three facts cause most SPF surprises in practice:
- Evaluating a record may take no more than 10 DNS lookups.
include,a,mx,ptr,existsand theredirectmodifier each cost one, and lookups inside included records count too, whileip4,ip6andallcost nothing. Going over the limit returns a permanent error (permerror), which DMARC treats as a failure. Every new SaaS sender adds an include, so the limit is easy to hit. - A domain may have only one SPF record. Two
v=spf1records also produce a permerror. - SPF checks the envelope domain, not the From address. An attacker who uses their own domain in
MAIL FROMand yours in the From header passes SPF. SPF also breaks when mail is forwarded, because the forwarding server's IP address isn't on the original domain's list.