This quick guide will show you how to create an SPF Record (Sender Policy Framework) for your email domain using DNS TXT records.
If you do not know what an SPF Record is, please read this post. Once done you can proceed with this short SPF records guide.
SPF consists of three loosely related tasks as follows:
- Publish a policy: Domains and hosts identify the machines that are authorized to send an email on their behalf by adding TXT entries to the Domain’s DNS records. SPF records must be set for hosts whether or not they send out emails
- Check and use SPF information: Receivers retrieve and interpret the SPF information as specified and act upon the result.
- Revise mail forwarding: Plain mail forwarding is not allowed by SPF, other methods such as Remailing, Refusing, Allowlisting, and Sender Rewriting Scheme.
Create the SPF Record
The following is the general format of the SPF record as a DNS TXT record for a host that sends out email:
"v=spf1 a mx ip4:192.0.2.0/24 ip4:203.0.113.0 ip6:2001:DB8::/32 include:example.com ~all"For a host that you do not intend to send out email you can use:
"v=spf1 -all"Breaking Down the SPF Record
“v=” defines the version of SPF used.
The SPF verion is followed by arguments that provide mechanisms to use to determine if a domain is eligible to send mail.
There are a total of eight mechanisms that you can use to create the SPF record as follows:
- ALL: Matches always;
- A: Used if the domain name has an address record (A or AAAA) that can be resolved to the sender’s address, it will match that address.
- IP4: Used if the sender is in a given IPv4 address range, match.
- IP6: Used if the sender is in a given IPv6 address range, match.
- MX: Used if the domain name has an MX record resolving to the sender’s incoming mail servers address, it will match
- PTR: Used 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. It is not recommended to use this mechanism.
- EXISTS: Used if the given domain name resolves to any address regardless, match. This mechanism is rarely if never used.
- INCLUDE: References the policy of another domain. If that domain’s policy passes, this mechanism passes. However, if the included policy fails, processing continues. To fully delegate to another domain’s policy, the redirect extension modifier must be used (See Modifiers below).
Qualifiers
Each mechanism can be combined with one of the four qualifiers:
- + for a PASS result. This can be omitted as it is the default; e.g., +mx is the same as MXmx
- ? for a NEUTRAL result interpreted like NONE (no policy).
- ~ (tilde) for SOFTFAIL, a debugging aid between NEUTRAL and FAIL. Typically, messages that return a SOFTFAIL are accepted but tagged.
- – (minus) for FAIL, the mail should be rejected (see below).
Modifiers
The modifiers allow for future extensions to the framework. To date only the two modifiers defined in the RFC 4408 have been widely deployed:
- exp=some.example.com gives the name of a domain with a DNS TXT record (interpreted using SPF’s macro language) to get an explanation for FAIL results—typically a URL that is added to the SMTP error code. This feature is rarely used.
- redirect=some.example.com can be used instead of the ALL-mechanism to link to the policy record of another domain. This modifier is easier to understand than the somewhat similar INCLUDE-mechanism.
Ref: [ 1 ]
Found this article interesting? Follow Brightwhiz on Facebook, Twitter, and YouTube to read and watch more content we post.