7 Network Working Group M. Wong
8 Request for Comments: 4408 W. Schlitt
9 Category: Experimental April 2006
12 Sender Policy Framework (SPF) for
13 Authorizing Use of Domains in E-Mail, Version 1
17 This memo defines an Experimental Protocol for the Internet
18 community. It does not specify an Internet standard of any kind.
19 Discussion and suggestions for improvement are requested.
20 Distribution of this memo is unlimited.
24 Copyright (C) The Internet Society (2006).
28 The following documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408)
29 are published simultaneously as Experimental RFCs, although there is
30 no general technical consensus and efforts to reconcile the two
31 approaches have failed. As such, these documents have not received
32 full IETF review and are published "AS-IS" to document the different
33 approaches as they were considered in the MARID working group.
35 The IESG takes no position about which approach is to be preferred
36 and cautions the reader that there are serious open issues for each
37 approach and concerns about using them in tandem. The IESG believes
38 that documenting the different approaches does less harm than not
41 Note that the Sender ID experiment may use DNS records that may have
42 been created for the current SPF experiment or earlier versions in
43 this set of experiments. Depending on the content of the record,
44 this may mean that Sender-ID heuristics would be applied incorrectly
45 to a message. Depending on the actions associated by the recipient
46 with those heuristics, the message may not be delivered or may be
49 Participants relying on Sender ID experiment DNS records are warned
50 that they may lose valid messages in this set of circumstances.
51 aParticipants publishing SPF experiment DNS records should consider
52 the advice given in section 3.4 of RFC 4406 and may wish to publish
53 both v=spf1 and spf2.0 records to avoid the conflict.
58 Wong & Schlitt Experimental [Page 1]
60 RFC 4408 Sender Policy Framework (SPF) April 2006
63 Participants in the Sender-ID experiment need to be aware that the
64 way Resent-* header fields are used will result in failure to receive
65 legitimate email when interacting with standards-compliant systems
66 (specifically automatic forwarders which comply with the standards by
67 not adding Resent-* headers, and systems which comply with RFC 822
68 but have not yet implemented RFC 2822 Resent-* semantics). It would
69 be inappropriate to advance Sender-ID on the standards track without
70 resolving this interoperability problem.
72 The community is invited to observe the success or failure of the two
73 approaches during the two years following publication, in order that
74 a community consensus can be reached in the future.
78 E-mail on the Internet can be forged in a number of ways. In
79 particular, existing protocols place no restriction on what a sending
80 host can use as the reverse-path of a message or the domain given on
81 the SMTP HELO/EHLO commands. This document describes version 1 of
82 the Sender Policy Framework (SPF) protocol, whereby a domain may
83 explicitly authorize the hosts that are allowed to use its domain
84 name, and a receiving host may check such authorization.
88 1. Introduction ....................................................4
89 1.1. Protocol Status ............................................4
90 1.2. Terminology ................................................5
91 2. Operation .......................................................5
92 2.1. The HELO Identity ..........................................5
93 2.2. The MAIL FROM Identity .....................................5
94 2.3. Publishing Authorization ...................................6
95 2.4. Checking Authorization .....................................6
96 2.5. Interpreting the Result ....................................7
97 2.5.1. None ................................................8
98 2.5.2. Neutral .............................................8
99 2.5.3. Pass ................................................8
100 2.5.4. Fail ................................................8
101 2.5.5. SoftFail ............................................9
102 2.5.6. TempError ...........................................9
103 2.5.7. PermError ...........................................9
104 3. SPF Records .....................................................9
105 3.1. Publishing ................................................10
106 3.1.1. DNS Resource Record Types ..........................10
107 3.1.2. Multiple DNS Records ...............................11
108 3.1.3. Multiple Strings in a Single DNS record ............11
109 3.1.4. Record Size ........................................11
110 3.1.5. Wildcard Records ...................................11
114 Wong & Schlitt Experimental [Page 2]
116 RFC 4408 Sender Policy Framework (SPF) April 2006
119 4. The check_host() Function ......................................12
120 4.1. Arguments .................................................12
121 4.2. Results ...................................................13
122 4.3. Initial Processing ........................................13
123 4.4. Record Lookup .............................................13
124 4.5. Selecting Records .........................................13
125 4.6. Record Evaluation .........................................14
126 4.6.1. Term Evaluation ....................................14
127 4.6.2. Mechanisms .........................................15
128 4.6.3. Modifiers ..........................................15
129 4.7. Default Result ............................................16
130 4.8. Domain Specification ......................................16
131 5. Mechanism Definitions ..........................................16
132 5.1. "all" .....................................................17
133 5.2. "include" .................................................18
134 5.3. "a" .......................................................19
135 5.4. "mx" ......................................................20
136 5.5. "ptr" .....................................................20
137 5.6. "ip4" and "ip6" ...........................................21
138 5.7. "exists" ..................................................22
139 6. Modifier Definitions ...........................................22
140 6.1. redirect: Redirected Query ................................23
141 6.2. exp: Explanation ..........................................23
142 7. The Received-SPF Header Field ..................................25
143 8. Macros .........................................................27
144 8.1. Macro Definitions .........................................27
145 8.2. Expansion Examples ........................................30
146 9. Implications ...................................................31
147 9.1. Sending Domains ...........................................31
148 9.2. Mailing Lists .............................................32
149 9.3. Forwarding Services and Aliases ...........................32
150 9.4. Mail Services .............................................34
151 9.5. MTA Relays ................................................34
152 10. Security Considerations .......................................35
153 10.1. Processing Limits ........................................35
154 10.2. SPF-Authorized E-Mail May Contain Other False
155 Identities ...............................................37
156 10.3. Spoofed DNS and IP Data ..................................37
157 10.4. Cross-User Forgery .......................................37
158 10.5. Untrusted Information Sources ............................38
159 10.6. Privacy Exposure .........................................38
160 11. Contributors and Acknowledgements .............................38
161 12. IANA Considerations ...........................................39
162 12.1. The SPF DNS Record Type ..................................39
163 12.2. The Received-SPF Mail Header Field .......................39
164 13. References ....................................................39
165 13.1. Normative References .....................................39
166 13.2. Informative References ...................................40
170 Wong & Schlitt Experimental [Page 3]
172 RFC 4408 Sender Policy Framework (SPF) April 2006
175 Appendix A. Collected ABNF .......................................42
176 Appendix B. Extended Examples ....................................44
177 B.1. Simple Examples ..........................................44
178 B.2. Multiple Domain Example ..................................45
179 B.3. DNSBL Style Example ......................................46
180 B.4. Multiple Requirements Example ............................46
184 The current E-Mail infrastructure has the property that any host
185 injecting mail into the mail system can identify itself as any domain
186 name it wants. Hosts can do this at a variety of levels: in
187 particular, the session, the envelope, and the mail headers.
188 Although this feature is desirable in some circumstances, it is a
189 major obstacle to reducing Unsolicited Bulk E-Mail (UBE, aka spam).
190 Furthermore, many domain name holders are understandably concerned
191 about the ease with which other entities may make use of their domain
192 names, often with malicious intent.
194 This document defines a protocol by which domain owners may authorize
195 hosts to use their domain name in the "MAIL FROM" or "HELO" identity.
196 Compliant domain holders publish Sender Policy Framework (SPF)
197 records specifying which hosts are permitted to use their names, and
198 compliant mail receivers use the published SPF records to test the
199 authorization of sending Mail Transfer Agents (MTAs) using a given
200 "HELO" or "MAIL FROM" identity during a mail transaction.
202 An additional benefit to mail receivers is that after the use of an
203 identity is verified, local policy decisions about the mail can be
204 made based on the sender's domain, rather than the host's IP address.
205 This is advantageous because reputation of domain names is likely to
206 be more accurate than reputation of host IP addresses. Furthermore,
207 if a claimed identity fails verification, local policy can take
208 stronger action against such E-Mail, such as rejecting it.
212 SPF has been in development since the summer of 2003 and has seen
213 deployment beyond the developers beginning in December 2003. The
214 design of SPF slowly evolved until the spring of 2004 and has since
215 stabilized. There have been quite a number of forms of SPF, some
216 written up as documents, some submitted as Internet Drafts, and many
217 discussed and debated in development forums.
219 The goal of this document is to clearly document the protocol defined
220 by earlier draft specifications of SPF as used in existing
221 implementations. This conception of SPF is sometimes called "SPF
222 Classic". It is understood that particular implementations and
226 Wong & Schlitt Experimental [Page 4]
228 RFC 4408 Sender Policy Framework (SPF) April 2006
231 deployments may differ from, and build upon, this work. It is hoped
232 that we have nonetheless captured the common understanding of SPF
237 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
238 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
239 document are to be interpreted as described in [RFC2119].
241 This document is concerned with the portion of a mail message
242 commonly called "envelope sender", "return path", "reverse path",
243 "bounce address", "2821 FROM", or "MAIL FROM". Since these terms are
244 either not well defined or often used casually, this document defines
245 the "MAIL FROM" identity in Section 2.2. Note that other terms that
246 may superficially look like the common terms, such as "reverse-path",
247 are used only with the defined meanings from normative documents.
251 2.1. The HELO Identity
253 The "HELO" identity derives from either the SMTP HELO or EHLO command
254 (see [RFC2821]). These commands supply the SMTP client (sending
255 host) for the SMTP session. Note that requirements for the domain
256 presented in the EHLO or HELO command are not always clear to the
257 sending party, and SPF clients must be prepared for the "HELO"
258 identity to be malformed or an IP address literal. At the time of
259 this writing, many legitimate E-Mails are delivered with invalid HELO
262 It is RECOMMENDED that SPF clients not only check the "MAIL FROM"
263 identity, but also separately check the "HELO" identity by applying
264 the check_host() function (Section 4) to the "HELO" identity as the
267 2.2. The MAIL FROM Identity
269 The "MAIL FROM" identity derives from the SMTP MAIL command (see
270 [RFC2821]). This command supplies the "reverse-path" for a message,
271 which generally consists of the sender mailbox, and is the mailbox to
272 which notification messages are to be sent if there are problems
273 delivering the message.
275 [RFC2821] allows the reverse-path to be null (see Section 4.5.5 in
276 RFC 2821). In this case, there is no explicit sender mailbox, and
277 such a message can be assumed to be a notification message from the
278 mail system itself. When the reverse-path is null, this document
282 Wong & Schlitt Experimental [Page 5]
284 RFC 4408 Sender Policy Framework (SPF) April 2006
287 defines the "MAIL FROM" identity to be the mailbox composed of the
288 localpart "postmaster" and the "HELO" identity (which may or may not
289 have been checked separately before).
291 SPF clients MUST check the "MAIL FROM" identity. SPF clients check
292 the "MAIL FROM" identity by applying the check_host() function to the
293 "MAIL FROM" identity as the <sender>.
295 2.3. Publishing Authorization
297 An SPF-compliant domain MUST publish a valid SPF record as described
298 in Section 3. This record authorizes the use of the domain name in
299 the "HELO" and "MAIL FROM" identities by the MTAs it specifies.
301 If domain owners choose to publish SPF records, it is RECOMMENDED
302 that they end in "-all", or redirect to other records that do, so
303 that a definitive determination of authorization can be made.
305 Domain holders may publish SPF records that explicitly authorize no
306 hosts if mail should never originate using that domain.
308 When changing SPF records, care must be taken to ensure that there is
309 a transition period so that the old policy remains valid until all
310 legitimate E-Mail has been checked.
312 2.4. Checking Authorization
314 A mail receiver can perform a set of SPF checks for each mail message
315 it receives. An SPF check tests the authorization of a client host
316 to emit mail with a given identity. Typically, such checks are done
317 by a receiving MTA, but can be performed elsewhere in the mail
318 processing chain so long as the required information is available and
319 reliable. At least the "MAIL FROM" identity MUST be checked, but it
320 is RECOMMENDED that the "HELO" identity also be checked beforehand.
322 Without explicit approval of the domain owner, checking other
323 identities against SPF version 1 records is NOT RECOMMENDED because
324 there are cases that are known to give incorrect results. For
325 example, almost all mailing lists rewrite the "MAIL FROM" identity
326 (see Section 9.2), but some do not change any other identities in the
327 message. The scenario described in Section 9.3, sub-section 1.2, is
328 another example. Documents that define other identities should
329 define the method for explicit approval.
331 It is possible that mail receivers will use the SPF check as part of
332 a larger set of tests on incoming mail. The results of other tests
333 may influence whether or not a particular SPF check is performed.
334 For example, finding the sending host's IP address on a local white
338 Wong & Schlitt Experimental [Page 6]
340 RFC 4408 Sender Policy Framework (SPF) April 2006
343 list may cause all other tests to be skipped and all mail from that
346 When a mail receiver decides to perform an SPF check, it MUST use a
347 correctly-implemented check_host() function (Section 4) evaluated
348 with the correct parameters. Although the test as a whole is
349 optional, once it has been decided to perform a test it must be
350 performed as specified so that the correct semantics are preserved
351 between publisher and receiver.
353 To make the test, the mail receiver MUST evaluate the check_host()
354 function with the arguments set as follows:
356 <ip> - the IP address of the SMTP client that is emitting the
357 mail, either IPv4 or IPv6.
359 <domain> - the domain portion of the "MAIL FROM" or "HELO" identity.
361 <sender> - the "MAIL FROM" or "HELO" identity.
363 Note that the <domain> argument may not be a well-formed domain name.
364 For example, if the reverse-path was null, then the EHLO/HELO domain
365 is used, with its associated problems (see Section 2.1). In these
366 cases, check_host() is defined in Section 4.3 to return a "None"
369 Although invalid, malformed, or non-existent domains cause SPF checks
370 to return "None" because no SPF record can be found, it has long been
371 the policy of many MTAs to reject E-Mail from such domains,
372 especially in the case of invalid "MAIL FROM". In order to prevent
373 the circumvention of SPF records, rejecting E-Mail from invalid
374 domains should be considered.
376 Implementations must take care to correctly extract the <domain> from
377 the data given with the SMTP MAIL FROM command as many MTAs will
378 still accept such things as source routes (see [RFC2821], Appendix
379 C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]).
380 These archaic features have been maliciously used to bypass security
383 2.5. Interpreting the Result
385 This section describes how software that performs the authorization
386 should interpret the results of the check_host() function. The
387 authorization check SHOULD be performed during the processing of the
388 SMTP transaction that sends the mail. This allows errors to be
389 returned directly to the sending MTA by way of SMTP replies.
394 Wong & Schlitt Experimental [Page 7]
396 RFC 4408 Sender Policy Framework (SPF) April 2006
399 Performing the authorization after the SMTP transaction has finished
400 may cause problems, such as the following: (1) It may be difficult to
401 accurately extract the required information from potentially
402 deceptive headers; (2) legitimate E-Mail may fail because the
403 sender's policy may have since changed.
405 Generating non-delivery notifications to forged identities that have
406 failed the authorization check is generally abusive and against the
407 explicit wishes of the identity owner.
411 A result of "None" means that no records were published by the domain
412 or that no checkable sender domain could be determined from the given
413 identity. The checking software cannot ascertain whether or not the
414 client host is authorized.
418 The domain owner has explicitly stated that he cannot or does not
419 want to assert whether or not the IP address is authorized. A
420 "Neutral" result MUST be treated exactly like the "None" result; the
421 distinction exists only for informational purposes. Treating
422 "Neutral" more harshly than "None" would discourage domain owners
423 from testing the use of SPF records (see Section 9.1).
427 A "Pass" result means that the client is authorized to inject mail
428 with the given identity. The domain can now, in the sense of
429 reputation, be considered responsible for sending the message.
430 Further policy checks can now proceed with confidence in the
431 legitimate use of the identity.
435 A "Fail" result is an explicit statement that the client is not
436 authorized to use the domain in the given identity. The checking
437 software can choose to mark the mail based on this or to reject the
440 If the checking software chooses to reject the mail during the SMTP
441 transaction, then it SHOULD use an SMTP reply code of 550 (see
442 [RFC2821]) and, if supported, the 5.7.1 Delivery Status Notification
443 (DSN) code (see [RFC3464]), in addition to an appropriate reply text.
444 The check_host() function may return either a default explanation
445 string or one from the domain that published the SPF records (see
446 Section 6.2). If the information does not originate with the
450 Wong & Schlitt Experimental [Page 8]
452 RFC 4408 Sender Policy Framework (SPF) April 2006
455 checking software, it should be made clear that the text is provided
456 by the sender's domain. For example:
458 550-5.7.1 SPF MAIL FROM check failed:
459 550-5.7.1 The domain example.com explains:
460 550 5.7.1 Please see http://www.example.com/mailpolicy.html
464 A "SoftFail" result should be treated as somewhere between a "Fail"
465 and a "Neutral". The domain believes the host is not authorized but
466 is not willing to make that strong of a statement. Receiving
467 software SHOULD NOT reject the message based solely on this result,
468 but MAY subject the message to closer scrutiny than normal.
470 The domain owner wants to discourage the use of this host and thus
471 desires limited feedback when a "SoftFail" result occurs. For
472 example, the recipient's Mail User Agent (MUA) could highlight the
473 "SoftFail" status, or the receiving MTA could give the sender a
474 message using a technique called "greylisting" whereby the MTA can
475 issue an SMTP reply code of 451 (4.3.0 DSN code) with a note the
476 first time the message is received, but accept it the second time.
480 A "TempError" result means that the SPF client encountered a
481 transient error while performing the check. Checking software can
482 choose to accept or temporarily reject the message. If the message
483 is rejected during the SMTP transaction for this reason, the software
484 SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 DSN
489 A "PermError" result means that the domain's published records could
490 not be correctly interpreted. This signals an error condition that
491 requires manual intervention to be resolved, as opposed to the
492 TempError result. Be aware that if the domain owner uses macros
493 (Section 8), it is possible that this result is due to the checked
494 identities having an unexpected format.
498 An SPF record is a DNS Resource Record (RR) that declares which hosts
499 are, and are not, authorized to use a domain name for the "HELO" and
500 "MAIL FROM" identities. Loosely, the record partitions all hosts
501 into permitted and not-permitted sets (though some hosts might fall
502 into neither category).
506 Wong & Schlitt Experimental [Page 9]
508 RFC 4408 Sender Policy Framework (SPF) April 2006
511 The SPF record is a single string of text. An example record is the
514 v=spf1 +mx a:colo.example.com/28 -all
516 This record has a version of "spf1" and three directives: "+mx",
517 "a:colo.example.com/28" (the + is implied), and "-all".
521 Domain owners wishing to be SPF compliant must publish SPF records
522 for the hosts that are used in the "MAIL FROM" and "HELO" identities.
523 The SPF records are placed in the DNS tree at the host name it
524 pertains to, not a subdomain under it, such as is done with SRV
525 records. This is the same whether the TXT or SPF RR type (see
526 Section 3.1.1) is used.
528 The example above in Section 3 might be published via these lines in
531 example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all"
532 smtp-out.example.com. TXT "v=spf1 a -all"
534 When publishing via TXT records, beware of other TXT records
535 published there for other purposes. They may cause problems with
536 size limits (see Section 3.1.4).
538 3.1.1. DNS Resource Record Types
540 This document defines a new DNS RR of type SPF, code 99. The format
541 of this type is identical to the TXT RR [RFC1035]. For either type,
542 the character content of the record is encoded as [US-ASCII].
544 It is recognized that the current practice (using a TXT record) is
545 not optimal, but it is necessary because there are a number of DNS
546 server and resolver implementations in common use that cannot handle
547 the new RR type. The two-record-type scheme provides a forward path
548 to the better solution of using an RR type reserved for this purpose.
550 An SPF-compliant domain name SHOULD have SPF records of both RR
551 types. A compliant domain name MUST have a record of at least one
552 type. If a domain has records of both types, they MUST have
553 identical content. For example, instead of publishing just one
554 record as in Section 3.1 above, it is better to publish:
556 example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all"
557 example.com. IN SPF "v=spf1 +mx a:colo.example.com/28 -all"
562 Wong & Schlitt Experimental [Page 10]
564 RFC 4408 Sender Policy Framework (SPF) April 2006
567 Example RRs in this document are shown with the TXT record type;
568 however, they could be published with the SPF type or with both
571 3.1.2. Multiple DNS Records
573 A domain name MUST NOT have multiple records that would cause an
574 authorization check to select more than one record. See Section 4.5
575 for the selection rules.
577 3.1.3. Multiple Strings in a Single DNS record
579 As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS
580 record (either TXT or SPF RR types) can be composed of more than one
581 string. If a published record contains multiple strings, then the
582 record MUST be treated as if those strings are concatenated together
583 without adding spaces. For example:
585 IN TXT "v=spf1 .... first" "second string..."
587 MUST be treated as equivalent to
589 IN TXT "v=spf1 .... firstsecond string..."
591 SPF or TXT records containing multiple strings are useful in
592 constructing records that would exceed the 255-byte maximum length of
593 a string within a single TXT or SPF RR record.
597 The published SPF record for a given domain name SHOULD remain small
598 enough that the results of a query for it will fit within 512 octets.
599 This will keep even older DNS implementations from falling over to
600 TCP. Since the answer size is dependent on many things outside the
601 scope of this document, it is only possible to give this guideline:
602 If the combined length of the DNS name and the text of all the
603 records of a given type (TXT or SPF) is under 450 characters, then
604 DNS answers should fit in UDP packets. Note that when computing the
605 sizes for queries of the TXT format, one must take into account any
606 other TXT records published at the domain name. Records that are too
607 long to fit in a single UDP packet MAY be silently ignored by SPF
610 3.1.5. Wildcard Records
612 Use of wildcard records for publishing is not recommended. Care must
613 be taken if wildcard records are used. If a domain publishes
614 wildcard MX records, it may want to publish wildcard declarations,
618 Wong & Schlitt Experimental [Page 11]
620 RFC 4408 Sender Policy Framework (SPF) April 2006
623 subject to the same requirements and problems. In particular, the
624 declaration must be repeated for any host that has any RR records at
625 all, and for subdomains thereof. For example, the example given in
626 [RFC1034], Section 4.3.3, could be extended with the following:
629 X.COM. TXT "v=spf1 a:A.X.COM -all"
631 *.X.COM. MX 10 A.X.COM
632 *.X.COM. TXT "v=spf1 a:A.X.COM -all"
635 A.X.COM. MX 10 A.X.COM
636 A.X.COM. TXT "v=spf1 a:A.X.COM -all"
638 *.A.X.COM. MX 10 A.X.COM
639 *.A.X.COM. TXT "v=spf1 a:A.X.COM -all"
641 Notice that SPF records must be repeated twice for every name within
642 the domain: once for the name, and once with a wildcard to cover the
645 Use of wildcards is discouraged in general as they cause every name
646 under the domain to exist and queries against arbitrary names will
647 never return RCODE 3 (Name Error).
649 4. The check_host() Function
651 The check_host() function fetches SPF records, parses them, and
652 interprets them to determine whether a particular host is or is not
653 permitted to send mail with a given identity. Mail receivers that
654 perform this check MUST correctly evaluate the check_host() function
657 Implementations MAY use a different algorithm than the canonical
658 algorithm defined here, so long as the results are the same in all
663 The check_host() function takes these arguments:
665 <ip> - the IP address of the SMTP client that is emitting the
666 mail, either IPv4 or IPv6.
668 <domain> - the domain that provides the sought-after authorization
669 information; initially, the domain portion of the "MAIL
670 FROM" or "HELO" identity.
674 Wong & Schlitt Experimental [Page 12]
676 RFC 4408 Sender Policy Framework (SPF) April 2006
679 <sender> - the "MAIL FROM" or "HELO" identity.
681 The domain portion of <sender> will usually be the same as the
682 <domain> argument when check_host() is initially evaluated. However,
683 this will generally not be true for recursive evaluations (see
686 Actual implementations of the check_host() function may need
687 additional arguments.
691 The function check_host() can return one of several results described
692 in Section 2.5. Based on the result, the action to be taken is
693 determined by the local policies of the receiver.
695 4.3. Initial Processing
697 If the <domain> is malformed (label longer than 63 characters, zero-
698 length label not at the end, etc.) or is not a fully qualified domain
699 name, or if the DNS lookup returns "domain does not exist" (RCODE 3),
700 check_host() immediately returns the result "None".
702 If the <sender> has no localpart, substitute the string "postmaster"
707 In accordance with how the records are published (see Section 3.1
708 above), a DNS query needs to be made for the <domain> name, querying
709 for either RR type TXT, SPF, or both. If both SPF and TXT RRs are
710 looked up, the queries MAY be done in parallel.
712 If all DNS lookups that are made return a server failure (RCODE 2),
713 or other error (RCODE other than 0 or 3), or time out, then
714 check_host() exits immediately with the result "TempError".
716 4.5. Selecting Records
718 Records begin with a version section:
720 record = version terms *SP
723 Starting with the set of records that were returned by the lookup,
724 record selection proceeds in two steps:
730 Wong & Schlitt Experimental [Page 13]
732 RFC 4408 Sender Policy Framework (SPF) April 2006
735 1. Records that do not begin with a version section of exactly
736 "v=spf1" are discarded. Note that the version section is
737 terminated either by an SP character or the end of the record. A
738 record with a version section of "v=spf10" does not match and must
741 2. If any records of type SPF are in the set, then all records of
742 type TXT are discarded.
744 After the above steps, there should be exactly one record remaining
745 and evaluation can proceed. If there are two or more records
746 remaining, then check_host() exits immediately with the result of
749 If no matching records are returned, an SPF client MUST assume that
750 the domain makes no SPF declarations. SPF processing MUST stop and
753 4.6. Record Evaluation
755 After one SPF record has been selected, the check_host() function
756 parses and interprets it to find a result for the current test. If
757 there are any syntax errors, check_host() returns immediately with
758 the result "PermError".
760 Implementations MAY choose to parse the entire record first and
761 return "PermError" if the record is not syntactically well formed.
762 However, in all cases, any syntax errors anywhere in the record MUST
765 4.6.1. Term Evaluation
767 There are two types of terms: mechanisms and modifiers. A record
768 contains an ordered list of these as specified in the following
769 Augmented Backus-Naur Form (ABNF).
771 terms = *( 1*SP ( directive / modifier ) )
773 directive = [ qualifier ] mechanism
774 qualifier = "+" / "-" / "?" / "~"
775 mechanism = ( all / include
776 / A / MX / PTR / IP4 / IP6 / exists )
777 modifier = redirect / explanation / unknown-modifier
778 unknown-modifier = name "=" macro-string
780 name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
782 Most mechanisms allow a ":" or "/" character after the name.
786 Wong & Schlitt Experimental [Page 14]
788 RFC 4408 Sender Policy Framework (SPF) April 2006
791 Modifiers always contain an equals ('=') character immediately after
792 the name, and before any ":" or "/" characters that may be part of
795 Terms that do not contain any of "=", ":", or "/" are mechanisms, as
796 defined in Section 5.
798 As per the definition of the ABNF notation in [RFC4234], mechanism
799 and modifier names are case-insensitive.
803 Each mechanism is considered in turn from left to right. If there
804 are no more mechanisms, the result is specified in Section 4.7.
806 When a mechanism is evaluated, one of three things can happen: it can
807 match, not match, or throw an exception.
809 If it matches, processing ends and the qualifier value is returned as
810 the result of that record. If it does not match, processing
811 continues with the next mechanism. If it throws an exception,
812 mechanism processing ends and the exception value is returned.
814 The possible qualifiers, and the results they return are as follows:
821 The qualifier is optional and defaults to "+".
823 When a mechanism matches and the qualifier is "-", then a "Fail"
824 result is returned and the explanation string is computed as
825 described in Section 6.2.
827 The specific mechanisms are described in Section 5.
831 Modifiers are not mechanisms: they do not return match or not-match.
832 Instead they provide additional information. Although modifiers do
833 not directly affect the evaluation of the record, the "redirect"
834 modifier has an effect after all the mechanisms have been evaluated.
842 Wong & Schlitt Experimental [Page 15]
844 RFC 4408 Sender Policy Framework (SPF) April 2006
849 If none of the mechanisms match and there is no "redirect" modifier,
850 then the check_host() returns a result of "Neutral", just as if
851 "?all" were specified as the last directive. If there is a
852 "redirect" modifier, check_host() proceeds as defined in Section 6.1.
854 Note that records SHOULD always use either a "redirect" modifier or
855 an "all" mechanism to explicitly terminate processing.
861 v=spf1 +mx redirect=_spf.example.com
863 4.8. Domain Specification
865 Several of these mechanisms and modifiers have a <domain-spec>
866 section. The <domain-spec> string is macro expanded (see Section 8).
867 The resulting string is the common presentation form of a fully-
868 qualified DNS name: a series of labels separated by periods. This
869 domain is called the <target-name> in the rest of this document.
871 Note: The result of the macro expansion is not subject to any further
872 escaping. Hence, this facility cannot produce all characters that
873 are legal in a DNS label (e.g., the control characters). However,
874 this facility is powerful enough to express legal host names and
875 common utility labels (such as "_spf") that are used in DNS.
877 For several mechanisms, the <domain-spec> is optional. If it is not
878 provided, the <domain> is used as the <target-name>.
880 5. Mechanism Definitions
882 This section defines two types of mechanisms.
884 Basic mechanisms contribute to the language framework. They do not
885 specify a particular type of authorization scheme.
890 Designated sender mechanisms are used to designate a set of <ip>
891 addresses as being permitted or not permitted to use the <domain> for
898 Wong & Schlitt Experimental [Page 16]
900 RFC 4408 Sender Policy Framework (SPF) April 2006
910 The following conventions apply to all mechanisms that perform a
911 comparison between <ip> and an IP address at any point:
913 If no CIDR-length is given in the directive, then <ip> and the IP
914 address are compared for equality. (Here, CIDR is Classless Inter-
917 If a CIDR-length is specified, then only the specified number of
918 high-order bits of <ip> and the IP address are compared for equality.
920 When any mechanism fetches host addresses to compare with <ip>, when
921 <ip> is an IPv4 address, A records are fetched, when <ip> is an IPv6
922 address, AAAA records are fetched. Even if the SMTP connection is
923 via IPv6, an IPv4-mapped IPv6 IP address (see [RFC3513], Section
924 2.5.5) MUST still be considered an IPv4 address.
926 Several mechanisms rely on information fetched from DNS. For these
927 DNS queries, except where noted, if the DNS server returns an error
928 (RCODE other than 0 or 3) or the query times out, the mechanism
929 throws the exception "TempError". If the server returns "domain does
930 not exist" (RCODE 3), then evaluation of the mechanism continues as
931 if the server returned no error (RCODE 0) and zero answer records.
937 The "all" mechanism is a test that always matches. It is used as the
938 rightmost mechanism in a record to provide an explicit default.
944 Mechanisms after "all" will never be tested. Any "redirect" modifier
945 (Section 6.1) has no effect when there is an "all" mechanism.
954 Wong & Schlitt Experimental [Page 17]
956 RFC 4408 Sender Policy Framework (SPF) April 2006
961 include = "include" ":" domain-spec
963 The "include" mechanism triggers a recursive evaluation of
964 check_host(). The domain-spec is expanded as per Section 8. Then
965 check_host() is evaluated with the resulting string as the <domain>.
966 The <ip> and <sender> arguments remain the same as in the current
967 evaluation of check_host().
969 In hindsight, the name "include" was poorly chosen. Only the
970 evaluated result of the referenced SPF record is used, rather than
971 acting as if the referenced SPF record was literally included in the
972 first. For example, evaluating a "-all" directive in the referenced
973 record does not terminate the overall processing and does not
974 necessarily result in an overall "Fail". (Better names for this
975 mechanism would have been "if-pass", "on-pass", etc.)
977 The "include" mechanism makes it possible for one domain to designate
978 multiple administratively-independent domains. For example, a vanity
979 domain "example.net" might send mail using the servers of
980 administratively-independent domains example.com and example.org.
982 Example.net could say
984 IN TXT "v=spf1 include:example.com include:example.org -all"
986 This would direct check_host() to, in effect, check the records of
987 example.com and example.org for a "Pass" result. Only if the host
988 were not permitted for either of those domains would the result be
1010 Wong & Schlitt Experimental [Page 18]
1012 RFC 4408 Sender Policy Framework (SPF) April 2006
1015 Whether this mechanism matches, does not match, or throws an
1016 exception depends on the result of the recursive evaluation of
1019 +---------------------------------+---------------------------------+
1020 | A recursive check_host() result | Causes the "include" mechanism |
1022 +---------------------------------+---------------------------------+
1025 | Fail | not match |
1027 | SoftFail | not match |
1029 | Neutral | not match |
1031 | TempError | throw TempError |
1033 | PermError | throw PermError |
1035 | None | throw PermError |
1036 +---------------------------------+---------------------------------+
1038 The "include" mechanism is intended for crossing administrative
1039 boundaries. Although it is possible to use includes to consolidate
1040 multiple domains that share the same set of designated hosts, domains
1041 are encouraged to use redirects where possible, and to minimize the
1042 number of includes within a single administrative domain. For
1043 example, if example.com and example.org were managed by the same
1044 entity, and if the permitted set of hosts for both domains was
1045 "mx:example.com", it would be possible for example.org to specify
1046 "include:example.com", but it would be preferable to specify
1047 "redirect=example.com" or even "mx:example.com".
1051 This mechanism matches if <ip> is one of the <target-name>'s IP
1054 A = "a" [ ":" domain-spec ] [ dual-cidr-length ]
1056 An address lookup is done on the <target-name>. The <ip> is compared
1057 to the returned address(es). If any address matches, the mechanism
1066 Wong & Schlitt Experimental [Page 19]
1068 RFC 4408 Sender Policy Framework (SPF) April 2006
1073 This mechanism matches if <ip> is one of the MX hosts for a domain
1076 MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ]
1078 check_host() first performs an MX lookup on the <target-name>. Then
1079 it performs an address lookup on each MX name returned. The <ip> is
1080 compared to each returned IP address. To prevent Denial of Service
1081 (DoS) attacks, more than 10 MX names MUST NOT be looked up during the
1082 evaluation of an "mx" mechanism (see Section 10). If any address
1083 matches, the mechanism matches.
1085 Note regarding implicit MXs: If the <target-name> has no MX records,
1086 check_host() MUST NOT pretend the target is its single MX, and MUST
1087 NOT default to an A lookup on the <target-name> directly. This
1088 behavior breaks with the legacy "implicit MX" rule. See [RFC2821],
1089 Section 5. If such behavior is desired, the publisher should specify
1094 This mechanism tests whether the DNS reverse-mapping for <ip> exists
1095 and correctly points to a domain name within a particular domain.
1097 PTR = "ptr" [ ":" domain-spec ]
1099 First, the <ip>'s name is looked up using this procedure: perform a
1100 DNS reverse-mapping for <ip>, looking up the corresponding PTR record
1101 in "in-addr.arpa." if the address is an IPv4 one and in "ip6.arpa."
1102 if it is an IPv6 address. For each record returned, validate the
1103 domain name by looking up its IP address. To prevent DoS attacks,
1104 more than 10 PTR names MUST NOT be looked up during the evaluation of
1105 a "ptr" mechanism (see Section 10). If <ip> is among the returned IP
1106 addresses, then that domain name is validated. In pseudocode:
1108 sending-domain_names := ptr_lookup(sending-host_IP); if more than 10
1109 sending-domain_names are found, use at most 10. for each name in
1110 (sending-domain_names) {
1111 IP_addresses := a_lookup(name);
1112 if the sending-domain_IP is one of the IP_addresses {
1113 validated-sending-domain_names += name;
1116 Check all validated domain names to see if they end in the
1117 <target-name> domain. If any do, this mechanism matches. If no
1118 validated domain name can be found, or if none of the validated
1122 Wong & Schlitt Experimental [Page 20]
1124 RFC 4408 Sender Policy Framework (SPF) April 2006
1127 domain names end in the <target-name>, this mechanism fails to match.
1128 If a DNS error occurs while doing the PTR RR lookup, then this
1129 mechanism fails to match. If a DNS error occurs while doing an A RR
1130 lookup, then that domain name is skipped and the search continues.
1134 for each name in (validated-sending-domain_names) {
1135 if name ends in <domain-spec>, return match.
1136 if name is <domain-spec>, return match.
1140 This mechanism matches if the <target-name> is either an ancestor of
1141 a validated domain name or if the <target-name> and a validated
1142 domain name are the same. For example: "mail.example.com" is within
1143 the domain "example.com", but "mail.bad-example.com" is not.
1145 Note: Use of this mechanism is discouraged because it is slow, it is
1146 not as reliable as other mechanisms in cases of DNS errors, and it
1147 places a large burden on the arpa name servers. If used, proper PTR
1148 records must be in place for the domain's hosts and the "ptr"
1149 mechanism should be one of the last mechanisms checked.
1151 5.6. "ip4" and "ip6"
1153 These mechanisms test whether <ip> is contained within a given IP
1156 IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
1157 IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ]
1159 ip4-cidr-length = "/" 1*DIGIT
1160 ip6-cidr-length = "/" 1*DIGIT
1161 dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
1163 ip4-network = qnum "." qnum "." qnum "." qnum
1165 / %x31-39 DIGIT ; 10-99
1166 / "1" 2DIGIT ; 100-199
1167 / "2" %x30-34 DIGIT ; 200-249
1168 / "25" %x30-35 ; 250-255
1169 ; as per conventional dotted quad notation. e.g., 192.0.2.0
1170 ip6-network = <as per [RFC 3513], section 2.2>
1171 ; e.g., 2001:DB8::CD30
1173 The <ip> is compared to the given network. If CIDR-length high-order
1174 bits match, the mechanism matches.
1178 Wong & Schlitt Experimental [Page 21]
1180 RFC 4408 Sender Policy Framework (SPF) April 2006
1183 If ip4-cidr-length is omitted, it is taken to be "/32". If
1184 ip6-cidr-length is omitted, it is taken to be "/128". It is not
1185 permitted to omit parts of the IP address instead of using CIDR
1186 notations. That is, use 192.0.2.0/24 instead of 192.0.2.
1190 This mechanism is used to construct an arbitrary domain name that is
1191 used for a DNS A record query. It allows for complicated schemes
1192 involving arbitrary parts of the mail envelope to determine what is
1195 exists = "exists" ":" domain-spec
1197 The domain-spec is expanded as per Section 8. The resulting domain
1198 name is used for a DNS A RR lookup. If any A record is returned,
1199 this mechanism matches. The lookup type is A even when the
1200 connection type is IPv6.
1202 Domains can use this mechanism to specify arbitrarily complex
1203 queries. For example, suppose example.com publishes the record:
1205 v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all
1207 The <target-name> might expand to
1208 "1.2.0.192.someuser._spf.example.com". This makes fine-grained
1209 decisions possible at the level of the user and client IP address.
1211 This mechanism enables queries that mimic the style of tests that
1212 existing anti-spam DNS blacklists (DNSBL) use.
1214 6. Modifier Definitions
1216 Modifiers are name/value pairs that provide additional information.
1217 Modifiers always have an "=" separating the name and the value.
1219 The modifiers defined in this document ("redirect" and "exp") MAY
1220 appear anywhere in the record, but SHOULD appear at the end, after
1221 all mechanisms. Ordering of these two modifiers does not matter.
1222 These two modifiers MUST NOT appear in a record more than once each.
1223 If they do, then check_host() exits with a result of "PermError".
1225 Unrecognized modifiers MUST be ignored no matter where in a record,
1226 or how often. This allows implementations of this document to
1227 gracefully handle records with modifiers that are defined in other
1234 Wong & Schlitt Experimental [Page 22]
1236 RFC 4408 Sender Policy Framework (SPF) April 2006
1239 6.1. redirect: Redirected Query
1241 If all mechanisms fail to match, and a "redirect" modifier is
1242 present, then processing proceeds as follows:
1244 redirect = "redirect" "=" domain-spec
1246 The domain-spec portion of the redirect section is expanded as per
1247 the macro rules in Section 8. Then check_host() is evaluated with
1248 the resulting string as the <domain>. The <ip> and <sender>
1249 arguments remain the same as current evaluation of check_host().
1251 The result of this new evaluation of check_host() is then considered
1252 the result of the current evaluation with the exception that if no
1253 SPF record is found, or if the target-name is malformed, the result
1254 is a "PermError" rather than "None".
1256 Note that the newly-queried domain may itself specify redirect
1259 This facility is intended for use by organizations that wish to apply
1260 the same record to multiple domains. For example:
1262 la.example.com. TXT "v=spf1 redirect=_spf.example.com"
1263 ny.example.com. TXT "v=spf1 redirect=_spf.example.com"
1264 sf.example.com. TXT "v=spf1 redirect=_spf.example.com"
1265 _spf.example.com. TXT "v=spf1 mx:example.com -all"
1267 In this example, mail from any of the three domains is described by
1268 the same record. This can be an administrative advantage.
1270 Note: In general, the domain "A" cannot reliably use a redirect to
1271 another domain "B" not under the same administrative control. Since
1272 the <sender> stays the same, there is no guarantee that the record at
1273 domain "B" will correctly work for mailboxes in domain "A",
1274 especially if domain "B" uses mechanisms involving localparts. An
1275 "include" directive may be more appropriate.
1277 For clarity, it is RECOMMENDED that any "redirect" modifier appear as
1278 the very last term in a record.
1280 6.2. exp: Explanation
1282 explanation = "exp" "=" domain-spec
1284 If check_host() results in a "Fail" due to a mechanism match (such as
1285 "-all"), and the "exp" modifier is present, then the explanation
1286 string returned is computed as described below. If no "exp" modifier
1290 Wong & Schlitt Experimental [Page 23]
1292 RFC 4408 Sender Policy Framework (SPF) April 2006
1295 is present, then either a default explanation string or an empty
1296 explanation string may be returned.
1298 The <domain-spec> is macro expanded (see Section 8) and becomes the
1299 <target-name>. The DNS TXT record for the <target-name> is fetched.
1301 If <domain-spec> is empty, or there are any DNS processing errors
1302 (any RCODE other than 0), or if no records are returned, or if more
1303 than one record is returned, or if there are syntax errors in the
1304 explanation string, then proceed as if no exp modifier was given.
1306 The fetched TXT record's strings are concatenated with no spaces, and
1307 then treated as an <explain-string>, which is macro-expanded. This
1308 final result is the explanation string. Implementations MAY limit
1309 the length of the resulting explanation string to allow for other
1310 protocol constraints and/or reasonable processing limits. Since the
1311 explanation string is intended for an SMTP response and [RFC2821]
1312 Section 2.4 says that responses are in [US-ASCII], the explanation
1313 string is also limited to US-ASCII.
1315 Software evaluating check_host() can use this string to communicate
1316 information from the publishing domain in the form of a short message
1317 or URL. Software SHOULD make it clear that the explanation string
1318 comes from a third party. For example, it can prepend the macro
1319 string "%{o} explains: " to the explanation, such as shown in Section
1322 Suppose example.com has this record:
1324 v=spf1 mx -all exp=explain._spf.%{d}
1326 Here are some examples of possible explanation TXT records at
1327 explain._spf.example.com:
1329 "Mail from example.com should only be sent by its own servers."
1330 -- a simple, constant message
1332 "%{i} is not one of %{d}'s designated mail servers."
1333 -- a message with a little more information, including the IP
1334 address that failed the check
1336 "See http://%{d}/why.html?s=%{S}&i=%{I}"
1337 -- a complicated example that constructs a URL with the
1338 arguments to check_host() so that a web page can be
1339 generated with detailed, custom instructions
1341 Note: During recursion into an "include" mechanism, an exp= modifier
1342 from the <target-name> MUST NOT be used. In contrast, when executing
1346 Wong & Schlitt Experimental [Page 24]
1348 RFC 4408 Sender Policy Framework (SPF) April 2006
1351 a "redirect" modifier, an exp= modifier from the original domain MUST
1354 7. The Received-SPF Header Field
1356 It is RECOMMENDED that SMTP receivers record the result of SPF
1357 processing in the message header. If an SMTP receiver chooses to do
1358 so, it SHOULD use the "Received-SPF" header field defined here for
1359 each identity that was checked. This information is intended for the
1360 recipient. (Information intended for the sender is described in
1361 Section 6.2, Explanation.)
1363 The Received-SPF header field is a trace field (see [RFC2822] Section
1364 3.6.7) and SHOULD be prepended to the existing header, above the
1365 Received: field that is generated by the SMTP receiver. It MUST
1366 appear above all other Received-SPF fields in the message. The
1367 header field has the following format:
1369 header-field = "Received-SPF:" [CFWS] result FWS [comment FWS]
1370 [ key-value-list ] CRLF
1372 result = "Pass" / "Fail" / "SoftFail" / "Neutral" /
1373 "None" / "TempError" / "PermError"
1375 key-value-list = key-value-pair *( ";" [CFWS] key-value-pair )
1378 key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string )
1380 key = "client-ip" / "envelope-from" / "helo" /
1381 "problem" / "receiver" / "identity" /
1382 mechanism / "x-" name / name
1384 identity = "mailfrom" ; for the "MAIL FROM" identity
1385 / "helo" ; for the "HELO" identity
1386 / name ; other identities
1388 dot-atom = <unquoted word as per [RFC2822]>
1389 quoted-string = <quoted string as per [RFC2822]>
1390 comment = <comment string as per [RFC2822]>
1391 CFWS = <comment or folding white space as per [RFC2822]>
1392 FWS = <folding white space as per [RFC2822]>
1393 CRLF = <standard end-of-line token as per [RFC2822]>
1395 The header field SHOULD include a "(...)" style <comment> after the
1396 result, conveying supporting information for the result, such as
1397 <ip>, <sender>, and <domain>.
1402 Wong & Schlitt Experimental [Page 25]
1404 RFC 4408 Sender Policy Framework (SPF) April 2006
1407 The following key-value pairs are designed for later machine parsing.
1408 SPF clients SHOULD give enough information so that the SPF results
1409 can be verified. That is, at least "client-ip", "helo", and, if the
1410 "MAIL FROM" identity was checked, "envelope-from".
1412 client-ip the IP address of the SMTP client
1414 envelope-from the envelope sender mailbox
1416 helo the host name given in the HELO or EHLO command
1418 mechanism the mechanism that matched (if no mechanisms matched,
1419 substitute the word "default")
1421 problem if an error was returned, details about the error
1423 receiver the host name of the SPF client
1425 identity the identity that was checked; see the <identity> ABNF
1428 Other keys may be defined by SPF clients. Until a new key name
1429 becomes widely accepted, new key names should start with "x-".
1431 SPF clients MUST make sure that the Received-SPF header field does
1432 not contain invalid characters, is not excessively long, and does not
1433 contain malicious data that has been provided by the sender.
1435 Examples of various header styles that could be generated are the
1438 Received-SPF: Pass (mybox.example.org: domain of
1439 myname@example.com designates 192.0.2.1 as permitted sender)
1440 receiver=mybox.example.org; client-ip=192.0.2.1;
1441 envelope-from=<myname@example.com>; helo=foo.example.com;
1443 Received-SPF: Fail (mybox.example.org: domain of
1444 myname@example.com does not designate
1445 192.0.2.1 as permitted sender)
1446 identity=mailfrom; client-ip=192.0.2.1;
1447 envelope-from=<myname@example.com>;
1458 Wong & Schlitt Experimental [Page 26]
1460 RFC 4408 Sender Policy Framework (SPF) April 2006
1465 8.1. Macro Definitions
1467 Many mechanisms and modifiers perform macro expansion on part of the
1470 domain-spec = macro-string domain-end
1471 domain-end = ( "." toplabel [ "." ] ) / macro-expand
1473 toplabel = ( *alphanum ALPHA *alphanum ) /
1474 ( 1*alphanum "-" *( alphanum / "-" ) alphanum )
1475 ; LDH rule plus additional TLD restrictions
1476 ; (see [RFC3696], Section 2)
1477 alphanum = ALPHA / DIGIT
1479 explain-string = *( macro-string / SP )
1481 macro-string = *( macro-expand / macro-literal )
1482 macro-expand = ( "%{" macro-letter transformers *delimiter "}" )
1483 / "%%" / "%_" / "%-"
1484 macro-literal = %x21-24 / %x26-7E
1485 ; visible characters except "%"
1486 macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
1488 transformers = *DIGIT [ "r" ]
1489 delimiter = "." / "-" / "+" / "," / "/" / "_" / "="
1491 A literal "%" is expressed by "%%".
1493 "%_" expands to a single " " space.
1494 "%-" expands to a URL-encoded space, viz., "%20".
1496 The following macro letters are expanded in term arguments:
1499 l = local-part of <sender>
1500 o = domain of <sender>
1503 p = the validated domain name of <ip>
1504 v = the string "in-addr" if <ip> is ipv4, or "ip6" if <ip> is ipv6
1505 h = HELO/EHLO domain
1514 Wong & Schlitt Experimental [Page 27]
1516 RFC 4408 Sender Policy Framework (SPF) April 2006
1519 The following macro letters are allowed only in "exp" text:
1521 c = SMTP client IP (easily readable format)
1522 r = domain name of host performing the check
1523 t = current timestamp
1525 A '%' character not followed by a '{', '%', '-', or '_' character is
1528 -exists:%(ir).sbl.spamhaus.example.org
1530 is incorrect and will cause check_host() to return a "PermError".
1533 -exists:%{ir}.sbl.spamhaus.example.org
1535 Optional transformers are the following:
1537 *DIGIT = zero or more digits
1538 'r' = reverse value, splitting on dots by default
1540 If transformers or delimiters are provided, the replacement value for
1541 a macro letter is split into parts. After performing any reversal
1542 operation and/or removal of left-hand parts, the parts are rejoined
1543 using "." and not the original splitting characters.
1545 By default, strings are split on "." (dots). Note that no special
1546 treatment is given to leading, trailing, or consecutive delimiters,
1547 and so the list of parts may contain empty strings. Older
1548 implementations of SPF prohibit trailing dots in domain names, so
1549 trailing dots should not be published by domain owners, although they
1550 must be accepted by implementations conforming to this document.
1551 Macros may specify delimiter characters that are used instead of ".".
1553 The 'r' transformer indicates a reversal operation: if the client IP
1554 address were 192.0.2.1, the macro %{i} would expand to "192.0.2.1"
1555 and the macro %{ir} would expand to "1.2.0.192".
1557 The DIGIT transformer indicates the number of right-hand parts to
1558 use, after optional reversal. If a DIGIT is specified, the value
1559 MUST be nonzero. If no DIGITs are specified, or if the value
1560 specifies more parts than are available, all the available parts are
1561 used. If the DIGIT was 5, and only 3 parts were available, the macro
1562 interpreter would pretend the DIGIT was 3. Implementations MUST
1563 support at least a value of 128, as that is the maximum number of
1564 labels in a domain name.
1570 Wong & Schlitt Experimental [Page 28]
1572 RFC 4408 Sender Policy Framework (SPF) April 2006
1575 The "s" macro expands to the <sender> argument. It is an E-Mail
1576 address with a localpart, an "@" character, and a domain. The "l"
1577 macro expands to just the localpart. The "o" macro expands to just
1578 the domain part. Note that these values remain the same during
1579 recursive and chained evaluations due to "include" and/or "redirect".
1580 Note also that if the original <sender> had no localpart, the
1581 localpart was set to "postmaster" in initial processing (see Section
1584 For IPv4 addresses, both the "i" and "c" macros expand to the
1585 standard dotted-quad format.
1587 For IPv6 addresses, the "i" macro expands to a dot-format address; it
1588 is intended for use in %{ir}. The "c" macro may expand to any of the
1589 hexadecimal colon-format addresses specified in [RFC3513], Section
1590 2.2. It is intended for humans to read.
1592 The "p" macro expands to the validated domain name of <ip>. The
1593 procedure for finding the validated domain name is defined in Section
1594 5.5. If the <domain> is present in the list of validated domains, it
1595 SHOULD be used. Otherwise, if a subdomain of the <domain> is
1596 present, it SHOULD be used. Otherwise, any name from the list may be
1597 used. If there are no validated domain names or if a DNS error
1598 occurs, the string "unknown" is used.
1600 The "r" macro expands to the name of the receiving MTA. This SHOULD
1601 be a fully qualified domain name, but if one does not exist (as when
1602 the checking is done by a MUA) or if policy restrictions dictate
1603 otherwise, the word "unknown" SHOULD be substituted. The domain name
1604 may be different from the name found in the MX record that the client
1605 MTA used to locate the receiving MTA.
1607 The "t" macro expands to the decimal representation of the
1608 approximate number of seconds since the Epoch (Midnight, January 1,
1609 1970, UTC). This is the same value as is returned by the POSIX
1610 time() function in most standards-compliant libraries.
1612 When the result of macro expansion is used in a domain name query, if
1613 the expanded domain name exceeds 253 characters (the maximum length
1614 of a domain name), the left side is truncated to fit, by removing
1615 successive domain labels until the total length does not exceed 253
1618 Uppercased macros expand exactly as their lowercased equivalents, and
1619 are then URL escaped. URL escaping must be performed for characters
1620 not in the "uric" set, which is defined in [RFC3986].
1626 Wong & Schlitt Experimental [Page 29]
1628 RFC 4408 Sender Policy Framework (SPF) April 2006
1631 Note: Care must be taken so that macro expansion for legitimate
1632 E-Mail does not exceed the 63-character limit on DNS labels. The
1633 localpart of E-Mail addresses, in particular, can have more than 63
1634 characters between dots.
1636 Note: Domains should avoid using the "s", "l", "o", or "h" macros in
1637 conjunction with any mechanism directive. Although these macros are
1638 powerful and allow per-user records to be published, they severely
1639 limit the ability of implementations to cache results of check_host()
1640 and they reduce the effectiveness of DNS caches.
1642 Implementations should be aware that if no directive processed during
1643 the evaluation of check_host() contains an "s", "l", "o", or "h"
1644 macro, then the results of the evaluation can be cached on the basis
1645 of <domain> and <ip> alone for as long as the shortest Time To Live
1646 (TTL) of all the DNS records involved.
1648 8.2. Expansion Examples
1650 The <sender> is strong-bad@email.example.com.
1651 The IPv4 SMTP client IP is 192.0.2.3.
1652 The IPv6 SMTP client IP is 2001:DB8::CB01.
1653 The PTR domain name of the client IP is mx.example.org.
1656 ------- ----------------------------
1657 %{s} strong-bad@email.example.com
1658 %{o} email.example.com
1659 %{d} email.example.com
1660 %{d4} email.example.com
1661 %{d3} email.example.com
1664 %{dr} com.example.email
1665 %{d2r} example.email
1682 Wong & Schlitt Experimental [Page 30]
1684 RFC 4408 Sender Policy Framework (SPF) April 2006
1687 macro-string expansion
1688 --------------------------------------------------------------------
1689 %{ir}.%{v}._spf.%{d2} 3.2.0.192.in-addr._spf.example.com
1690 %{lr-}.lp._spf.%{d2} bad.strong.lp._spf.example.com
1692 %{lr-}.lp.%{ir}.%{v}._spf.%{d2}
1693 bad.strong.lp.3.2.0.192.in-addr._spf.example.com
1695 %{ir}.%{v}.%{l1r-}.lp._spf.%{d2}
1696 3.2.0.192.in-addr.strong.lp._spf.example.com
1698 %{d2}.trusted-domains.example.net
1699 example.com.trusted-domains.example.net
1702 %{ir}.%{v}._spf.%{d2} 1.0.B.C.0.0.0.0.
1703 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
1707 This section outlines the major implications that adoption of this
1708 document will have on various entities involved in Internet E-Mail.
1709 It is intended to make clear to the reader where this document
1710 knowingly affects the operation of such entities. This section is
1711 not a "how-to" manual, or a "best practices" document, and it is not
1712 a comprehensive list of what such entities should do in light of this
1715 This section is non-normative.
1717 9.1. Sending Domains
1719 Domains that wish to be compliant with this specification will need
1720 to determine the list of hosts that they allow to use their domain
1721 name in the "HELO" and "MAIL FROM" identities. It is recognized that
1722 forming such a list is not just a simple technical exercise, but
1723 involves policy decisions with both technical and administrative
1726 It can be helpful to publish records that include a "tracking
1727 exists:" mechanism. By looking at the name server logs, a rough list
1728 may then be generated. For example:
1730 v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all
1738 Wong & Schlitt Experimental [Page 31]
1740 RFC 4408 Sender Policy Framework (SPF) April 2006
1745 Mailing lists must be aware of how they re-inject mail that is sent
1746 to the list. Mailing lists MUST comply with the requirements in
1747 [RFC2821], Section 3.10, and [RFC1123], Section 5.3.6, that say that
1748 the reverse-path MUST be changed to be the mailbox of a person or
1749 other entity who administers the list. Whereas the reasons for
1750 changing the reverse-path are many and long-standing, SPF adds
1751 enforcement to this requirement.
1753 In practice, almost all mailing list software in use already complies
1754 with this requirement. Mailing lists that do not comply may or may
1755 not encounter problems depending on how access to the list is
1756 restricted. Such lists that are entirely internal to a domain (only
1757 people in the domain can send to or receive from the list) are not
1760 9.3. Forwarding Services and Aliases
1762 Forwarding services take mail that is received at a mailbox and
1763 direct it to some external mailbox. At the time of this writing, the
1764 near-universal practice of such services is to use the original "MAIL
1765 FROM" of a message when re-injecting it for delivery to the external
1766 mailbox. [RFC1123] and [RFC2821] describe this action as an "alias"
1767 rather than a "mail list". This means that the external mailbox's
1768 MTA sees all such mail in a connection from a host of the forwarding
1769 service, and so the "MAIL FROM" identity will not, in general, pass
1772 There are three places that techniques can be used to ameliorate this
1775 1. The beginning, when E-Mail is first sent.
1777 1. "Neutral" results could be given for IP addresses that may be
1778 forwarders, instead of "Fail" results. For example:
1780 "v=spf1 mx -exists:%{ir}.sbl.spamhaus.example.org ?all"
1782 This would cause a lookup on an anti-spam DNS blacklist
1783 (DNSBL) and cause a result of "Fail" only for E-Mail coming
1784 from listed sources. All other E-Mail, including E-Mail sent
1785 through forwarders, would receive a "Neutral" result. By
1786 checking the DNSBL after the known good sources, problems with
1787 incorrect listing on the DNSBL are greatly reduced.
1794 Wong & Schlitt Experimental [Page 32]
1796 RFC 4408 Sender Policy Framework (SPF) April 2006
1799 2. The "MAIL FROM" identity could have additional information in
1800 the localpart that cryptographically identifies the mail as
1801 coming from an authorized source. In this case, such an SPF
1802 record could be used:
1804 "v=spf1 mx exists:%{l}._spf_verify.%{d} -all"
1806 Then, a specialized DNS server can be set up to serve the
1807 _spf_verify subdomain that validates the localpart. Although
1808 this requires an extra DNS lookup, this happens only when the
1809 E-Mail would otherwise be rejected as not coming from a known
1812 Note that due to the 63-character limit for domain labels,
1813 this approach only works reliably if the localpart signature
1814 scheme is guaranteed either to only produce localparts with a
1815 maximum of 63 characters or to gracefully handle truncated
1818 3. Similarly, a specialized DNS server could be set up that will
1819 rate-limit the E-Mail coming from unexpected IP addresses.
1821 "v=spf1 mx exists:%{ir}._spf_rate.%{d} -all"
1823 4. SPF allows the creation of per-user policies for special
1824 cases. For example, the following SPF record and appropriate
1825 wildcard DNS records can be used:
1827 "v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}"
1829 2. The middle, when E-Mail is forwarded.
1831 1. Forwarding services can solve the problem by rewriting the
1832 "MAIL FROM" to be in their own domain. This means that mail
1833 bounced from the external mailbox will have to be re-bounced
1834 by the forwarding service. Various schemes to do this exist
1835 though they vary widely in complexity and resource
1836 requirements on the part of the forwarding service.
1838 2. Several popular MTAs can be forced from "alias" semantics to
1839 "mailing list" semantics by configuring an additional alias
1840 with "owner-" prepended to the original alias name (e.g., an
1841 alias of "friends: george@example.com, fred@example.org" would
1842 need another alias of the form "owner-friends: localowner").
1850 Wong & Schlitt Experimental [Page 33]
1852 RFC 4408 Sender Policy Framework (SPF) April 2006
1855 3. The end, when E-Mail is received.
1857 1. If the owner of the external mailbox wishes to trust the
1858 forwarding service, he can direct the external mailbox's MTA
1859 to skip SPF tests when the client host belongs to the
1862 2. Tests against other identities, such as the "HELO" identity,
1863 may be used to override a failed test against the "MAIL FROM"
1866 3. For larger domains, it may not be possible to have a complete
1867 or accurate list of forwarding services used by the owners of
1868 the domain's mailboxes. In such cases, whitelists of
1869 generally-recognized forwarding services could be employed.
1873 Service providers that offer mail services to third-party domains,
1874 such as sending of bulk mail, may want to adjust their setup in light
1875 of the authorization check described in this document. If the "MAIL
1876 FROM" identity used for such E-Mail uses the domain of the service
1877 provider, then the provider needs only to ensure that its sending
1878 host is authorized by its own SPF record, if any.
1880 If the "MAIL FROM" identity does not use the mail service provider's
1881 domain, then extra care must be taken. The SPF record format has
1882 several options for the third-party domain to authorize the service
1883 provider's MTAs to send mail on its behalf. For mail service
1884 providers, such as ISPs, that have a wide variety of customers using
1885 the same MTA, steps should be taken to prevent cross-customer forgery
1890 The authorization check generally precludes the use of arbitrary MTA
1891 relays between sender and receiver of an E-Mail message.
1893 Within an organization, MTA relays can be effectively deployed.
1894 However, for purposes of this document, such relays are effectively
1895 transparent. The SPF authorization check is a check between border
1896 MTAs of different domains.
1898 For mail senders, this means that published SPF records must
1899 authorize any MTAs that actually send across the Internet. Usually,
1900 these are just the border MTAs as internal MTAs simply forward mail
1901 to these MTAs for delivery.
1906 Wong & Schlitt Experimental [Page 34]
1908 RFC 4408 Sender Policy Framework (SPF) April 2006
1911 Mail receivers will generally want to perform the authorization check
1912 at the border MTAs, specifically including all secondary MXs. This
1913 allows mail that fails to be rejected during the SMTP session rather
1914 than bounced. Internal MTAs then do not perform the authorization
1915 test. To perform the authorization test other than at the border,
1916 the host that first transferred the message to the organization must
1917 be determined, which can be difficult to extract from the message
1918 header. Testing other than at the border is not recommended.
1920 10. Security Considerations
1922 10.1. Processing Limits
1924 As with most aspects of E-Mail, there are a number of ways that
1925 malicious parties could use the protocol as an avenue for a
1926 Denial-of-Service (DoS) attack. The processing limits outlined here
1927 are designed to prevent attacks such as the following:
1929 o A malicious party could create an SPF record with many references
1930 to a victim's domain and send many E-Mails to different SPF
1931 clients; those SPF clients would then create a DoS attack. In
1932 effect, the SPF clients are being used to amplify the attacker's
1933 bandwidth by using fewer bytes in the SMTP session than are used
1934 by the DNS queries. Using SPF clients also allows the attacker to
1935 hide the true source of the attack.
1937 o Whereas implementations of check_host() are supposed to limit the
1938 number of DNS lookups, malicious domains could publish records
1939 that exceed these limits in an attempt to waste computation effort
1940 at their targets when they send them mail. Malicious domains
1941 could also design SPF records that cause particular
1942 implementations to use excessive memory or CPU usage, or to
1945 o Malicious parties could send a large volume of mail purporting to
1946 come from the intended target to a wide variety of legitimate mail
1947 hosts. These legitimate machines would then present a DNS load on
1948 the target as they fetched the relevant records.
1950 Of these, the case of a third party referenced in the SPF record is
1951 the easiest for a DoS attack to effectively exploit. As a result,
1952 limits that may seem reasonable for an individual mail server can
1953 still allow an unreasonable amount of bandwidth amplification.
1954 Therefore, the processing limits need to be quite low.
1956 SPF implementations MUST limit the number of mechanisms and modifiers
1957 that do DNS lookups to at most 10 per SPF check, including any
1958 lookups caused by the use of the "include" mechanism or the
1962 Wong & Schlitt Experimental [Page 35]
1964 RFC 4408 Sender Policy Framework (SPF) April 2006
1967 "redirect" modifier. If this number is exceeded during a check, a
1968 PermError MUST be returned. The "include", "a", "mx", "ptr", and
1969 "exists" mechanisms as well as the "redirect" modifier do count
1970 against this limit. The "all", "ip4", and "ip6" mechanisms do not
1971 require DNS lookups and therefore do not count against this limit.
1972 The "exp" modifier does not count against this limit because the DNS
1973 lookup to fetch the explanation string occurs after the SPF record
1976 When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro,
1977 there MUST be a limit of no more than 10 MX or PTR RRs looked up and
1980 SPF implementations SHOULD limit the total amount of data obtained
1981 from the DNS queries. For example, when DNS over TCP or EDNS0 are
1982 available, there may need to be an explicit limit to how much data
1983 will be accepted to prevent excessive bandwidth usage or memory usage
1986 MTAs or other processors MAY also impose a limit on the maximum
1987 amount of elapsed time to evaluate check_host(). Such a limit SHOULD
1988 allow at least 20 seconds. If such a limit is exceeded, the result
1989 of authorization SHOULD be "TempError".
1991 Domains publishing records SHOULD try to keep the number of "include"
1992 mechanisms and chained "redirect" modifiers to a minimum. Domains
1993 SHOULD also try to minimize the amount of other DNS information
1994 needed to evaluate a record. This can be done by choosing directives
1995 that require less DNS information and placing lower-cost mechanisms
1996 earlier in the SPF record.
1998 For example, consider a domain set up as follows:
2000 example.com. IN MX 10 mx.example.com.
2001 mx.example.com. IN A 192.0.2.1
2002 a.example.com. IN TXT "v=spf1 mx:example.com -all"
2003 b.example.com. IN TXT "v=spf1 a:mx.example.com -all"
2004 c.example.com. IN TXT "v=spf1 ip4:192.0.2.1 -all"
2006 Evaluating check_host() for the domain "a.example.com" requires the
2007 MX records for "example.com", and then the A records for the listed
2008 hosts. Evaluating for "b.example.com" requires only the A records.
2009 Evaluating for "c.example.com" requires none.
2011 However, there may be administrative considerations: using "a" over
2012 "ip4" allows hosts to be renumbered easily. Using "mx" over "a"
2013 allows the set of mail hosts to be changed easily.
2018 Wong & Schlitt Experimental [Page 36]
2020 RFC 4408 Sender Policy Framework (SPF) April 2006
2023 10.2. SPF-Authorized E-Mail May Contain Other False Identities
2025 The "MAIL FROM" and "HELO" identity authorizations must not be
2026 construed to provide more assurance than they do. It is entirely
2027 possible for a malicious sender to inject a message using his own
2028 domain in the identities used by SPF, to have that domain's SPF
2029 record authorize the sending host, and yet the message can easily
2030 list other identities in its header. Unless the user or the MUA
2031 takes care to note that the authorized identity does not match the
2032 other more commonly-presented identities (such as the From: header
2033 field), the user may be lulled into a false sense of security.
2035 10.3. Spoofed DNS and IP Data
2037 There are two aspects of this protocol that malicious parties could
2038 exploit to undermine the validity of the check_host() function:
2040 o The evaluation of check_host() relies heavily on DNS. A malicious
2041 attacker could attack the DNS infrastructure and cause
2042 check_host() to see spoofed DNS data, and then return incorrect
2043 results. This could include returning "Pass" for an <ip> value
2044 where the actual domain's record would evaluate to "Fail". See
2045 [RFC3833] for a description of DNS weaknesses.
2047 o The client IP address, <ip>, is assumed to be correct. A
2048 malicious attacker could spoof TCP sequence numbers to make mail
2049 appear to come from a permitted host for a domain that the
2050 attacker is impersonating.
2052 10.4. Cross-User Forgery
2054 By definition, SPF policies just map domain names to sets of
2055 authorized MTAs, not whole E-Mail addresses to sets of authorized
2056 users. Although the "l" macro (Section 8) provides a limited way to
2057 define individual sets of authorized MTAs for specific E-Mail
2058 addresses, it is generally impossible to verify, through SPF, the use
2059 of specific E-Mail addresses by individual users of the same MTA.
2061 It is up to mail services and their MTAs to directly prevent
2062 cross-user forgery: based on SMTP AUTH ([RFC2554]), users should be
2063 restricted to using only those E-Mail addresses that are actually
2064 under their control (see [RFC4409], Section 6.1). Another means to
2065 verify the identity of individual users is message cryptography such
2066 as PGP ([RFC2440]) or S/MIME ([RFC3851]).
2074 Wong & Schlitt Experimental [Page 37]
2076 RFC 4408 Sender Policy Framework (SPF) April 2006
2079 10.5. Untrusted Information Sources
2081 SPF uses information supplied by third parties, such as the "HELO"
2082 domain name, the "MAIL FROM" address, and SPF records. This
2083 information is then passed to the receiver in the Received-SPF: trace
2084 fields and possibly returned to the client MTA in the form of an SMTP
2085 rejection message. This information must be checked for invalid
2086 characters and excessively long lines.
2088 When the authorization check fails, an explanation string may be
2089 included in the reject response. Both the sender and the rejecting
2090 receiver need to be aware that the explanation was determined by the
2091 publisher of the SPF record checked and, in general, not the
2092 receiver. The explanation may contain malicious URLs, or it may be
2093 offensive or misleading.
2095 This is probably less of a concern than it may initially seem since
2096 such messages are returned to the sender, and the explanation strings
2097 come from the sender policy published by the domain in the identity
2098 claimed by that very sender. As long as the DSN is not redirected to
2099 someone other than the actual sender, the only people who see
2100 malicious explanation strings are people whose messages claim to be
2101 from domains that publish such strings in their SPF records. In
2102 practice, DSNs can be misdirected, such as when an MTA accepts an
2103 E-Mail and then later generates a DSN to a forged address, or when an
2104 E-Mail forwarder does not direct the DSN back to the original sender.
2106 10.6. Privacy Exposure
2108 Checking SPF records causes DNS queries to be sent to the domain
2109 owner. These DNS queries, especially if they are caused by the
2110 "exists" mechanism, can contain information about who is sending
2111 E-Mail and likely to which MTA the E-Mail is being sent. This can
2112 introduce some privacy concerns, which may be more or less of an
2113 issue depending on local laws and the relationship between the domain
2114 owner and the person sending the E-Mail.
2116 11. Contributors and Acknowledgements
2118 This document is largely based on the work of Meng Weng Wong and Mark
2119 Lentczner. Although, as this section acknowledges, many people have
2120 contributed to this document, a very large portion of the writing and
2121 editing are due to Meng and Mark.
2123 This design owes a debt of parentage to [RMX] by Hadmut Danisch and
2124 to [DMP] by Gordon Fecyk. The idea of using a DNS record to check
2125 the legitimacy of an E-Mail address traces its ancestry further back
2126 through messages on the namedroppers mailing list by Paul Vixie
2130 Wong & Schlitt Experimental [Page 38]
2132 RFC 4408 Sender Policy Framework (SPF) April 2006
2135 [Vixie] (based on suggestion by Jim Miller) and by David Green
2138 Philip Gladstone contributed the concept of macros to the
2139 specification, multiplying the expressiveness of the language and
2140 making per-user and per-IP lookups possible.
2142 The authors would also like to thank the literally hundreds of
2143 individuals who have participated in the development of this design.
2144 They are far too numerous to name, but they include the following:
2146 The folks on the spf-discuss mailing list.
2147 The folks on the SPAM-L mailing list.
2148 The folks on the IRTF ASRG mailing list.
2149 The folks on the IETF MARID mailing list.
2152 12. IANA Considerations
2154 12.1. The SPF DNS Record Type
2156 The IANA has assigned a new Resource Record Type and Qtype from the
2157 DNS Parameters Registry for the SPF RR type with code 99.
2159 12.2. The Received-SPF Mail Header Field
2161 Per [RFC3864], the "Received-SPF:" header field is added to the IANA
2162 Permanent Message Header Field Registry. The following is the
2163 registration template:
2165 Header field name: Received-SPF
2166 Applicable protocol: mail ([RFC2822])
2167 Status: Experimental
2168 Author/Change controller: IETF
2169 Specification document(s): RFC 4408
2170 Related information:
2171 Requesting SPF Council review of any proposed changes and
2172 additions to this field are recommended. For information about
2173 the SPF Council see http://www.openspf.org/Council
2177 13.1. Normative References
2179 [RFC1035] Mockapetris, P., "Domain names - implementation and
2180 specification", STD 13, RFC 1035, November 1987.
2186 Wong & Schlitt Experimental [Page 39]
2188 RFC 4408 Sender Policy Framework (SPF) April 2006
2191 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
2192 and Support", STD 3, RFC 1123, October 1989.
2194 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2195 Requirement Levels", BCP 14, RFC 2119, March 1997.
2197 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
2200 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
2203 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format
2204 for Delivery Status Notifications", RFC 3464, January
2207 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
2208 (IPv6) Addressing Architecture", RFC 3513, April 2003.
2210 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
2211 Procedures for Message Header Fields", BCP 90, RFC 3864,
2214 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
2215 Resource Identifier (URI): Generic Syntax", STD 66, RFC
2218 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
2219 Specifications: ABNF", RFC 4234, October 2005.
2221 [US-ASCII] American National Standards Institute (formerly United
2222 States of America Standards Institute), "USA Code for
2223 Information Interchange, X3.4", 1968.
2225 ANSI X3.4-1968 has been replaced by newer versions with slight
2226 modifications, but the 1968 version remains definitive for
2229 13.2 Informative References
2231 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
2232 STD 13, RFC 1034, November 1987.
2234 [RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983, August
2237 [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
2238 "OpenPGP Message Format", RFC 2440, November 1998.
2242 Wong & Schlitt Experimental [Page 40]
2244 RFC 4408 Sender Policy Framework (SPF) April 2006
2247 [RFC2554] Myers, J., "SMTP Service Extension for Authentication",
2248 RFC 2554, March 1999.
2250 [RFC3696] Klensin, J., "Application Techniques for Checking and
2251 Transformation of Names", RFC 3696, February 2004.
2253 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
2254 Name System (DNS)", RFC 3833, August 2004.
2256 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
2257 Extensions (S/MIME) Version 3.1 Message Specification",
2258 RFC 3851, July 2004.
2260 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail",
2261 RFC 4409, April 2006.
2263 [RMX] Danish, H., "The RMX DNS RR Type for light weight sender
2264 authentication", Work In Progress
2266 [DMP] Fecyk, G., "Designated Mailers Protocol", Work In Progress
2268 [Vixie] Vixie, P., "Repudiating MAIL FROM", 2002.
2270 [Green] Green, D., "Domain-Authorized SMTP Mail", 2002.
2298 Wong & Schlitt Experimental [Page 41]
2300 RFC 4408 Sender Policy Framework (SPF) April 2006
2303 Appendix A. Collected ABNF
2305 This section is normative and any discrepancies with the ABNF
2306 fragments in the preceding text are to be resolved in favor of this
2309 See [RFC4234] for ABNF notation. Please note that as per this ABNF
2310 definition, literal text strings (those in quotes) are case-
2311 insensitive. Hence, "mx" matches "mx", "MX", "mX", and "Mx".
2313 record = version terms *SP
2316 terms = *( 1*SP ( directive / modifier ) )
2318 directive = [ qualifier ] mechanism
2319 qualifier = "+" / "-" / "?" / "~"
2320 mechanism = ( all / include
2321 / A / MX / PTR / IP4 / IP6 / exists )
2324 include = "include" ":" domain-spec
2325 A = "a" [ ":" domain-spec ] [ dual-cidr-length ]
2326 MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ]
2327 PTR = "ptr" [ ":" domain-spec ]
2328 IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
2329 IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ]
2330 exists = "exists" ":" domain-spec
2332 modifier = redirect / explanation / unknown-modifier
2333 redirect = "redirect" "=" domain-spec
2334 explanation = "exp" "=" domain-spec
2335 unknown-modifier = name "=" macro-string
2337 ip4-cidr-length = "/" 1*DIGIT
2338 ip6-cidr-length = "/" 1*DIGIT
2339 dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
2341 ip4-network = qnum "." qnum "." qnum "." qnum
2343 / %x31-39 DIGIT ; 10-99
2344 / "1" 2DIGIT ; 100-199
2345 / "2" %x30-34 DIGIT ; 200-249
2346 / "25" %x30-35 ; 250-255
2347 ; conventional dotted quad notation. e.g., 192.0.2.0
2348 ip6-network = <as per [RFC 3513], section 2.2>
2349 ; e.g., 2001:DB8::CD30
2354 Wong & Schlitt Experimental [Page 42]
2356 RFC 4408 Sender Policy Framework (SPF) April 2006
2359 domain-spec = macro-string domain-end
2360 domain-end = ( "." toplabel [ "." ] ) / macro-expand
2361 toplabel = ( *alphanum ALPHA *alphanum ) /
2362 ( 1*alphanum "-" *( alphanum / "-" ) alphanum )
2363 ; LDH rule plus additional TLD restrictions
2364 ; (see [RFC3696], Section 2)
2366 alphanum = ALPHA / DIGIT
2368 explain-string = *( macro-string / SP )
2370 macro-string = *( macro-expand / macro-literal )
2371 macro-expand = ( "%{" macro-letter transformers *delimiter "}" )
2372 / "%%" / "%_" / "%-"
2373 macro-literal = %x21-24 / %x26-7E
2374 ; visible characters except "%"
2375 macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
2377 transformers = *DIGIT [ "r" ]
2378 delimiter = "." / "-" / "+" / "," / "/" / "_" / "="
2380 name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
2382 header-field = "Received-SPF:" [CFWS] result FWS [comment FWS]
2383 [ key-value-list ] CRLF
2385 result = "Pass" / "Fail" / "SoftFail" / "Neutral" /
2386 "None" / "TempError" / "PermError"
2388 key-value-list = key-value-pair *( ";" [CFWS] key-value-pair )
2391 key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string )
2393 key = "client-ip" / "envelope-from" / "helo" /
2394 "problem" / "receiver" / "identity" /
2395 mechanism / "x-" name / name
2397 identity = "mailfrom" ; for the "MAIL FROM" identity
2398 / "helo" ; for the "HELO" identity
2399 / name ; other identities
2401 dot-atom = <unquoted word as per [RFC2822]>
2402 quoted-string = <quoted string as per [RFC2822]>
2403 comment = <comment string as per [RFC2822]>
2404 CFWS = <comment or folding white space as per [RFC2822]>
2405 FWS = <folding white space as per [RFC2822]>
2406 CRLF = <standard end-of-line token as per [RFC2822]>
2410 Wong & Schlitt Experimental [Page 43]
2412 RFC 4408 Sender Policy Framework (SPF) April 2006
2415 Appendix B. Extended Examples
2417 These examples are based on the following DNS setup:
2419 ; A domain with two mail servers, two hosts
2420 ; and two servers at the domain name
2421 $ORIGIN example.com.
2428 mail-a A 192.0.2.129
2429 mail-b A 192.0.2.130
2430 www CNAME example.com.
2433 $ORIGIN example.org.
2435 mail-c A 192.0.2.140
2437 ; The reverse IP for those addresses
2438 $ORIGIN 2.0.192.in-addr.arpa.
2441 65 PTR amy.example.com.
2442 66 PTR bob.example.com.
2443 129 PTR mail-a.example.com.
2444 130 PTR mail-b.example.com.
2445 140 PTR mail-c.example.org.
2447 ; A rogue reverse IP domain that claims to be
2448 ; something it's not
2449 $ORIGIN 0.0.10.in-addr.arpa.
2450 4 PTR bob.example.com.
2452 B.1. Simple Examples
2454 These examples show various possible published records for
2455 example.com and which values if <ip> would cause check_host() to
2456 return "Pass". Note that <domain> is "example.com".
2462 -- hosts 192.0.2.10 and 192.0.2.11 pass
2466 Wong & Schlitt Experimental [Page 44]
2468 RFC 4408 Sender Policy Framework (SPF) April 2006
2471 v=spf1 a:example.org -all
2472 -- no sending hosts pass since example.org has no A records
2475 -- sending hosts 192.0.2.129 and 192.0.2.130 pass
2477 v=spf1 mx:example.org -all
2478 -- sending host 192.0.2.140 passes
2480 v=spf1 mx mx:example.org -all
2481 -- sending hosts 192.0.2.129, 192.0.2.130, and 192.0.2.140 pass
2483 v=spf1 mx/30 mx:example.org/30 -all
2484 -- any sending host in 192.0.2.128/30 or 192.0.2.140/30 passes
2487 -- sending host 192.0.2.65 passes (reverse DNS is valid and is in
2489 -- sending host 192.0.2.140 fails (reverse DNS is valid, but not
2491 -- sending host 10.0.0.4 fails (reverse IP is not valid)
2493 v=spf1 ip4:192.0.2.128/28 -all
2494 -- sending host 192.0.2.65 fails
2495 -- sending host 192.0.2.129 passes
2497 B.2. Multiple Domain Example
2499 These examples show the effect of related records:
2501 example.org: "v=spf1 include:example.com include:example.net -all"
2503 This record would be used if mail from example.org actually came
2504 through servers at example.com and example.net. Example.org's
2505 designated servers are the union of example.com's and example.net's
2508 la.example.org: "v=spf1 redirect=example.org"
2509 ny.example.org: "v=spf1 redirect=example.org"
2510 sf.example.org: "v=spf1 redirect=example.org"
2512 These records allow a set of domains that all use the same mail
2513 system to make use of that mail system's record. In this way, only
2514 the mail system's record needs to be updated when the mail setup
2515 changes. These domains' records never have to change.
2522 Wong & Schlitt Experimental [Page 45]
2524 RFC 4408 Sender Policy Framework (SPF) April 2006
2527 B.3. DNSBL Style Example
2529 Imagine that, in addition to the domain records listed above, there
2532 $ORIGIN _spf.example.com. mary.mobile-users A
2533 127.0.0.2 fred.mobile-users A 127.0.0.2
2534 15.15.168.192.joel.remote-users A 127.0.0.2
2535 16.15.168.192.joel.remote-users A 127.0.0.2
2537 The following records describe users at example.com who mail from
2538 arbitrary servers, or who mail from personal servers.
2543 include:mobile-users._spf.%{d}
2544 include:remote-users._spf.%{d}
2547 mobile-users._spf.example.com:
2549 v=spf1 exists:%{l1r+}.%{d}
2551 remote-users._spf.example.com:
2553 v=spf1 exists:%{ir}.%{l1r+}.%{d}
2555 B.4. Multiple Requirements Example
2557 Say that your sender policy requires both that the IP address is
2558 within a certain range and that the reverse DNS for the IP matches.
2559 This can be done several ways, including the following:
2561 example.com. SPF ( "v=spf1 "
2562 "-include:ip4._spf.%{d} "
2563 "-include:ptr._spf.%{d} "
2565 ip4._spf.example.com. SPF "v=spf1 -ip4:192.0.2.0/24 +all"
2566 ptr._spf.example.com. SPF "v=spf1 -ptr +all"
2568 This example shows how the "-include" mechanism can be useful, how an
2569 SPF record that ends in "+all" can be very restrictive, and the use
2578 Wong & Schlitt Experimental [Page 46]
2580 RFC 4408 Sender Policy Framework (SPF) April 2006
2588 EMail: mengwong+spf@pobox.com
2593 Lincoln Nebraska, NE 68506
2594 United States of America
2596 EMail: wayne@schlitt.net
2597 URI: http://www.schlitt.net/spf/
2634 Wong & Schlitt Experimental [Page 47]
2636 RFC 4408 Sender Policy Framework (SPF) April 2006
2639 Full Copyright Statement
2641 Copyright (C) The Internet Society (2006).
2643 This document is subject to the rights, licenses and restrictions
2644 contained in BCP 78, and except as set forth therein, the authors
2645 retain all their rights.
2647 This document and the information contained herein are provided on an
2648 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2649 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
2650 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
2651 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
2652 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2653 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2655 Intellectual Property
2657 The IETF takes no position regarding the validity or scope of any
2658 Intellectual Property Rights or other rights that might be claimed to
2659 pertain to the implementation or use of the technology described in
2660 this document or the extent to which any license under such rights
2661 might or might not be available; nor does it represent that it has
2662 made any independent effort to identify any such rights. Information
2663 on the procedures with respect to rights in RFC documents can be
2664 found in BCP 78 and BCP 79.
2666 Copies of IPR disclosures made to the IETF Secretariat and any
2667 assurances of licenses to be made available, or the result of an
2668 attempt made to obtain a general license or permission for the use of
2669 such proprietary rights by implementers or users of this
2670 specification can be obtained from the IETF on-line IPR repository at
2671 http://www.ietf.org/ipr.
2673 The IETF invites any interested party to bring to its attention any
2674 copyrights, patents or patent applications, or other proprietary
2675 rights that may cover technology that may be required to implement
2676 this standard. Please address the information to the IETF at
2681 Funding for the RFC Editor function is provided by the IETF
2682 Administrative Support Activity (IASA).
2690 Wong & Schlitt Experimental [Page 48]
projects / FreeBSD / releng / 7.2.git / blob