Difference between revisions of "SPF/term"
< SPF
Jump to navigation
Jump to search
(→About) |
|||
| Line 61: | Line 61: | ||
|- | |- | ||
|} | |} | ||
| − | + | ==Links== | |
| + | * [https://dmarcadvisor.com/spf-syntax-table/ SPF Record Syntax] | ||
==Footnote== | ==Footnote== | ||
<references> | <references> | ||
<ref name=ptr-note>From the RFC (formatting added for clarity): {{fmt/quote|'''This mechanism is slow, it is not as reliable as other mechanisms in cases of DNS errors, and it places a large burden on the {{l/wp|.arpa}} name servers.''' If used, proper PTR records have to be in place for the domain's hosts and the "ptr" mechanism SHOULD be one of the last mechanisms checked. After many years of SPF deployment experience, '''it has been concluded that it is unnecessary and more reliable alternatives should be used instead.''' It is, however, still in use as part of the SPF protocol, so compliant check_host() implementations MUST support it.}}</ref> | <ref name=ptr-note>From the RFC (formatting added for clarity): {{fmt/quote|'''This mechanism is slow, it is not as reliable as other mechanisms in cases of DNS errors, and it places a large burden on the {{l/wp|.arpa}} name servers.''' If used, proper PTR records have to be in place for the domain's hosts and the "ptr" mechanism SHOULD be one of the last mechanisms checked. After many years of SPF deployment experience, '''it has been concluded that it is unnecessary and more reliable alternatives should be used instead.''' It is, however, still in use as part of the SPF protocol, so compliant check_host() implementations MUST support it.}}</ref> | ||
</references> | </references> | ||
Revision as of 14:10, 19 August 2022
|
SPF terms
|
About
SPF terms are either mechanisms (which are ways of evaluating and return pass/fail) or modifiers (which return additional information but do not evaluate). All terms are separated by spaces.
Mechanisms used by SPF are defined in RFC 7208 Section 5.
Modifiers used by SPF are defined in RFC 7208 Section 6.
Commonly-used argument names:
- <*-cidr-length>: see cidr-length
- <domain-spec> defaults to <host domain>.
- <host domain> is the domain whose DNS record we're constructing/examining
- The RFC calls this the
<target-name>).
- The RFC calls this the
- <ip>, aka "the IP": I thought this meant one thing, but now I'm not sure.
| code | format | meaning |
|---|---|---|
| Basic mechanisms: | ||
all
|
all
|
a test that always matches; place as last mechanism in a record to provide an explicit default |
include
|
include:<domain-spec>
|
utility is unclear; includes SPF evaluation of the given domain, but not in a systematic way |
| Designated sender mechanisms: | ||
a
|
a[:<domain-spec>] [ <dual-cidr-length> ] | match if <domain-spec> points to one of the <host domain>'s IP addresses |
mx
|
mx |
All the A records for all the MX records for <domain-spec> are tested in order of MX priority. If the client IP is found among them, this mechanism matches. |
|
(do not use[1]) | |
|
|
ipN[:<ipN-network>] [ <ipN-cidr-length> ] | test whether sender is contained within a given IP network
|
exists
|
exists:<domain-spec> | construct a domain name in various ways, and use that for a DNS A record query.
|
| Modifiers: | ||
Links
Footnote
- ↑ From the RFC (formatting added for clarity): «This mechanism is slow, it is not as reliable as other mechanisms in cases of DNS errors, and it places a large burden on the .arpa name servers. If used, proper PTR records have to be in place for the domain's hosts and the "ptr" mechanism SHOULD be one of the last mechanisms checked. After many years of SPF deployment experience, it has been concluded that it is unnecessary and more reliable alternatives should be used instead. It is, however, still in use as part of the SPF protocol, so compliant check_host() implementations MUST support it.»