Email Deliverability: SPF Records – Part 2a

SPF Records – Part 2a – Mechanisms and Qualifiers

This second part will examine the options available in SPF records and breakdown some example records. I’ve again split these posts up, this time it’s to give the example SPF records a place to live on their own. That post should be up in a couple of hours. Also, if you haven’t read the first part of the article, Email Deliverability: SPF Records – Part 1, which covers the background of SPF records and gives a simple example, you might want to do so before proceeding.

SPF records have two main parts: mechanisms and qualifiers. Mechanisms are the options used to determine if a message has been sent from a valid host. There are a total of eight mechanism types. Qualifiers can be used to modify the action performed based on the mechanism. There are four qualifiers, but in practice only one is used.

Mechanisms are used to help specify the hosts that are approved senders of mail for a domain. If a mechanism results in a match, the action taken depends on the qualifier that is set. Once a match occurs, the SPF record stops being processed.

From Wikipedia, the eight mechanisms and their definition:

  • ALL – Matches always; used for a default result like -all for all IPs not matched by prior mechanisms.
  • A – If the domain name has an address record (A or AAAA) that can be resolved to the sender’s address, it will match.
  • IP4 – If the sender is in a given IPv4 address range, match.
  • IP6 – If the sender is in a given IPv6 address range, match.
  • MX – If the domain name has an MX record resolving to the sender’s address, it will match (i.e. the mail comes from one of the domain’s mail servers).
  • PTR – If the domain name (PTR record) for the client’s address is in the given domain and that domain name resolves to the client’s address (forward-confirmed reverse DNS), match.
  • EXISTS – If the given domain name resolves to any address, match (no matter the address it resolves to). This is rarely used. Along with the SPF macro language it offers more complex matches like DNSBL-queries.
  • INCLUDE – If the included (a misnomer) policy passes the test this mechanism matches. This is typically used to include policies of more than one ISP.

IP6, PTR, and EXISTS mechanisms are rarely used.

Qualifiers specify the action to be taken if a mechanism is matched. There are four qualifiers, but only one is typically utilized. From Wikipedia:

  • + for a PASS result. This can be omitted; e.g., +mx is the same as mx.
  • ? for a NEUTRAL result interpreted like NONE (no policy).
  • ~ for SOFTFAIL, a debugging aid between NEUTRAL and FAIL. Typically, messages that return a SOFTFAIL are accepted but tagged.
  • – for FAIL, the mail should be rejected.

The PASS result is the default qualifier and thus there is little reason to specify it. Any mechanism will have it as its default qualifier. The NEUTRAL result adds no benefit, and some mail servers will reject all messages if used in conjunction with the ALL mechanism. The SOFTFAIL result is typically treated as a FAIL, so there is little reason to ever utilize it.

If you look back at the SPF record for that I posted previously, things should start to make a little more sense.

v=spf1 a mx -all

Again, the v=spf1 can be ignored, and then we are left with three mechanisms. The first two have no qualifier specified, so they default to PASS (+). If a match occurs with the address (A) record or mail (MX) record the email has been validated. Otherwise, the ALL mechanism matches and, since it has a FAIL (-) qualifier, the email is ruled invalid and should be rejected.

Part 2b – SPF Record Examples will be linked here after it is posted.

Update: Part 2b is now live.

This entry was posted in Email Deliverability, SPF Records and tagged , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *