RFC 5322 includes the syntax for Internet email headers. This means it does not say anything directly about how SPF should be configured and maintained. However, we know SPF works in conjunction with the email headers defined in RFC5322, particularly the ‘MAIL FROM’ and ‘Return-Path’ headers. It’s true that SPF’s job is to verify the authenticity of the sender’s domain via DNS records, but its structure is based on the concept that also involves interaction with the email headers defined in RFC5322. All this makes the protocol more complex, and that’s exactly what we’ll untangle through this article.
SPF focus
SPF is an email authentication protocol that is deployed by domain owners to prevent instances of email phishing and spoofing attempted in their names. With SPF in place, the domain owners specify the servers they officially allow to be used for sending emails from their domains. SPF works by validating the IP address of the server sending the email. This is done by comparing it to the domain’s SPF DNS record.
SPF primarily checks the ‘MAIL FROM’ address (defined in RFC 5321 during the SMTP process) and not the headers defined by RFC 5322. However, its results can indirectly influence how headers like ‘From’ are perceived for authenticity.
SPF and RFC5322 headers
The MAIL FROM address, which is also known as the SMTP address, is basically recorded in the Return-Path header of the final email. Whereas, if we talk about the From field, then it’s the visible sender address that the recipients see when they receive your email.
A potential risk arises when both addresses don’t match and SPF does not directly validate the From header. This misalignment opens avenues for malpractices and leads to cyberattacks like spoofing, phishing, and ransomware through emails. These attacks become successful because recipients only focus on the visible sender address without realizing that the actual sender address is different.
For example, the MAIL FROM address used by SPF might be bounce@example.com, while the From header displayed to the recipient could be ceo@another-domain.com. Without additional standards like DMARC to enforce alignment, such discrepancies can be exploited for phishing and fraud.
Return-Path header
The receiving server inserts the return-path header, and it also includes the MAIL FROM address. SPF uses it to verify the origin of the email so that it can confirm whether it has come from a legitimate source or not. If the IP address of the sending server does not belong to the list mentioned by the domain owner in the SPF record, the SPF check fails. This means such an email will be subjected to either the Softfail mechanism or the Hardfail mechanism, whatever you have chosen to mention in your SPF record.
SPF alone is not enough
SPF comes with its own set of shortcomings, but DKIM and DMARC and email security measures compensate for them by bridging the deficiencies. DKIM helps know if someone has tampered with the email content in transit, while DMARC ensures alignment between MAIL FROM and FROM headers. Without DMARC, a mismatch between these headers might still pass SPF but appear suspicious.
