Sender Policy Framework or SPF is an email authentication platform. It helps in specifying who is allowed to send emails from your domain. Making it harder for fraudsters to spoof sender information.

SPF Records are used to specify the origin of the email to the world. It can be considered as a public list that specifies where an email is sent from.

How does SPF records look like?

SPF is configured and managed as a TXT record inside the DNS server your domain uses.

$ dig txt

;                     IN      TXT

;; ANSWER SECTION:              1800    IN      TXT     "v=spf1 ~all"


Let’s now make sense of it!

SPF records can be broken down into two parts—qualifiers and mechanisms.

  • Mechanisms - It can be set to describe who is allowed to send email on behalf of the domain. If the conditions are met, then four qualifiers can be applied.
  • Qualifiers - They are the action that is applied when a mechanism is matched. Default: +. Types of qualifiers -
    • + (Pass | Accept) - Allows mail to be delivered.
    • - (Fail | Reject) - Does not allow mail to be delivered
    • ~ (SoftFail | Accepts by tag as SPF softfail ) - Does not explicit deny by neither accepts. This means suspicious emails, or emails from unauthorized servers, are not rejected, but forwarded to a spam folder, or marked as suspicious.
    • ? (Neutral | Accept) - Matches will neither pass nor fail SFP

Anatomy of the SPF Policy

  • v=spf1 - 1st tag in the SPF Policy. Mentions the version of the SPF.

  • a - Tests the A records for the domain. If the host IP is found, it is matched.

  • all - At the end of the SPF record. Specifies what to when there is no match for the SPF Record. It is generally prefixed by a qualifier.

    E.g. - The below example allows everything from the specified IP and softfails everything else.

v=spf1 ~all
  • mx - Using mx by itself will query the A record IP addresses of the MX record for the current domain. The mx mechanism can also be paired with a completely separate domain. Using mx allows you to update your DNS without having to modify your SPF record.

    E.g. - Softfail everything else other than everything from the domain specified.

v=spf1 ~all
  • Include - Allows for another domain to be specified, and is often used when allowing third party services to send mail with your domain. Include mechanisms can be stacked, allowing for multiple senders.

  • Exists - Looks to see if the A record of any specified domain exists. If the A record exists, then this passes. The domain does not have to be your own, and simply must resolve. This can be used in conjunction with macros to have the recipient query a public spam list, and fail the SPF check if the address is listed on the list.

    E.g. - Using a macro to query a blacklist. %{i} is a macro syntax that inputs the senders IP address and then checks to see if that address is present on the list.

v=spf1 mx -exists:%{i} ~all

Now since we know all the above, we know how to understand the SPF Records.


So you may say - Understanding all of this and implementing SPF, makes you invulnerable to the problem we care about - Phishing?

The answer is NO.

SPF records apply to specific Return-Path domains, not the domain in the human-readable From address. Unfortunately, that introduces another limitation, because humans don’t generally pay attention to the Return-Path when reading emails. Instead, they look at the name and email address that appears in the “From” field in their email client or Web-based email display.

That’s where  Domain-based Message Authentication, Reporting and Conformance (DMARC) comes in. It addresses this limitation in SPF by requiring a match (called “alignment”) between the address shown in the human-readable From field and the server authenticated by SPF.

DMARC combines SPF and DKIM to provide better email security. More in subsequent blogs.

See you till then 👋


These are a few blogs that helped me curate this content and try to present it in easy manner -