constructing records that would exceed the 255-byte maximum length of
a string within a single TXT or SPF RR record.
3.1.4. Record Size
The published SPF record for a given domain name SHOULD remain small
enough that the results of a query for it will fit within 512 octets.
This will keep even older DNS implementations from falling over to
TCP. Since the answer size is dependent on many things outside the
scope of this document, it is only possible to give this guideline:
If the combined length of the DNS name and the text of all the
records of a given type (TXT or SPF) is under 450 characters, then
DNS answers should fit in UDP packets. Note that when computing the
sizes for queries of the TXT format, one must take into account any
other TXT records published at the domain name. Records that are too
long to fit in a single UDP packet MAY be silently ignored by SPF
clients.
3.1.5. Wildcard Records
Use of wildcard records for publishing is not recommended. Care must
be taken if wildcard records are used. If a domain publishes
wildcard MX records, it may want to publish wildcard declarations,
subject to the same requirements and problems. In particular, the
declaration must be repeated for any host that has any RR records at
all, and for subdomains thereof. For example, the example given in
[RFC1034], Section 4.3.3, could be extended with the following:
X.COM. MX 10 A.X.COM
X.COM. TXT "v=spf1 a:A.X.COM -all"
*.X.COM. MX 10 A.X.COM
*.X.COM. TXT "v=spf1 a:A.X.COM -all"
A.X.COM. A 1.2.3.4
A.X.COM. MX 10 A.X.COM
A.X.COM. TXT "v=spf1 a:A.X.COM -all"
*.A.X.COM. MX 10 A.X.COM
*.A.X.COM. TXT "v=spf1 a:A.X.COM -all"
Notice that SPF records must be repeated twice for every name within
the domain: once for the name, and once with a wildcard to cover the
tree under the name.
Use of wildcards is discouraged in general as they cause every name
under the domain to exist and queries against arbitrary names will
never return RCODE 3 (Name Error).
4. The check_host() Function
The check_host() function fetches SPF records, parses them, and
interprets them to determine whether a particular host is or is not
permitted to send mail with a given identity. Mail receivers that
perform this check MUST correctly evaluate the check_host() function
as described here.
Implementations MAY use a different algorithm than the canonical
algorithm defined here, so long as the results are the same in all
cases.
4.1. Arguments
The check_host() function takes these arguments:
<ip> - the IP address of the SMTP client that is emitting the
mail, either IPv4 or IPv6.
<domain> - the domain that provides the sought-after authorization
information; initially, the domain portion of the "MAIL
FROM" or "HELO" identity.
<sender> - the "MAIL FROM" or "HELO" identity.
The domain portion of <sender> will usually be the same as the
<domain> argument when check_host() is initially evaluated. However,
this will generally not be true for recursive evaluations (see
Section 5.2 below).
Actual implementations of the check_host() function may need
additional arguments.
4.2. Results
The function check_host() can return one of several results described
in Section 2.5. Based on the result, the action to be taken is
determined by the local policies of the receiver.
4.3. Initial Processing
If the <domain> is malformed (label longer than 63 characters, zero-
length label not at the end, etc.) or is not a fully qualified domain
name, or if the DNS lookup returns "domain does not exist" (RCODE 3),
check_host() immediately returns the result "None".
If the <sender> has no localpart, substitute the string "postmaster"
for the localpart.
4.4. Record Lookup
In accordance with how the records are published (see Section 3.1
above), a DNS query needs to be made for the <domain> name, querying
for either RR type TXT, SPF, or both. If both SPF and TXT RRs are
looked up, the queries MAY be done in parallel.
If all DNS lookups that are made return a server failure (RCODE 2),
or other error (RCODE other than 0 or 3), or time out, then
check_host() exits immediately with the result "TempError".
4.5. Selecting Records
Records begin with a version section:
record = version terms *SP
version = "v=spf1"
Starting with the set of records that were returned by the lookup,
record selection proceeds in two steps:
1. Records that do not begin with a version section of exactly
"v=spf1" are discarded. Note that the version section is
terminated either by an SP character or the end of the record. A
record with a version section of "v=spf10" does not match and must
be discarded.
2. If any records of type SPF are in the set, then all records of
type TXT are discarded.
After the above steps, there should be exactly one record remaining
and evaluation can proceed. If there are two or more records
remaining, then check_host() exits immediately with the result of
"PermError".
If no matching records are returned, an SPF client MUST assume that
the domain makes no SPF declarations. SPF processing MUST stop and
return "None".
4.6. Record Evaluation
After one SPF record has been selected, the check_host() function
parses and interprets it to find a result for the current test. If
there are any syntax errors, check_host() returns immediately with
the result "PermError".
Implementations MAY choose to parse the entire record first and
return "PermError" if the record is not syntactically well formed.
However, in all cases, any syntax errors anywhere in the record MUST
be detected.
4.6.1. Term Evaluation
There are two types of terms: mechanisms and modifiers. A record
contains an ordered list of these as specified in the following
Augmented Backus-Naur Form (ABNF).
terms = *( 1*SP ( directive / modifier ) )
directive = [ qualifier ] mechanism
qualifier = "+" / "-" / "?" / "~"
mechanism = ( all / include
/ A / MX / PTR / IP4 / IP6 / exists )
modifier = redirect / explanation / unknown-modifier
unknown-modifier = name "=" macro-string
name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
Most mechanisms allow a ":" or "/" character after the name.
Modifiers always contain an equals (’=’) character immediately after
the name, and before any ":" or "/" characters that may be part of
the macro-string.
Terms that do not contain any of "=", ":", or "/" are mechanisms, as
defined in Section 5.
As per the definition of the ABNF notation in [RFC4234], mechanism
and modifier names are case-insensitive.
4.6.2. Mechanisms
Each mechanism is considered in turn from left to right. If there
are no more mechanisms, the result is specified in Section 4.7.
When a mechanism is evaluated, one of three things can happen: it can
match, not match, or throw an exception.
If it matches, processing ends and the qualifier value is returned as
the result of that record. If it does not match, processing
continues with the next mechanism. If it throws an exception,
mechanism processing ends and the exception value is returned.
The possible qualifiers, and the results they return are as follows:
"+" Pass
"-" Fail
"~" SoftFail
"?" Neutral
The qualifier is optional and defaults to "+".
When a mechanism matches and the qualifier is "-", then a "Fail"
result is returned and the explanation string is computed as
described in Section 6.2.
The specific mechanisms are described in Section 5.
4.6.3. Modifiers
Modifiers are not mechanisms: they do not return match or not-match.
Instead they provide additional information. Although modifiers do
not directly affect the evaluation of the record, the "redirect"
modifier has an effect after all the mechanisms have been evaluated.
4.7. Default Result
If none of the mechanisms match and there is no "redirect" modifier,
then the check_host() returns a result of "Neutral", just as if
"?all" were specified as the last directive. If there is a
"redirect" modifier, check_host() proceeds as defined in Section 6.1.
Note that records SHOULD always use either a "redirect" modifier or
an "all" mechanism to explicitly terminate processing.
For example:
v=spf1 +mx -all
or
v=spf1 +mx redirect=_spf.example.com
4.8. Domain Specification
Several of these mechanisms and modifiers have a <domain-spec>
section. The <domain-spec> string is macro expanded (see Section 8).
The resulting string is the common presentation form of a fully-
qualified DNS name: a series of labels separated by periods. This
domain is called the <target-name> in the rest of this document.
Note: The result of the macro expansion is not subject to any further
escaping. Hence, this facility cannot produce all characters that
are legal in a DNS label (e.g., the control characters). However,
this facility is powerful enough to express legal host names and
common utility labels (such as "_spf") that are used in DNS.
For several mechanisms, the <domain-spec> is optional. If it is not
provided, the <domain> is used as the <target-name>.
5. Mechanism Definitions
This section defines two types of mechanisms.
Basic mechanisms contribute to the language framework. They do not
specify a particular type of authorization scheme.
all
include
Designated sender mechanisms are used to designate a set of <ip>
addresses as being permitted or not permitted to use the <domain> for
sending mail.
a
mx
ptr
ip4
ip6
exists
The following conventions apply to all mechanisms that perform a
comparison between <ip> and an IP address at any point:
If no CIDR-length is given in the directive, then <ip> and the IP
address are compared for equality. (Here, CIDR is Classless Inter-
Domain Routing.)
If a CIDR-length is specified, then only the specified number of
high-order bits of <ip> and the IP address are compared for equality.
When any mechanism fetches host addresses to compare with <ip>, when
<ip> is an IPv4 address, A records are fetched, when <ip> is an IPv6
address, AAAA records are fetched. Even if the SMTP connection is
via IPv6, an IPv4-mapped IPv6 IP address (see [RFC3513], Section
2.5.5) MUST still be considered an IPv4 address.
Several mechanisms rely on information fetched from DNS. For these
DNS queries, except where noted, if the DNS server returns an error
(RCODE other than 0 or 3) or the query times out, the mechanism
throws the exception "TempError". If the server returns "domain does
not exist" (RCODE 3), then evaluation of the mechanism continues as
if the server returned no error (RCODE 0) and zero answer records.
5.1. "all"
all = "all"
The "all" mechanism is a test that always matches. It is used as the
rightmost mechanism in a record to provide an explicit default.
For example:
v=spf1 a mx -all
Mechanisms after "all" will never be tested. Any "redirect" modifier
(Section 6.1) has no effect when there is an "all" mechanism.
5.2. "include"
include = "include" ":" domain-spec
The "include" mechanism triggers a recursive evaluation of
check_host(). The domain-spec is expanded as per Section 8. Then
check_host() is evaluated with the resulting string as the <domain>.
The <ip> and <sender> arguments remain the same as in the current
evaluation of check_host().
In hindsight, the name "include" was poorly chosen. Only the
evaluated result of the referenced SPF record is used, rather than
acting as if the referenced SPF record was literally included in the
first. For example, evaluating a "-all" directive in the referenced
record does not terminate the overall processing and does not
necessarily result in an overall "Fail". (Better names for this
mechanism would have been "if-pass", "on-pass", etc.)
The "include" mechanism makes it possible for one domain to designate
multiple administratively-independent domains. For example, a vanity
domain "example.net" might send mail using the servers of
administratively-independent domains example.com and example.org.
Example.net could say
IN TXT "v=spf1 include:example.com include:example.org -all"
This would direct check_host() to, in effect, check the records of
example.com and example.org for a "Pass" result. Only if the host
were not permitted for either of those domains would the result be
"Fail".
Whether this mechanism matches, does not match, or throws an
exception depends on the result of the recursive evaluation of
check_host():
+---------------------------------+---------------------------------+
| A recursive check_host() result | Causes the "include" mechanism |
| of: | to: |
+---------------------------------+---------------------------------+
| Pass | match |
| | |
| Fail | not match |
| | |
| SoftFail | not match |
| | |
| Neutral | not match |
| | |
| TempError | throw TempError |
| | |
| PermError | throw PermError |
| | |
| None | throw PermError |
+---------------------------------+---------------------------------+
The "include" mechanism is intended for crossing administrative
boundaries. Although it is possible to use includes to consolidate
multiple domains that share the same set of designated hosts, domains
are encouraged to use redirects where possible, and to minimize the
number of includes within a single administrative domain. For
example, if example.com and example.org were managed by the same
entity, and if the permitted set of hosts for both domains was
"mx:example.com", it would be possible for example.org to specify
"include:example.com", but it would be preferable to specify
"redirect=example.com" or even "mx:example.com".
5.3. "a"
This mechanism matches if <ip> is one of the <target-name>’s IP
addresses.
A = "a" [ ":" domain-spec ] [ dual-cidr-length ]
An address lookup is done on the <target-name>. The <ip> is compared
to the returned address(es). If any address matches, the mechanism
matches.
5.4. "mx"
This mechanism matches if <ip> is one of the MX hosts for a domain
name.
MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ]
check_host() first performs an MX lookup on the <target-name>. Then
it performs an address lookup on each MX name returned. The <ip> is
compared to each returned IP address. To prevent Denial of Service
(DoS) attacks, more than 10 MX names MUST NOT be looked up during the
evaluation of an "mx" mechanism (see Section 10). If any address
matches, the mechanism matches.
Note regarding implicit MXs: If the <target-name> has no MX records,
check_host() MUST NOT pretend the target is its single MX, and MUST
NOT default to an A lookup on the <target-name> directly. This
behavior breaks with the legacy "implicit MX" rule. See [RFC2821],
Section 5. If such behavior is desired, the publisher should specify
an "a" directive.
5.5. "ptr"
This mechanism tests whether the DNS reverse-mapping for <ip> exists
and correctly points to a domain name within a particular domain.
PTR = "ptr" [ ":" domain-spec ]
First, the <ip>’s name is looked up using this procedure: perform a
DNS reverse-mapping for <ip>, looking up the corresponding PTR record
in "in-addr.arpa." if the address is an IPv4 one and in "ip6.arpa."
if it is an IPv6 address. For each record returned, validate the
domain name by looking up its IP address. To prevent DoS attacks,
more than 10 PTR names MUST NOT be looked up during the evaluation of
a "ptr" mechanism (see Section 10). If <ip> is among the returned IP
addresses, then that domain name is validated. In pseudocode:
sending-domain_names := ptr_lookup(sending-host_IP); if more than 10
sending-domain_names are found, use at most 10. for each name in
(sending-domain_names) {
IP_addresses := a_lookup(name);
if the sending-domain_IP is one of the IP_addresses {
validated-sending-domain_names += name;
} }
Check all validated domain names to see if they end in the
<target-name> domain. If any do, this mechanism matches. If no
validated domain name can be found, or if none of the validated
domain names end in the <target-name>, this mechanism fails to match.
If a DNS error occurs while doing the PTR RR lookup, then this
mechanism fails to match. If a DNS error occurs while doing an A RR
lookup, then that domain name is skipped and the search continues.
Pseudocode:
for each name in (validated-sending-domain_names) {
if name ends in <domain-spec>, return match.
if name is <domain-spec>, return match.
}
return no-match.
This mechanism matches if the <target-name> is either an ancestor of
a validated domain name or if the <target-name> and a validated
domain name are the same. For example: "mail.example.com" is within
the domain "example.com", but "mail.bad-example.com" is not.
Note: Use of this mechanism is discouraged because it is slow, it is
not as reliable as other mechanisms in cases of DNS errors, and it
places a large burden on the arpa name servers. If used, proper PTR
records must be in place for the domain’s hosts and the "ptr"
mechanism should be one of the last mechanisms checked.
5.6. "ip4" and "ip6"
These mechanisms test whether <ip> is contained within a given IP
network.
IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ]
ip4-cidr-length = "/" 1*DIGIT
ip6-cidr-length = "/" 1*DIGIT
dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
ip4-network = qnum "." qnum "." qnum "." qnum
qnum = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
; as per conventional dotted quad notation. e.g., 192.0.2.0
ip6-network = <as per [RFC 3513], section 2.2>
; e.g., 2001:DB8::CD30
The <ip> is compared to the given network. If CIDR-length high-order
bits match, the mechanism matches.
If ip4-cidr-length is omitted, it is taken to be "/32". If
ip6-cidr-length is omitted, it is taken to be "/128". It is not
permitted to omit parts of the IP address instead of using CIDR
notations. That is, use 192.0.2.0/24 instead of 192.0.2.
5.7. "exists"
This mechanism is used to construct an arbitrary domain name that is
used for a DNS A record query. It allows for complicated schemes
involving arbitrary parts of the mail envelope to determine what is
permitted.
exists = "exists" ":" domain-spec
The domain-spec is expanded as per Section 8. The resulting domain
name is used for a DNS A RR lookup. If any A record is returned,
this mechanism matches. The lookup type is A even when the
connection type is IPv6.
Domains can use this mechanism to specify arbitrarily complex
queries. For example, suppose example.com publishes the record:
v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all
The <target-name> might expand to
"1.2.0.192.someuser._spf.example.com". This makes fine-grained
decisions possible at the level of the user and client IP address.
This mechanism enables queries that mimic the style of tests that
existing anti-spam DNS blacklists (DNSBL) use.
6. Modifier Definitions
Modifiers are name/value pairs that provide additional information.
Modifiers always have an "=" separating the name and the value.
The modifiers defined in this document ("redirect" and "exp") MAY
appear anywhere in the record, but SHOULD appear at the end, after
all mechanisms. Ordering of these two modifiers does not matter.
These two modifiers MUST NOT appear in a record more than once each.
If they do, then check_host() exits with a result of "PermError".
Unrecognized modifiers MUST be ignored no matter where in a record,
or how often. This allows implementations of this document to
gracefully handle records with modifiers that are defined in other
specifications.
6.1. redirect: Redirected Query
If all mechanisms fail to match, and a "redirect" modifier is