What is SPF and how it protects your domain

SPF, or Sender Policy Framework, is a DNS record that tells the world which mail servers are allowed to send email for your domain. Get it right and you turn most spoofing attempts into a failed delivery.

Email was built to trust whoever claims to be the sender. SPF is the first fix for that - a small DNS record that lists the servers allowed to send mail as your domain, so receivers can spot impostors. This guide explains what an SPF record is, how it works, where it commonly breaks, and how SecRift checks yours.

What is SPF?

SPF stands for Sender Policy Framework. It is a published list of the mail servers that are authorized to send email on behalf of your domain. The list lives in a DNS TXT record and starts with v=spf1.

Think of it as a guest list for your domain's outbound mail. When a receiving server gets a message that claims to come from [email protected], it can look up your SPF record and ask a simple question: did this message actually come from a server you approved? If the sending server is on the list, SPF passes. If it isn't, the receiver knows the message is suspect.

A typical record looks like this:

v=spf1 include:_spf.google.com ip4:192.0.2.10 -all

That says: mail from Google Workspace is allowed, mail from 192.0.2.10 is allowed, and everything else should be rejected.

How SPF works

SPF is evaluated by the receiving mail server during delivery, using a few moving parts:

• Mechanisms define who is allowed. ip4 and ip6 authorize specific addresses or ranges. a and mx authorize the domain's own hosts. include pulls in another domain's SPF policy - this is how providers like Google, Microsoft, and Mailchimp let you authorize their servers with one entry.
• Qualifiers set the verdict for each mechanism. + means pass (the default), - means fail, ~ means softfail, and ? means neutral.
• The terminator is the final all mechanism. It decides what happens to senders that matched nothing above it. -all means reject everything else, which is the strict, secure setting.

Receivers read the record left to right and stop at the first match - so order matters, and anything after a matching all is never evaluated.

There is one important limit: evaluating an SPF record may trigger no more than 10 DNS lookups. Every include, a, mx, ptr, exists, and redirect term counts. Go over the limit and receivers treat your SPF as a permanent error, which can break legitimate mail.

Why SPF matters

Without SPF, anyone can send email that appears to come from your domain. Attackers use that for phishing, invoice fraud, and brand impersonation - and your customers have no easy way to tell the fake from the real thing.

A correct SPF record with a -all terminator turns most of those attempts into a failed delivery before they reach an inbox. It is also a building block for stronger controls: DMARC relies on SPF (and DKIM) to decide which messages are aligned with your domain and which should be quarantined or rejected. In other words, SPF on its own raises the bar, and SPF done well unlocks everything above it.

Common SPF mistakes

A published record is not the same as a working one. The most frequent problems we see:

• More than one SPF record. A domain must publish exactly one v=spf1 TXT record. Two records make SPF invalid, and receivers may ignore both.
• Too many DNS lookups. Chaining several providers through include quietly pushes you past the 10-lookup limit and breaks evaluation.
• A weak terminator. Ending with ~all, ?all, or no all at all leaves the door open. +all is worse - it authorizes the entire internet.
• Broken includes. An include that points at a domain with no SPF, multiple SPF records, or invalid syntax silently weakens your policy.
• Deprecated mechanisms. The ptr mechanism and %{p} macro are slow, unreliable, and discouraged. Use explicit ranges or trusted includes instead.

How SecRift checks SPF

SecRift audits your SPF setup from the outside, the same way a receiving mail server would, and breaks the result into seven findings:

• Record publication - confirms your domain publishes exactly one v=spf1 record. No record or multiple records both fail here.
• Syntax - parses the record against RFC 7208 and flags invalid mechanisms, qualifiers, IP addresses, CIDR ranges, and macros.
• Policy terminator - checks the effective all verdict. -all passes, ~all and ?all are weaker, and +all is a critical finding.
• DNS lookup limit - counts the lookups your record triggers and warns when it exceeds 10.
• Delegated policy validity - follows every include and redirect to confirm each target resolves to one valid SPF policy, and catches reference loops.
• Deprecated mechanisms - flags ptr and %{p} macro logic.
• Authorization scope - catches obviously overbroad ranges like ip4:0.0.0.0/0 that authorize every address on the internet.

Each finding comes with a plain-language summary and, where something is wrong, one concrete fix. SecRift never sends test mail or evaluates a specific sender IP - it reads what you have published and tells you exactly where it falls short.

SPF is the foundation, but it only protects the envelope sender. To cover the visible "From" address your recipients actually see, you pair it with DMARC.

Run a free scan on any domain at secrift.com and see your SPF posture in seconds.