SPF Explained: Sender Policy Framework for the Security+ Exam
SPF lets a domain owner publish which mail servers are allowed to send mail on that domain's behalf. A receiving server checks the sending IP against that list and decides what to do if it is not there.
It is one of three email authentication mechanisms the Security+ exam expects you to know together — SPF, DKIM and DMARC — and the questions usually test which one does what.
How it works
The domain owner publishes a DNS TXT record listing authorised senders. When mail arrives, the receiving server takes the domain from the envelope sender, looks up that record, and compares the connecting IP address against the list.
A typical record:
v=spf1 ip4:203.0.113.10 include:_spf.google.com -all
Read left to right: this is SPF version 1; that specific IPv4 address may send; so may anything authorised by Google's record; and anything else fails.
The mechanisms
ip4: and ip6: authorise an address or CIDR range. a authorises the domain's own A record, mx authorises its MX hosts. include: pulls in another domain's policy, which is how you authorise a third-party sender such as a marketing platform. all matches everything and must come last.
The qualifiers — where the exam points are
| Qualifier | Meaning | Typical handling |
+ Pass | Authorised (the default) | Accept |
~ SoftFail | Probably not authorised | Accept but mark suspicious |
- Fail | Not authorised | Reject |
? Neutral | No assertion | Accept |
So -all is a hard fail and ~all is a soft fail. ~all is the safe setting while you are still discovering which systems send mail as your domain; -all is where you want to end up. A record ending ?all asserts nothing and is close to useless.
The limits
Two constraints that cause real failures and appear in questions.
Ten DNS lookups. An SPF evaluation may trigger at most ten DNS lookups. Mechanisms like include, a, mx and redirect each count, and includes nest — a single include for a large provider may consume several. Exceed ten and the result is PermError, which most receivers treat as a failure. Organisations using several mail services hit this easily, and the fix is flattening the record into explicit IP ranges.
One SPF record per domain. Two TXT records beginning v=spf1 produce PermError. Merge them into one.
What SPF does not do, and forwarding
SPF checks the envelope sender — the MAIL FROM address used during SMTP — not the From: header the recipient actually sees. An attacker can pass SPF for a domain they control while displaying a completely different From: address. That gap is exactly why DMARC exists.
SPF also breaks on plain forwarding. If a message is forwarded, the forwarding server becomes the sender, its IP is not in the original domain's record, and SPF fails. Mailing lists have the same problem. SRS, Sender Rewriting Scheme, is the workaround, and it is a good reason not to reject on SPF failure alone.
SPF, DKIM and DMARC together
This comparison is the reliable exam question.
| Mechanism | What it verifies | Survives forwarding? |
| SPF | The sending IP is authorised for the envelope domain | No |
| DKIM | A cryptographic signature proves the message was not altered and came from the domain | Usually |
| DMARC | Alignment between the visible From: domain and SPF or DKIM, plus a policy and reporting | Depends on the underlying check |
DMARC is what ties the other two to the address the user actually sees. Its policies are p=none for monitoring only, p=quarantine to send failures to spam, and p=reject to refuse them. The normal deployment path is none, then quarantine, then reject, using the aggregate reports to find legitimate senders before you start rejecting.
A message can pass SPF and still be a phishing email. Only DMARC alignment ties authentication to the displayed sender.
Troubleshooting
Legitimate mail failing SPF usually means a sender was never added — a CRM, a ticketing system, a payroll platform. Add its include. Sudden failures across the board suggest the ten-lookup limit was crossed when a provider changed their record. And check for a duplicate SPF record before anything else, since it invalidates the lot.
What to remember
SPF is a DNS TXT record listing authorised sending IPs, checked against the envelope sender. -all hard fails, ~all soft fails. Ten DNS lookups maximum and exactly one SPF record per domain. SPF does not check the visible From: header and breaks under forwarding, which is why DMARC alignment and DKIM are needed alongside it.
Related reading: DKIM · SMTP · DNS record types
Comments
Post a Comment