SPF Record Tags

The below table outlines all of the possible mechanisms and modifiers that can be seen inside an SPF TXT record. All of the tags in this list are referred to as mechanisms, except for "exp" and "redirect", which are referred to as modifiers.

Tag Description Example
Version (v) The v tag is required and represents the protocol version. It MUST be the first tag in the SPF record. An example is v=spf1
mx

if used on its own (mx) then it uses the A record IPs of the MX records for the current domain. If you put a domain or host name after it then it uses the A records of the MX records for that domain(mx:domain.com). This allows you to update your DNS without having to make a change to the SPF record.

 mx or mx:mxtoolbox.com
a

If used on its own then it uses the A record of the current domain (a). If you put a domain or host name after it then it uses that A record(a:domain.com). This allows you to update your DNS without having to make a change to the SPF record 

 a or a:mxtoolbox.com
ptr This tag is NOT recommended to be used per RFC 7208. This option will validate the PTR records to ensure that least one A record for a PTR hostname matches the original client IP. If used on its own (ptr) then it looks for the current domain. You can also specify a domain (ptr:domain.com) so that it validates against that domain.   ptr or ptr:domain.com
ip4

Specifies an IPv4 IP address (1.2.3.4) or IP CIDR Range (1.2.3.4/32) that is allowed to send mail for the domain.

 ip4:1.2.3.4 (IP Address) or ip4:208.123.79.45/24 (IP Range)
ip6

Specifies an IPv6 IP Address (2001:0db8:0123:4567:89ab:cdef:1234:5678) or IP CIDR Range (2001:0db8:0123::/36) that is allowed to send mail for the domain.

 ip6:2001:0db8:0123:4567:89ab:cdef:1234:5678 (IP Address) or 2001:0db8:0123::/36 (IP Range)
include

This tag allows the inclusion of another domain or sub domain's entire spf record. This if often used if you use a 3rd party service to send mail or have multiple domains/sub-domains that send email. Example: include:_spf.google.com. By specifying this tag you are telling the recipient mail server that all of the IP addresses contained within _spf.google.com are verified sending sources for your email.

If you use multiple senders, you will put an include: tag before each domain(i.e. v=spf1 mx ip4:1.2.3.4 include:_spf.google.com include:mcsv.com ~all). This signals that both Google (include:_spf.google.com) and Mailchimp (include:mcsv.com) are approved senders and their IP addresses should authenticate for the domain.

 include:_spf.google.com
exists

This tag performs an A record lookup on the domain used to see if one exists. If the A record exists then this passes.

 exists:google.com
all

This tag MUST go at the end of your record and provides instruction of what a recipient should do if there is not a match to your SPF record. There are 3 common options used that allow a sender to tell the user to reject mail that does match the record (-all), treat mail as suspicious (~all), and a neutral recommendation (?all) which leaves it up to the recipient. In most cases, treating the mail as suspicious will work (~all) since it will generally cause non-matching messages to be marked as spam.

 ~all
redirect The redirect modifier is used for setting domains that will use the same SPF configuration of mechanisms and tags. Basically, an SPF record is created for one domain and for other domains or subdomains that are going to use the exact same SPF policy, a redirect= points to the other domain. An example setup using redirect could be for subdomains like email.example.com and accounting.example.com. In this case, they would each have an SPF record, such as "v=spf1 redirect=spf.example.com". This setup would point to another SPF record spf.example.com, which might be used by the primary example.com domain. Redirects are also used for pointing SPF records to another host who manages the SPF for the domain(s).
exp The Explanation modifier is used for setting a message or URL to be displayed to the recipient email server - that explains information about failures. Macros are often used with this modifier. When an exp modifier is used in an SPF record, this causes the recipient server to look up the resulting TXT record for the exp value. An example of this provided by RFC-7208 Section 6.2 shows an explanation of exp=explain.spf.%{d} which would cause a TXT record lookup for explain._spf.example.com and display a message like "Mail from exmple.com should only be sent by its own servers" or "See https://%{d}/why.html?s=%{S}&i=%{I}". In the first case it displays a message, in the second it links to a URL.
Macros Macros are used to create character sequences that will be replaced by components of the message. For example a Macro that contains d would mean that its should be replaced by the domain found in the message. In another case an i would mean that it should be replaced by the IP address that was used in sending the email. Here are a list of Macro Definitions: The following macro letters are expanded in term arguments:
  • s =
  • l = local-part of
  • o = domain of
  • d =
  • i =
  • p = the validated domain name of (do not use)
  • v = the string "in-addr" if is ipv4, or "ip6" if is ipv6
  • h = HELO/EHLO domain

The following macro letters are allowed only in "exp" text:

  • c = SMTP client IP (easily readable format
  • r = domain name of host performing the check
  • t = current timestamp
 RFC-7208 Section 7.4 outlines several examples of Macros expanded using the case: The is strong-bad@email.example.com. The IPv4 SMTP client IP is 192.0.2.3. The IPv6 SMTP client IP is 2001:db8::cb01. The PTR domain name of the client IP is mx.example.org.
  • %{s} strong-bad@email.example.com
  • %{o} email.example.com
  • %{d} email.example.com
  • %{d4} email.example.com
  • %{d3} email.example.com
  • %{d2} example.com
  • %{d1} com
  • %{dr} com.example.email
  • %{d2r} example.email
  • %{l} strong-bad
  • %{l-} strong.bad
  • %{lr} strong-bad
  • %{lr-} bad.strong
  • %{l1r-} strong

Examples macros:

  • %{ir}.%{v}._spf.%{d2} 3.2.0.192.in-addr._spf.example.com
  • %{lr-}.lp._spf.%{d2} bad.strong.lp._spf.example.com
  • %{lr-}.lp.%{ir}.%{v}._spf.%{d2} bad.strong.lp.3.2.0.192.in-addr._spf.example.com
  • %{ir}.%{v}.%{l1r-}.lp._spf.%{d2} 3.2.0.192.in-addr.strong.lp._spf.example.com
  • %{d2}.trusted-domains.example.net example.com.trusted-domains.example.net
  • IPv6:
  • %{ir}.%{v}._spf.%{d2} 1.0.b.c.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6._spf.example.com

 

A normal record will have a mix of elements, such as the following:

v=spf1 ip4:64.20.227.128/28 ip4:208.123.79.32/27 include:_spf.google.com ~all

The above record says that it is using SPF Version 1 and that the IP range 64.20.227.123/28 and the IP range 208.123.79.32/27 are allowed to send email for the domain. It then says that all the entries in the SPF record for _spf.google.com are allowed to send for the domain, as well. It ends by saying that if a message comes from the domain, but does not match the SPF record, then it should be treated suspiciously.

burritos@banana-pancakes.com braunstrowman@banana-pancakes.com finnbalor@banana-pancakes.com ricflair@banana-pancakes.com randysavage@banana-pancakes.com