Significance of SPF
I want to draw your attention to an important, in my opinion, problem, which is neglected even by the largest and most innovative companies in the world. The problem is that most domains do not have an SPF record that protects the domain from unauthorized use in email.
SPF (Sender Policy Framework) is a text entry in the TXT record of the DNS domain. The record contains information about the list of servers that have the right to send letters on behalf of this domain and the mechanism for processing letters sent from other servers.
For example, the SPF record “ example.com. TXT "v = spf1 + a + mx -all""Says that the servers specified in the A and MX records of this domain can send letters on behalf of the domain" example.com ", and letters sent from other servers must be deleted (Fail).
It is important to understand:
All details on this can be found on the technology the site of the project «the Sender the Policy Framework» .
Currently, all advanced anti-spam systems use 3 main types of email analysis (and their variations):
To successfully pass the anti-spam system, a spammer (or scammer) will need: “clean ip”, a beautiful letter and a domain without protection (examples No. 1 and No. 3). To prevent sending letters from “your name” (phishing), you just need to add the corresponding TXT record to the domain (example No. 2).
As an example, I sent 3 simple letters using telnet and SMTP commands. 2 letters will show the work of the SpamAssassin spam filter (mail-tester.com service), and the last letter will go through the Gmail anti-spam filter. For the purity of the experiments, I used a “clean” IP address (it was not so difficult to find it) and text without links and HTML.
Letter No. 1:
Letter No. 2:
Letter No. 3:
As can be seen from the results, a letter from the microsoft.com domain would not have passed the anti-spam filter, even if it had perfectly clean content. But the letter on behalf of the domain "microsoft.ru" passed the verification of both SpamAssassin and Gmail, as it is not protected.
Comrades IT people, do not expose yourself and your company - set SPF records for all your domains and MX servers.
Testing SPF records
SpamAssassin anti-spam email analysis
Many useful tests (MX, SPF, Blacklist, DKIM Lookup, etc.)
Checking the reputation of mail servers and domains
Checking the domain and sender servers (here you will see who sends letters on behalf of your domain)
MS Sender ID Framework SPF Record Wizard
SPF (Sender Policy Framework) is a text entry in the TXT record of the DNS domain. The record contains information about the list of servers that have the right to send letters on behalf of this domain and the mechanism for processing letters sent from other servers.
For example, the SPF record “ example.com. TXT "v = spf1 + a + mx -all""Says that the servers specified in the A and MX records of this domain can send letters on behalf of the domain" example.com ", and letters sent from other servers must be deleted (Fail).
It is important to understand:
- An SPF record is not inherited into subdomains. Each domain of the third (and lower) levels needs its own record.
- SPF checks only HELO and MAIL FROM fields.
All details on this can be found on the technology the site of the project «the Sender the Policy Framework» .
Why is it important?
Currently, all advanced anti-spam systems use 3 main types of email analysis (and their variations):
- Analysis of the IP address of the sender server: its reputation, correctness of A and PTR records.
- Analysis of SPF / DMARC domain records and DKIM digital signatures.
- Content analysis: headings, subject, text, links, etc.
To successfully pass the anti-spam system, a spammer (or scammer) will need: “clean ip”, a beautiful letter and a domain without protection (examples No. 1 and No. 3). To prevent sending letters from “your name” (phishing), you just need to add the corresponding TXT record to the domain (example No. 2).
Examples
As an example, I sent 3 simple letters using telnet and SMTP commands. 2 letters will show the work of the SpamAssassin spam filter (mail-tester.com service), and the last letter will go through the Gmail anti-spam filter. For the purity of the experiments, I used a “clean” IP address (it was not so difficult to find it) and text without links and HTML.
| # | From | To | Result | SPF sender domain |
| 1 | bill.gates@microsoft.ru | *@mail-tester.com | Successfully. Points at mail-tester.com: 7/10 | - |
| 2 | bill.gates@microsoft.com | *@mail-tester.com | Unsuccessfully. Points at mail-tester.com: 2.1 / 10 | v = spf1 include: _spf-a.microsoft.com include: _spf-c..microsoft.com include: _spf-ssg-a.microsoft.com include: spf-a.hotmail.com ip4: 147.243.128.24 ip4: 147.243.128.26 ip4: 147.243.1.153 ip4: 147.243.1.47 ip4: 147.243.1.48 -all |
| 3 | bill.gates@microsoft.ru | *@gmail.com | Successfully | - |
Letter No. 1:
Letter No. 2:
Letter No. 3:
As can be seen from the results, a letter from the microsoft.com domain would not have passed the anti-spam filter, even if it had perfectly clean content. But the letter on behalf of the domain "microsoft.ru" passed the verification of both SpamAssassin and Gmail, as it is not protected.
Advice
- Before installing an SPF record, make sure that all servers sending emails to the Internet are taken into account. Do not forget about web-servers and other external systems, otherwise you may lose some letters, and thereby harm yourself and your business.
- Correctly choose the mechanism for processing letters (Pass, Fail, SoftFail, Neutral). If you unconditionally redirect your letter from one mail system to another, a problem may arise, since SPF checks only the last "hop".
- It is recommended that you create SPF records for all second-level domains that belong to you or your company, even if you do not send letters on their behalf. For such domains, it is advisable to use a simple record “ v = spf1 -all ”, which says that no one can send letters from these domains.
- Third-level domains can be protected using a wildcard record of the type * .example.com. IN TXT "v = spf1 -all" ". But, note that wildcard only works for non-existent subdomains. For example, if you have a subdomain moscow.example.com with MX records, the entry is “ * .example.com. TXT the IN «v = spf1 -all» »will be distributed to it. More details are described in the article on Wikipedia and RFC 1034 .
Moreover, the wildcard is matched only when a domain does not exist, not just when there are no matching records of the type that has been queried for. Even the definition of "does not exist" as defined in the search algorithm of RFC 1034 section 4.3.2 can result in the wild card not matching cases that one might expect with other types of wildcards.
- It is recommended that you create SPF records not only for domains, but also for mail servers that send emails to the Internet. It is necessary to pass the HELO / EHLO Test of the receiving server. Standard entry: “ mx.example.com. IN TXT "v = spf1 a -all" ".
- If you have many domains that are served by several major MX servers, then I recommend using the redirect mechanism. For example, the main domain “example.com” has an SPF record “ v = spf1 + a + mx -all ”, then for other domains (example1.com, example2.com, etc.), for ease of maintenance, you can register an entry " V = spf1 redirect = example.com ."
- If you have many domains and many sender mail servers distributed geographically and organizationally, you can use the “include” mechanism and a separate zone “_spf.example.com”. As an example, you can see the entry for the gmail.com domain - “ v = spf1 redirect = _spf.google.com ”.
- In addition to protecting your domains, it is recommended that you protect your mail system and users by enabling verification of SPF / DKIM / DMARC records on your external mail servers. This will be a good addition even for powerful hardware and software systems like Cisco IronPort.
- As soon as you fully understand SPF, I advise you to study the issue of signing your emails using DKIM technology and DMARC policy, this will significantly increase the reputation of your outgoing emails.
Comrades IT people, do not expose yourself and your company - set SPF records for all your domains and MX servers.
Useful Services
Testing SPF records
SpamAssassin anti-spam email analysis
Many useful tests (MX, SPF, Blacklist, DKIM Lookup, etc.)
Checking the reputation of mail servers and domains
Checking the domain and sender servers (here you will see who sends letters on behalf of your domain)
MS Sender ID Framework SPF Record Wizard