RFC 5322 laid down email security specifications for Sender Policy Framework
RFC 5322 defines the syntax for Internet email headers. SPF, DKIM, and DMARC rely on these headers to authenticate emails and prevent phishing. Published in October 2008 as an update to RFC 2822, RFC 5322 is widely used for formatting email headers and bodies.
RFC 5322 doesn’t say anything about how SPF should be set up. However, since SPF works in conjunction with the email headers defined in RFC 5322 (particularly MAIL FROM and Return-path), it’s important to consider it.
While SPF is only responsible for verifying whether an authorized sender has sent the email, it’s based on a complicated structure that requires interaction with the email headers defined in RFC 5322. This blog attempts to explain these structures in an easier manner.
How does SPF function?
SPF uses DNS TXT records in which the domain owner mentions all the approved mail servers that can be used to send emails on behalf of the brand. When a recipient’s mail server gets an email from your domain, it retrieves the SPF record corresponding to the sender’s domain to determine whether the sending server is authorized.
If the sending server’s IP matches an entry in the SPF record, the email passes SPF authentication. However, if the sending server’s IP is not listed in the SPF record:
- The email is rejected if -all is used.
- The email is marked as suspicious but still delivered if ~all is used.
- No action is taken if ?all is used.
The receiving mail server logs the SPF result and may use it along with other factors (such as DKIM and DMARC) to decide whether to accept, reject, or mark the email as spam.
SPF and RFC 5322 headers
The MAIL FROM address of an email is also called the SMTP address. This address is recorded in the Return-Path header of the final email. On the other hand, the From field is the address that’s visible to the receiver when they get your email.
When both these addresses aren’t the same, a vulnerability arises that allows threat actors to take advantage and send phishing emails on your behalf. Usually, recipients don’t notice this mismatch in the MAIL FROM and From fields and get duped.
For example, SPF may authenticate the MAIL FROM address email1@example.com while the recipient sees the From header as email2@example.com. If there is no additional protocol like DKIM and DMARC to ensure alignment, cybercriminals can exploit this mismatch and send potentially fraudulent emails in the name of your business.
Return-path header
The receiving server adds the Return-path header that includes the MAIL FROM address. When the email is received, the receiving server checks this address to verify if the message has been sent from an authorized server. If the sending server’s IP is not listed in the domain’s SPF record, the check fails. Depending on the SPF settings, the email may be marked as suspicious (Softfail) or rejected (Hardfail).
Pair SPF with DKIM and DMARC
SPF alone is not enough. It has limitations like-
- It only checks the MAIL FROM and not the From header.
- It breaks with email forwarding.
- It is limited to 10 DNS lookups.
- It can’t validate email content or message integrity.
If you pair SPF with DKIM and DMARC, the shortcomings are compensated. DKIM helps verify whether the email content was altered in transit, while DMARC ascertains alignment between the MAIL FROM and From headers.