SPF authentication: Sender Policy Framework
Definition of SPF (Sender Policy Framework)
This sender authentication technique is extremely easy to implement. The principle is simple: after extracting the sender’s domain (“MAIL FROM:” from the SMTP message envelope, not the “From:” field in the header), a TXT-type DNS query is performed on the domain in question to find out the list of mail servers authorized to send e-mails, and to compare it with the IP address of the server sending the message.
Unfortunately, however, this technology has a problem when it comes to email forwarding: in this case, the sending server is not necessarily the mail server of the original sender of the email. On the other hand, when setting up SPFs, you need to be exhaustive, otherwise the SPF rule will not be respected. In some architectures, it’s even preferable not to set SPF fields at all, rather than run the risk of not respecting it! To be sure, you can check the complete list of your sending servers via DnsLookup.fr (see #15 of http://dnslookup.fr/faq.php).
Examples:
The presence of the following TXT field: domain.tld IN TXT “v=spf1 mx ~all” is sufficient, for example, to consider that a domain’s sending servers correspond to its MX servers.
To simply define an IP address, use the syntax: “v=spf1 ip4:192.168.0.1/32 ~all”.
Applications :
A sender belonging to a domain that makes every effort to distribute and respect its SPFs will be considered more reliable. SenderID, a technology defined by Microsoft, now uses the DNS definition implemented for SPF. However, operation and use are a little different. In ALTOSPAM, we use the pure SPF implementation to accredit the sending servers of a domain.
Email is the main vector for cyberattacks
Text New and increasingly sophisticated attacks are being launched around the world every day. Our solution detects and neutralizes phishing, spear-phishing, malware, ransomware and spam threats in real time.