SPF record is a Sender Policy Framework resource record. This is defined as a regular TXT record type.
The SPF record are used to avoid spam emails. SPF record validates the mail server that delivers the email for a domain to check if it is actually an authorised server before accepting any email from it.
For example, When Server X receives an email for a user in the domain xyz.com from a Server Y claiming to be sending an email from the domain abc.com
The receiving Server X checks the SPF records for the domain abc.com and if the Server Y is an authorised sender for this domain then it accepts the email, if it is not an authorised server then rejects the email. This way, the receiving server which checks for the SPF records can reduce the amount of SPAM without even passing them onto various spam checkers and other extensions to the email servers.
The SPF records are simple TXT records although some of the newer version of the DNS servers (BIND 9.4.0) does support a SPF record type. The RFC 4408 for the Sender Policy Framework recommends using a TXT record type or add a duplicate TXT record (if using a SPF record type) as the older version of the Nameserver software do not support the SPF record type.
The record format is as for a TXT record.
<Name> TTL class TXT <text with SPF arguements>
<Name> TTL class SPF <text with SPF arguements>
The text field contains the SPF data.
The SPF data is of the following format.
v=spf1 [<Qualifier><Mechanism>] [<Qualifier><Mechanism>] <optional Modifiers>
where,
v=spf1 defines the version of the SPF format. As of now there is just one version.
<qualifier><Mechanism> One of more pair of Qualifier:Mechanism pairs that describes the mailing hosts for the domain.
<modifiers> There can be only one modifer in a SPF record.
Qualifiers
The qualifiers are the paramters that define the action to perform on a match to a Mechanism. There are four Qualifiers:
+ Pass (default)
– Fail
~ SoftFail
? Neutral
Mechanism
The following are the mechanisms that describes the host that sends email for the domains:
all – Match all
ipv4 – IPv4 Host or Network
ipv6 – IPv6 or Network
a – Match A records
mx – Match A records for the MX records
ptr – Check PTR records
exist – Check if the Domain checked resolves
include – Check for the SPF record for the domain checked
all
Always matches anything that is compared. Usually comes at the end of the record.
ip4
ip4:<ip4-address>
ip4:<ip4-network>/<prefix>
Checks the IPv4 host or the network range. If no prefix is given then it is assumed as a Host(/32).
ip6
ip6:<ip6-address>
ip6:<ip6-network>/<prefix>
Checks the IPv6 network range. If no prefix is given then it is assumed as a Host (/128).
a
a/<prefix>
a:<domain>
a:<domain>/<prefix>
All the A records for domain are tested and if the client IP is one of them then this mechanism matches. If domain is not specified, the current-domain is used.
The A records have to match the client IP exactly, unless a "prefix" is provided, in which case each IP address returned by the A lookup will be expanded to its corresponding CIDR prefix, and the client IP will be sought within that subnet.
mx
mx
mx/<prefix>
mx:<domain>
mx:<domain>/<prefix>
The A records for all the MX records for domain are tested in order of MX priority. If the client IP is found among them, this mechanism matches. If domain is not specified, the current-domain is used.
The A records have to match the client IP exactly, unless a prefix is provided, in which case each IP address returned by the A lookup will be expanded to its corresponding CIDR prefix, and the client IP will be sought within that network range.
ptr
ptr
ptr:<domain>
The hostname or hostnames for the client IP are looked up using PTR queries. The hostnames are then validated: at least one of the A records for a PTR hostname must match the original client IP. Invalid hostnames are discarded. If a valid hostname ends in domain, this mechanism matches.
If domain is not specified, the current-domain is used.
exists
exists:<domain>
Perform an A query on the provided domain. If a result is found, this constitutes a match.
include
include:<domain>
The specified domain is searched for a match. If the lookup does not return a match or an error, processing proceeds to the next directive. Warning: If the domain does not have a valid SPF record, the result is a permanent error. Some mail receivers will reject based on a PermError.
Modifiers
Modifiers are optional. A modifier may appear only once per record.
The "redirect" modifier
redirect=<domain>
The SPF record for domain replace the current record.
The "exp" modifier
exp=<domain>
If a receiving receiver rejects a message, it can include an explanation. The SPF record can specify the explanation string that senders can see.
The domain is expanded; a TXT lookup is performed. The result of the TXT query is then macro-expanded and shown to the sender. Other macros can be used to provide an customized explanation.
Examples for SPF Resource Records:
v=spf1 ip4:192.168.0.1/16 -all
Allows any host from 192.168.0.0/16 network
v=spf1 mx -all
Allows only mx servers for the domain and discards anything else (-all)
v=spf1 ptr:example.com -all
Allows any host whose hostname ends as example.com
v=spf1 exists:example.com -all
Matches if the example.com domain resolves
v=spf1 include:example.com -all
Checks the SPF records for the example.com domain and follows the matches for that domain. Fails if there is no SPF record for example.com
To quickly generate a SPF record, plese use the wizard here
To check the SPF record for your domain, click here