I would like to draw your attention to an important, in my opinion, problem that even the largest and most innovative companies in the world have neglected. The problem is that most domains do not have SPF records that protect the domain from unauthorized use in email.
SPF (Sender Policy Framework) is a text entry in the TXT records 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. The TXT "v = spf1 + a + mx-all" ”means that the server specified in the A and MX records of this domain can send letters on behalf of the“ example.com ”domain, and letters sent from other servers should be deleted (Fail).

It is important to understand:
- SPF record is not inherited on subdomains. Each domain of the third (and below) levels requires its own entry.
- SPF checks only HELO and MAIL FROM fields.
All the detailed information about this technology can be found on the
site of the project “Sender Policy Framework” .
Why is it important?
Currently, all advanced anti-spam systems use 3 main types of email analysis (and variations):
- Analysis of the IP address of the sending server: its reputation, the correctness of the A and PTR records.
- Analysis of SPF / DMARC domain records and DKIM digital signature.
- Content analysis: titles, subject, text, links, etc.
In order to successfully go through the anti-spam system, the spammer (or fraudster) will need: “pure ip”, a beautiful letter and a domain without protection (examples 1 and 3). To prevent sending emails on “your name” (phishing), all you have to do is add the appropriate TXT record to the domain (example # 2).
Examples
As an example, I sent 3 simple letters using telnet and SMTP commands. 2 emails will show the operation of the SpamAssassin spam filter (mail-tester.com service), and the last email 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 | Sender Domain SPF |
one | bill.gates@microsoft.ru | *@mail-tester.com | Successfully. Points in 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-b.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 number 1:

Letter number 2:

Letter number 3:



As can be seen from the results, a letter from the microsoft.com domain would not pass an anti-spam filter, even if it has perfectly clean content. But the letter on behalf of the domain "microsoft.ru" was tested by both SpamAssassin and Gmail, since it is not protected.
Tips
- Before installing the SPF record, make sure that all servers that send emails to the Internet are taken into account. Do not forget about the web server and other external systems, otherwise you can lose some of the letters, and thus harm yourself and your business.
- Choose the right email processing engine (Pass, Fail, SoftFail, Neutral). If your letter is unconditionally redirected from one mail system to another, a problem may arise, since SPF only checks 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 desirable to use the simple entry “ v = spf1 -all ”, which says that no one can send emails from these domains.
- Domains of the third level can be protected using wildcard-records of the type " * .example.com. IN TXT "v = spf1-all ". " But pay attention to the fact that wildcard only works for non-existent subdomains. For example, if you have a subdomain moscow.example.com with MX records, the entry “ * .example.com. IN TXT "v = spf1 -all" "will not apply to it. Details are described in the article on Wikipedia and RFC 1034 .
Moreover, it is not possible to record the wildcard. It would not be possible to clarify the code.
- SPF records are recommended to be created not only for domains, but also for mail servers that are engaged in sending emails to the Internet. This is required to pass the HELO / EHLO Test of the receiving server. Standard entry: “ mx.example.com. IN TXT "v = spf1 a -all ". "
- If you have a lot of domains that are served by several primary MX servers, then I advise you to use the redirect mechanism. For example, the main domain "example.com" has the SPF record " v = spf1 + a + mx -all ", then the rest of the domains (example1.com, example2.com, etc.), for ease of maintenance, you can write " V = spf1 redirect = example.com ".
- If you have many domains and many mail servers of the senders distributed geographically and organizationally, then you can use the “include” mechanism and a separate zone “_spf.example.com”. As an example, you can see the entry for the domain gmail.com - “ v = spf1 redirect = _spf.google.com ”.
- In addition to protecting your domains, it is recommended to protect your mail system and users by turning on SPF / DKIM / DMARC checking of records on your external mail servers. This will be a good addition even for such powerful software and hardware systems such as 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 professionals, do not substitute yourself and your company - set SPF records for all your domains and MX servers.
Useful services
SPF Recording TestingSpamAssassin anti-spam analysisMany useful tests (MX, SPF, Blacklist, DKIM Lookup, etc.)Checking the reputation of mail servers and domainsChecking the domain and sending servers (here you will see who is sending letters on behalf of your domain)MS Sender ID Framework SPF Record Wizard