Why SPF Exists

Why SPF exists

SMTP, the protocol mail servers use to hand messages to each other, was finalized in 1982. It was designed for a network where every participant was known and trusted. There is no authentication step in plain SMTP. A sending server can claim to be anyone.

That permissive design is the single fact that makes everything in this module necessary.

The address that lies

Every message moving over SMTP has two “from” addresses. They look the same to a recipient but they live in different layers of the protocol.

The envelope sender — also called MAIL FROM, the return-path, or the bounce address — is announced during the SMTP conversation. The receiving server uses it to decide where bounces go. The recipient never sees it directly in their mail client.

The header From: — the one displayed in Outlook or Gmail — lives inside the message body. It is set by the sending application. Most users believe this is the sender.

Neither is checked by default. A server can announce MAIL FROM: <ceo@isidoregroup.com> while connecting from an IP that has nothing to do with Isidore, and the receiving server has no built-in way to know that’s a lie.

SPF closes part of that gap. Not all of it — DKIM and DMARC handle the rest of the chain. SPF’s job is narrow and specific.

What SPF actually does

SPF is a published list, in DNS, of which IP addresses are allowed to send mail using a given domain in the envelope sender. It is one TXT record at the apex of the domain. Receiving servers read it during the SMTP handshake and decide whether to accept, soft-fail, or reject.

A minimal record for an M365 tenant:

v=spf1 include:spf.protection.outlook.com -all

The receiving server reads that as: “Mail with isidoregroup.com in the envelope is authorized only from IPs published by spf.protection.outlook.com. Reject anything else.”

That’s the entire mechanism. SPF is not signing the message. It is not encrypting anything. It is not checking the From: line a user sees. It is a lookup against the connecting IP, performed against a list the domain owner controls.

The single thing SPF does not do

SPF authenticates the envelope sender, not the displayed From:. An attacker can pass SPF cleanly while forging the From: line in the message body, because SPF never looks at the body.

This matters for two reasons. First, it explains why DMARC exists — DMARC is the layer that ties SPF (and DKIM) to the visible From:. Second, it explains why you cannot “just turn on SPF” and consider phishing solved. SPF without DMARC blocks the easiest spoofing pattern (envelope spoofing) but leaves display-name and From: spoofing untouched.

When a client asks why their domain still gets spoofed after you turned on SPF, the answer is in this paragraph.

Where SPF sits in the chain

A delivery decision on a well-configured receiver looks roughly like this:

  1. Sender connects, announces HELO and MAIL FROM.
  2. Receiver looks up the SPF record for the domain in MAIL FROM.
  3. Receiver compares the sender’s IP to the authorized list.
  4. Receiver records the SPF result — pass, soft-fail, hard-fail, neutral, none.
  5. Message body arrives. DKIM signatures (if any) are checked.
  6. DMARC policy is consulted. DMARC requires SPF or DKIM to pass and align with the From: header.
  7. Receiver applies the DMARC policy — deliver, quarantine, or reject.

Step 4 is SPF. By itself it is a vote, not a verdict. DMARC turns the vote into action. We cover that in Module 5.

What Cathedra checks

Cathedra’s SpfRecordCheck.php reads the SPF record at the apex of the domain and runs four passes against it. It does not connect to any mail server. It does not send a probe message. Every finding comes from reading the TXT record alone.

The four passes:

  • Presence. Is there an SPF record at all? If not, every finding downstream is moot.
  • Uniqueness. Is there exactly one SPF record? RFC 7208 forbids multiples; if Cathedra sees two, that is a hard error.
  • Enforcement posture. What does the record end with? -all, ~all, +all, ?all, or nothing.
  • Lookup count. How many DNS-lookup mechanisms are inside the record? RFC 7208 caps total lookups at 10.

The next four lessons walk through each of these in detail, with the exact finding text Cathedra will surface when you re-run the scan.

What you should remember

  • SMTP has no built-in authentication. SPF is the patch.
  • SPF authorizes IPs against the envelope sender, not the visible From: header.
  • SPF without DMARC stops easy spoofing but leaves display-name forgery wide open.
  • One TXT record at the apex, read during the SMTP handshake. That’s the whole protocol.
  • Cathedra reads the record statically. You can predict every Cathedra SPF finding by reading the record yourself.

Next: the syntax of the record, mechanism by mechanism.

Cathedra alignment: SpfRecordCheck.php — context for every SPF finding

Previous Lesson
Back to Lesson
Next Topic