As spam is increasing in the world and ways to circumvent current measures against it are increasing, so are new technologies and practices to prevent spam. A common problem is that the sender of spam (or any e-mail) can enter any e-mail address of the sender in the message header. We can find a parallel with classic paper mail, where we can also write any name and address of the sender on the envelope, nothing will stop us and no one has the opportunity to check the accuracy of this information. Only the recipient of the message will understand that it is false. So, of course, spammers do not use their address for sender addresses, but arbitrary and often random addresses with random domains.
This has an unpleasant effect – if the spam cannot be delivered to the recipient, the delivering SMTP server sends an error message to the sender’s address. Thus, not only recipients are overwhelmed, but also people whose addresses have been misused to send spam. Domain owners and administrators are certainly aware of this. We can prevent this delivery of error messages by taking care of the configuration of the mail server of our domain. For many other reasons, it is advisable not to use the so-called domain basket (i.e. delivering messages for unknown recipients to a special box), but to have a clearly defined list of recipient addresses that we accept on our domain, and strictly reject other addresses. This greatly reduces the likelihood that the spammer will correctly pick a sender’s address that actually exists.
However, the above measure will only reduce the amount of spam received for randomly generated recipients on our domain and will also reduce the amount of back-received error messages about the inability to deliver spam. However, spam will still be sent with the indication of our domain. This often leads to the administrators of servers that are affected by the influx of unsolicited messages mistakenly blaming us for the spam.
An attempt to solve this problem is the so-called SPF system (Sender Policy Framework), which is defined in RFC 7208. It is a system that allows domain owners to define rules that say which nodes on the Internet are allowed to send e-mails with the sender’s address from given domains. In practice, the domain owner enters a special TXT record in the zone, which contains a list of IP addresses of computers from which e-mails with the domain can come. Typically this will be a list of IP addresses of corporate computers, servers, corporate SMTP gateways, etc. This system must of course be supported by other servers. If the SMTP server receives an e-mail, queries the DNS and obtains a TXT record that contains SPF rules for the sender’s domain, it performs a check. It will then release the e-mail only if it complies with the rules. Otherwise it will reject it. The check is performed before the message body is sent (after sending the MAIL FROM command). An SMTP server that does not support SPF does not check it and lets the e-mail pass.
It was originally intended to use a special SPF type DNS record for SPF rules. However, this was eventually abandoned and this type of record was abolished in favor of the TXT record.
The SPF system is relatively young and until recently was called experimental, so this technology is not very widespread yet. In order to eradicate spam with it, all domains in the world would have to have the appropriate (and correctly defined) SPF records and all SMTP servers in the world would have to perform appropriate checks. Great care must be taken to set the rules correctly in the SPF record. If we accidentally forget about a computer or a subnet, there may be a problem with the delivery of regular e-mails.
The following is an example of what the corresponding TXT record for the ietf.org domain looks like (abbreviated):
v=spf1 ip4:64.170.98.0/26 ip6:2001:1890:1112:1::0/64 -all
In the example, we see clearly defined subnets that are allowed to send emails with an address containing the domain ietf.org.
ATTENTION: Multiple TXT (SPF) records must not be set for one domain, server addresses must be entered in one common record!
More information: