In the following article and the next article (My E-mail appears as spam | The…
The current article focused on explaining the purpose of the SPF record and, how does the SPF record enable us to prevent a scenario in which hostile elements, could send E-mail on our behalf.
The next article – Implementing SPF record | Part 8#17, focus on the “technical side” of the SPF record such as – the structure of SPF record, the way that we create SPF record, what is the required syntax for the SPF record in Office 365 environment + Mix mail environment, how to verify the existence of SPF record and so on.
Table of contents
The purpose of the SPF record
There are two main objectives for using SPF record:
- Try to prevent a scenario, in which spammer will send E-mails using our domain name (a specific organization E-mail address) by using his mail server. In other words: a scenario in which the spammer’s mail server is introduced himself as “our legitimate mail server”.
- Preventing a scenario, in which a destination mail server will block E-mail that sent from our organization or “stamp” our organization mail with a high spam score level because a spammer is “distributing E-mail” using our organization user’s identity (using an E-mail address of our recipient organization).
Issues that relate to SPF record
We can classify that scenario of “problems that relate to SPF record” into two main areas:
- Lack of SPF record – a typical scenario, in which the organization doesn’t use an SPF record. The main reason is – lack of awareness to the big impertinence of using SPF records.
- Miss configured SPF record – an existing SPF record that was configured with incorrect syntax or doesn’t include the “full information” about all the mail server that represents the particular organization.
Why do I need to use SPF record?
Ensure our E-mail message reliability
The use of SPF record is critical in a modern mail environment because SPF record enables us to set the level of “reliability” of an E-mail message that sent “from our organization” meaning: E-mail message sent from our legitimate mail server.
The purpose of the SPF record is to enable organizations to publicly “declare” who are the mail servers, which are authorized to send mail on behalf of the organization (for a particular domain name).
The destination mail server, which accepts E-mail message that includes our domain name (E-mail address with our domain name), can verify if the mail server that “deliver” the E-mail is entitled or, authorized to represent the specific domain name.
The destination mail server verifies this information by looking for at the organization SPF record, which should include a list of all of the authorized mail servers that represent the particular domain name.
In case that the “source mail server” doesn’t appear as listed in the SPF record, the “destination mail server” (the mail server that spouses accept the E-mail message and forward the E-mail to the target recipient) can decide if he agrees to accept the
E-mail or, “block” the sending mail server.
A scenario in which we don’t use SPF record or, a situation in which we sent mail by using a mail server that doesn’t appear on the SPF record that represents our domain name, could lead to a significant reduction in the “reliability grade” of E-mail that is sent by our organization users.
In other words: an outcome in which our organization E-mail identified as spam/junk mail.
Prevent spoofing scenario
In a modern mail environment the scenario of “spoofing” is very common and very popular.
The reason for this “popularity” of the spam phenomenon is because that the SMTP mail protocol was created, based on the assumption that the parties that want to communicate using E-mail message are, “legitimate players.”
The reality is a little different and many times, hostile elements such as spammers, use the primary SMTP option for “presenting themselves” as some else (impersonation).
For example: in a standard SMTP session between two mail servers (the source and the destination mail server), when server A connects server B and ask him to forward
An E-mail message to a recipient who hosted on mail server B, mail server A, present himself as the representative of the source recipient.
By default, server B (the destination server) is supposed to believe to server A ( the belief that he is the true representative of the source recipient).
The SPF record was created for preventing a scenario in which spammer, fake his identity and, pretend to be the “legitimate mail server” of a particular organization.
In our example, the spammer’s mail server, present himself as the legitimate mail server that sends E-mail “on behalf” the domain: o365info.com
In the following diagram, we can see such a scenario, in which hostile elements try to send E-mail message to the destination recipient and the mail server of the hostile elements “declare” that the message sent by a recipient’s name – Alice@o365info.com
Q1: What is SPF stand for?
A1: SPF stands for Sender Policy Framework
Q2: How does the SPF record is implemented?
A2: By publishing a TXT record in our public DNS that includes pre-defined structure + information about the mail server that is authorized and “approved” to send E-mail on behalf of our organization.
Q3: What is the information that included in the SPF record?
A3: The SPF record contains information about the mail server names or IP address that represents a particular organization (domain name) and can send an E-mail on behalf of the organization.
The SPF record syntax includes additional options for “pointing out” the legitimate mail server, such as using the MX or the A record option.
For example, when using the MX option in the SPF record, the meaning is that all the mail servers who appear “under” the MX record of a specific domain name, considers as “authorized” mail server that can send E-mail on behalf of the particular domain.
How does the SPF record prevent a spoofing scenario?
To be able to demonstrate the way in which the use of the SPF record prevents a spoofing, let’s use the following scenario:
A hostile element (spammer) wants to distribute spam mail, hide his identity and impersonate his identity by using the identity of a legitimate organization that uses the public domain name: o365info.com
The spammer is going to “present himself” using the recipient name (E-mail address) – Alice@o365info.com
Step 1: Sending E-mail message on behalf of the legitimate recipient
In the following diagram, we can see that the spammer’s mail server connects the destination mail server and asks him to forward email messages to the target recipient.
The destination mail server “see” that the IP address that used by the “source mail server” (the spammer’s mail server) is: 100.100.100.100
Pay attention that the “real mail server” that represent the organization o365info.com, use different IP address: 188.8.131.52
Step 2: Destination mail server, check SPF record.
In our scenario, we assume that the E-mail policy that utilized by the “destination mail server” is configured to check the SPF record of the “source mail server.”
The “destination mail server” query DNS server and ask for the SPF record for the domain – o365info.com
In our scenario, the SPF record “say” that the “formal mail server” that represents the domain – o365info.com is: 184.108.40.206
Step 3: Destination mail rejects the E-mail message.
The spammer’s mail server is the IP address: 100.100.100.100
Because the SPF record for the domain – o365info.com doesn’t include this IP address; the mail server will reject the E-mail message from the spammer’s mail server.
Important: The “real world” is a little more complicated. In reality, there could be many other scenarios.
For example: in case that the “destination mail server” is not configured to check the existence of SPF record, he will accept the E-mail message that was sent by the spammer.
Another possible scenario could be a situation in which the “destination mail server” will agree to accept the E-mail, although the IP address of the “source mail server” (the spammer’s mail server) doesn’t appear in the SPF record. In this case te mail server “stamp” the E-mail message as a “problematic” or dangerous E-mail message.
“Problems” that relates to SPF record
Q: What are a possible scenario of “problems” that relates to SPF record?
A: An example of a “problems” that relates to SPF record could be:
- Lack of SPF record – A scenario in which the organization doesn’t use SPF record.
- More than one SPF records – a common mistake, in which the DNS includes two or more SPF records. The outcome is: “unknown results”. Some of the mail server will relate only to one SPF record and some mail server, will refuse to accept mail because the SPF record not configured correctly.
- SPF record that set improperly. SPF record based on very strict “syntax rules” that dictate how to “construct” the SPF record. In some cases, the SPF record includes a syntax error. In this case, we are dealing again with the realm of: “unknown results”.
- SPF record that doesn’t include information about all the organization’s mail servers.
Any of this “issues”, could lead to a scenario in which external mail server will block mail that sent by a user’s from our organization (users whom their E-mail address includes our public domain name).
Mixed mail environment example
An example of a scenario: “SPF record that doesn’t include information about all the organization’s mail servers” could be: Hybrid environment, that is based on two separated mail infrastructures: the Office 365 mail infrastructure (Exchange Online) and the Exchange on-Premises mail infrastructure.
In this scenario, an E-mail message could be sent from the booth of this mail infrastructure (depend on the physical location of the user mailbox).
In a scenario of: “two separate mail infrastructures”, the SPF should contain “pointers” to the separated mail infrastructure.
In simple words: the SPF record should “declare” that E-mail that sent by the Exchange Online mail servers + mail that sent from the Exchange on-Premises mail servers consider as a legitimate mail.
In case that the SPF record value that we have configured doesn’t include information about the Exchange on-Premises server. Each E-mail that will be sent by the Exchange on-Premises server has the Potential to be identified as spam/junk mail.
You can read more detailed information on the SPF record syntax in the article Implementing SPF record | Part 8#17.
Q: In a scenario of a problem in SPF record, what are the possible “responses” of the target mail server?
A: It’s important to emphasize that in a scenario of: “problems that relate to SPF record,” the “response” from the destination mail server, cannot be predictable.
The reason is that each mail server, use or implement a different mail security policy.
Some of the mail servers are more “forgiving” to a scenario of luck (or a problem) of SPF record and, some of the mail servers are stricter.