Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization. This document obsoletes RFC 4408
Replaces RFC 4408: Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1.
This document is current and has been amended. 3 later RFCs have changed part of it. Nothing on the RFC itself tells you this.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 34 must, 29 should, 4 may.
2.2 Checking Authorization
- NOT RECOMMENDEDWithout explicit approval of the publishing ADMD, checking other identities against SPF version 1 records is NOT RECOMMENDED because there are cases that are known to give incorrect results.
- MUSTTo make the test, the mail receiver MUST evaluate the check_host() function with the arguments described in Section 4.1.
2.3 The "HELO" Identity
- RECOMMENDEDIt is RECOMMENDED that SPF verifiers not only check the "MAIL FROM" identity but also separately check the "HELO" identity by applying the check_host() function (Section 4) to the "HELO" identity as the <sender>.
- RECOMMENDEDChecking "HELO" before "MAIL FROM" is the RECOMMENDED sequence if both are checked.
2.4 The "MAIL FROM" Identity
- MUSTSPF verifiers MUST check the "MAIL FROM" identity if a "HELO" check either has not been performed or has not reached a definitive policy result by applying the check_host() function to the "MAIL FROM" identity as the <sender>.
2.5 Location of Checks
- SHOULDThe authorization check SHOULD be performed during the processing of the SMTP transaction that receives the mail.
3.1 DNS Resource Records
- MUSTSPF records MUST be published as a DNS TXT (type 16) Resource Record (RR) [RFC1035] only.
3.2 Multiple DNS Records
- MUST NOTA domain name MUST NOT have multiple records that would cause an authorization check to select more than one record.
3.3 Multiple Strings in a Single DNS Record
- MUSTIf a published record contains multiple character-strings, then the record MUST be treated as if those strings are concatenated together without adding spaces.
3.4 Record Size
- SHOULDThe 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.
3.5 Wildcard Records
- MUSTIn particular, the declaration MUST be repeated for any host that has any RR records at all, and for subdomains thereof.
4 The check_host() Function
- MUSTA compliant SPF implementation MUST produce results semantically equivalent to this description.
- MUSTReceiving ADMDs that perform this check MUST correctly evaluate the check_host() function as described here.
- MAYImplementations MAY use a different algorithm than the canonical algorithm defined here, so long as the results are the same in all cases.
4.3 Initial Processing
- MUSTInternationalized domain names MUST be encoded as A-labels, as described in Section 2.3 of [RFC5890].
4.6.4 DNS Lookup Limits
- MUSTSPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS.
- MUSTIf this limit is exceeded, the implementation MUST return "permerror".
- MUST NOTIn addition to that limit, the evaluation of each "MX" record MUST NOT result in
- MUSTIf this limit is exceeded, the "mx" mechanism MUST produce a "permerror" result.
- MUST NOTIn addition to that limit, the evaluation of each "PTR" record MUST NOT result in querying more than 10 address records -- either "A" or "AAAA" resource records.
- MUSTIf this limit is exceeded, all records other than the first 10 MUST be ignored.
- SHOULDMTAs or other processors SHOULD impose a limit on the maximum amount of elapsed time to evaluate check_host().
- SHOULDSuch a limit SHOULD allow at least 20 seconds.
- SHOULDIf such a limit is exceeded, the result of authorization SHOULD be "temperror".
- SHOULDSPF implementations SHOULD limit "void lookups" to two.
- MAYAn implementation MAY choose to make such a limit configurable.
- RECOMMENDEDIn this case, a default of two is RECOMMENDED.
5.1 "all"
- MUSTMechanisms listed after "all" MUST be ignored.
- MUSTAny "redirect" modifier (Section 6.1) MUST be ignored when there is an "all" mechanism in the record, regardless of the relative ordering of the terms.
5.4 "mx"
- MUSTTo prevent denial-of-service (DoS) attacks, the processing limits defined in Section 4.6.4 MUST be followed.
- MUST NOTNote regarding implicit MXes: If the <target-name> has no MX record, check_host() MUST NOT apply the implicit MX rules of [RFC5321] by querying for an A or AAAA record for the same name.
5.5 "ptr" (do not use)
- SHOULD NOTThis mechanism SHOULD NOT be published.
- MUSTTo prevent DoS attacks, the PTR processing limits defined in Section 4.6.4 MUST be applied.
- SHOULDIf used, proper PTR records have to be in place for the domain's hosts and the "ptr" mechanism SHOULD be one of the last mechanisms checked.
- MUSTIt is, however, still in use as part of the SPF protocol, so compliant check_host() implementations MUST support it.
6 Modifier Definitions
- SHOULDThe modifiers defined in this document ("redirect" and "exp") SHOULD appear at the end of the record, after all mechanisms, though syntactically they can appear anywhere in the record.
- MUST NOTThese two modifiers MUST NOT appear in a record more than once each.
- MUSTUnrecognized modifiers MUST be ignored no matter where, or how often, they appear in a record.
- SHOULDFor clarity, any "redirect" modifier SHOULD appear as the very last term in a record.
- MUSTAny "redirect" modifier MUST be ignored if there is an "all" mechanism anywhere in the record.
- MUSTIf no "exp" modifier is present, then either a default explanation string or an empty explanation string MUST be returned to the calling application.
- MAYImplementations MAY limit the length of the resulting explanation string to allow for other protocol constraints and/or reasonable processing limits.
- MUSTSince the explanation string is intended for an SMTP response and Section 2.4 of [RFC5321] says that responses are in [US-ASCII], the explanation string MUST be limited to [US-ASCII].
- SHOULDSoftware SHOULD make it clear that the explanation string comes from a third party.
- MUST NOTNote: During recursion into an "include" mechanism, an "exp" modifier from the <target-name> MUST NOT be used.
- MUST NOTIn contrast, when executing a "redirect" modifier, an "exp" modifier from the original domain MUST NOT be used.
7.3 Macro Processing Details
- SHOULD NOTSome older implementations of SPF prohibit trailing dots in domain names, so trailing dots SHOULD NOT be published, although they MUST be accepted by implementations conforming to this document.
- MUSTIf a DIGIT is specified, the value MUST be nonzero.
- MUSTImplementations MUST support at least a value of 127, as that is the maximum number of labels in a domain name (less the zero-length label at the end).
- SHOULDIf the <domain> is present in the list of validated domains, it SHOULD be used.
- SHOULDOtherwise, if a subdomain of the <domain> is present, it SHOULD be used.
- SHOULD NOTThis macro SHOULD NOT be published (see Section 5.5 for the discussion).
- SHOULDThis SHOULD be a fully qualified domain name, but if one does not exist (as when the checking is done by a Mail User Agent (MUA)) or if policy restrictions dictate otherwise, the word "unknown" SHOULD be substituted.
- MUSTURL escaping MUST be performed for characters not in the "unreserved" set, which is defined in [RFC3986].
8.2 Neutral
- MUSTA "neutral" result MUST be treated exactly like the "none" result; the distinction exists only for informational purposes.
8.4 Fail
- SHOULDIf the checking software chooses to reject the mail during the SMTP transaction, then it SHOULD use an SMTP reply code of 550 (see [RFC5321]) and, if supported, the 5.7.1 enhanced status code (see [RFC3463], Section 3.8), in addition to an appropriate reply text.
- SHOULDIf the checking software chooses not to reject the mail during the SMTP transaction, then it SHOULD add a Received-SPF or Authentication-Results header field (see Section 9) to communicate this result to downstream message processors.
8.5 Softfail
- SHOULD NOTReceiving software SHOULD NOT reject the message based solely on this result, but MAY subject the message to closer scrutiny than normal.
8.6 Temperror
- SHOULDIf the message is rejected during the SMTP transaction for this reason, the software SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 enhanced status code (see Section 3.5 of [RFC3463]).
8.7 Permerror
- SHOULDIf the message is rejected during the SMTP transaction for this reason, the software SHOULD use an SMTP reply code of 550 and, if supported, the 5.5.2 enhanced status code (see [RFC3463], Section 3.6).
9 Recording the Result
- RECOMMENDEDTo provide downstream agents, such as MUAs, with the information they might need in terms of evaluating or representing the apparent safety of the message content, it is RECOMMENDED that SMTP receivers record the result of SPF processing in the message header.
9.1 The Received-SPF Header Field
- SHOULDThe Received-SPF header field is a trace field (see [RFC5322], Section 3.6.7) and SHOULD be prepended to the existing header, above the Received: field that is generated by the SMTP receiver.
- MUSTIt MUST appear above all other Received-SPF fields in the message.
- SHOULDThe header field SHOULD include a "(...)" style comment after the result, conveying supporting information for the result, such as <ip>, <sender>, and <domain>.
- SHOULDSPF verifiers SHOULD give enough information so that the SPF results can be verified -- that is, at least "client-ip", "helo", and, if the "MAIL FROM" identity was checked, "envelope-from".
- MAYOther keys MAY be defined by SPF verifiers.
- MUSTSPF verifiers MUST make sure that the Received-SPF header field does not contain invalid characters, is not excessively long (see [RFC5322], Section 2.1.1), and does not contain malicious data that has been provided by the sender.