This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
Sender Policy Framework
Sender Policy Framework

Version management

Difference between version and

At line 1 added 25 lines
!!! Overview
[{$pagename}] (SPF) is an [email] [authentication] [protocol] designed to detect forging sender addresses during the delivery of the [email] and is defined in [RFC 7208][{$pagename}] alone though is limited only to detect a forged sender claimed in the envelope of the [email] which is used when the mail gets bounced. Only in combination with [DMARC] it can be used to detect forging of the visible sender in emails ([email] [spoofing]), a technique often used in [phishing] and [email] [spam].
[SPF] allows the receiving mail server to check during [email] delivery that a [email] claiming to come from a specific domain is submitted by an [IP Address] authorized by that [DNS Domain]'s administrators. The list of authorized sending hosts and IP addresses for a domain is published in the [DNS Resource Records] for that [DNS Domain].
!! [{$pagename}] [Implementation]
Compliance with [SPF] consists of three loosely related tasks:
* Publish a policy: Domains and hosts identify the machines authorized to send email on their behalf. They do this by adding additional records to their existing DNS information: every domain name or host that has an A record or MX record should have an SPF record specifying the policy if it is used either in an email address or as HELO/EHLO argument. Hosts which do not send mail should have an SPF record published which indicate such ("v=spf1 -all"). It is highly recommended to validate the SPF record using record testing tools such as those provided on the SPF Project webpage.
* Check and use SPF information: Receivers use ordinary DNS queries, which are typically cached to enhance performance. Receivers then interpret the SPF information as specified and act upon the result.
* Revise mail forwarding: Plain mail forwarding is not allowed by SPF. The alternatives are:
** Remailing (i.e., replacing the original sender with one belonging to the local domain)
** Refusing (i.e., answering 551 User not local; please try <user@example.com>)
** Whitelisting on the target server, so that it will not refuse a forwarded message
** Sender Rewriting Scheme, a more complicated mechanism that handles routing non-delivery notifications to the original sender
Thus, the key issue in SPF is the specification for the new DNS information that domains set and receivers use. The records laid out below are in typical DNS syntax, for example:
{{{"v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -all"}}}
"v=" defines the version of SPF used. The following words provide mechanisms to use to determine if a domain is eligible to send mail. The "ip4" and "a" specify the systems permitted to send messages for the given domain. The "-all" at the end specifies that, if the previous mechanisms did not match, the message should be rejected.
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Sender Policy Framework|Wikipedia:Sender_Policy_Framework|target='_blank'] - based on information obtained 2019-07-18
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop