- October 26, 2021
- Posted by: Divya
- Categories: Email Marketing, Uncategorized
“Protect from phishing, spoofing and prevents email from being flagged as spam.”
Understand what is Sender Policy Framework?
SPF is included in the email authentication method; the SPF concept was designed in 2000 to detect incorrect email addresses during email delivery. We use SPF to protect our domains from spoofing and to prevent the emails we deliver from being flagged as spam.
SPF assigns email servers that are allowed to send bulk email from our domain. Using an SPF with a specified email server indicates that messages coming from your domain are sent only from the specified server.
Without SPF, sending email from your domain or company marks the email as spam on the recipient’s email server.
Importance of Sender Policy Framework
- Protect from phishing and spoofing
- Prevent email from being marked as a spam
- Confirm email received on the recipient’s mail server that the mail came from a secure and specified mail server
- It informs the recipient how reliable the base of the email is.
History of Sender Policy Framework (SPF)
The SPF concept was first introduced to the public in 2000, but not many people noticed at the time. There was no mention of the concept again until it was published in 2002 on the IETF “Namedroppers” mailing list by Dana Valerie Reese, who was unknown since 2000.
All were also unknown until it was published by Dana Valerie Reese on the IETF “Namedroppers” mailing list in 2002.
The morning of the next day, Paul Vixie published his own SPF-like specification post on the same list, and after public interest conscious, the IETF Anti-Spam Research Group (ASRG) and their mailing list arose, where SPF was further developed.
In June 2003, Meng Weng Wong bring together the RMX and DMP specifications and solicited ideas from others. After the next six months, began working more on SPF with the larger community and announcing major changes.
SPF stands for Sender Permitted From and is sometimes referred to as SMTP+SPF. But in February 2004, it was renamed as Sender Policy Framework.
The IETF created the MARID Working Group in early 2004 to try to decipher what a sender ID is using SPF and Microsoft’s CallerID proposal as a basis, but was unsuccessful due to technical and licensing conflicts.
The SPF community returned the original “classic” version of SPF, this version of the specification was approved as an IETF use by the IESG in 2005. The SPF RFC was revealed as Experimental RFC 4408 on April 28, 2006.
The IETF published SPF as a “proposed standard” in RFC 7208 in April 2014.
Why should we add SPF Record for Domain?
You can also send email without setting a SPF record, but SPF provides an additional security signal to ISPs that the message will go to the recipient’s inbox.
SPF doesn’t solve all your email delivery problems, but it is an additional email-authenticating method that merged with DKIM and DMARC to improve email delivery rates and avoid fixing, spoofing, and spamming.
How does SPF Record Works?
The work of SPF policy is a bit lengthy, let’s see how SPF works.
The above SPF workflow is given in a diagram of how the receiver’s mail server checks the SPF.
- Sender server send email with IP address of 126.96.36.199 and email is using Cname (return path) firstname.lastname@example.org
- Then receiving mail server catch the render-path domain and examines the domain’s DNS records
- The receiving mail server gets the SPF record for the sender’s domain example.com, then checks whether any IP address listed as a valid sender for the domain matches the address that is being used to send mail.
- Then it’s match! sending IP will listed as an approved sender, status will be SPF pass. If IP address doesn’t match, that status would be SPF fail.
SPF Record Syntax
“v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -all”
V= determine the version of using SPF. Determine the version of SPF used. These given words provide the mechanism whether the domain is capable of sending email or not.
Determine the version of SPF used. These given words provide the mechanism whether the domain is capable of sending email or not. The IPV4 and ‘A’ mechanisms specify the systems allowed to send messages to the specified domain. The “-all” at the end defines the message to be rejected if the previous system does not match.
The mechanism is used to specify the set of hosts to which the outbound mailer is assigned to the domain, and may be prefixed with one of four qualifiers.
All: This mechanism should be at the very end of the SPF syntax and this mechanism always matches. “-all” is used for the default result, and it is taken for all IPs that do not match the prior system.
IP4: The logic of the mechanism is an IPv4 network range. If sender is included in IPv4 network range, match it.
IP6: If sender is included in IPv6 network range, match it.
A: All “A” records in the domain will be checked. This mechanism matches if the client IP is found between them. AAAA lookup is performed if the network range is IP6.
MX: All “A” record for each and every “MX record” of all the Domains is examine according to MX priority. If Client IP is found, mechanism matches.
The A record must exactly match the client’s IP, as long as the prefix-length is not obtained. At this point each IP address returned by a lookup will be expanded to its corresponding CIDR prefix and the client IP will be sought within that subnet.
PTR: If the PTR record of the domain’s address matches the given domain and that domain name matches the client’s address. This mechanism is discouraged and should be avoided.
EXISTS: If the given domain name matches any mail address. It is used less. Along with the SPF macro language it provides more concrete matches such as DNSBL-queries.
INCLUDE: This is in relation to another domain’s policy. If their policy is declared pass then the process is over. If the policy is not passed, processing continues. Redirect is used to fully delegate the policy of another domain.
There are four types of qualifiers, each of which can be combined with a mechanism.
Default qualifier is “+”which means pass, if modifier is not matched, the default result will be “neutral”.
Evaluating an SPF record may return any of the following results:
|Pass||SPF record appointed a host to be permitted to send message.||Accept|
|Fail||The SPF record has appointed host are not permitted to send email.||Reject|
|Softfail||The SPF record has told the host that it is not allowed to send the email but is in transformation state.||Accept but mark|
|Neutral||The SPF record clearly indicates this that the validity is not yet known.||Accept|
|None||The domain has not verified SPF record or is not able to evaluate SPF result.||Accept|
|PermError||A persistent error has occurred (eg badly formatted SPF record)||Unspecified|
|TempError||A temporary error has occurred||Accept or Reject|