Sender Policy Framework(SPF) is a technological framework that helps to protect email senders and receivers against spam, spoofing, and phishing. In particular, it defines a way to validate the sending of an email message from an authorized mail server to detect forgery and prevent spam.
SPF Record: An SPF record is included in the DNS database of an organization. It is a specifically formatted version of a standard DNS TXT record.
How does it work ?
SPF lays out a system for receiving mail servers to check that incoming mail from a domain has been sent from a host allowed by the administrators of that domain.
- A domain administrator publishes the rules for mail servers allowed to send email from that domain. Its regulation is referred to as an SPF record and is classified as part of the overall DNS records of the domain.
- When an incoming email is opened by an inbound mail server, it will look up the domain rules in DNS. Then the inbound server compares the mail sender’s IP address with the approved IP addresses set out in the SPF log.
- The receiving mail server instead uses the rules defined in the SPF record of the issuing domain to decide whether to accept, deny or flag the email message otherwise.
Why use SPF ?
- SPF may not be fine, but it’s much safer for you than not to use it. By setting up SPF, emails can still be sent but doing so will improve your chances.
- Using an SPF scheme provides ISPs with an extra confidence signal to increase the likelihood that your communications will arrive in the inbox.
- The SPF framework can also help mitigate the bounce and error warning backscatter as spammers seek to misuse the domain.
Limitations
SPF is worth having, but it has limits you need to know about.
- SPF will not verify the header “From.” This header is shown as the real source of communication in most clients. The “header from” is not checked by SPF, but the “envelope from” is used to evaluate the domain received.
- SPF is going to break when an email is forward. At this stage, the ‘ forwarder ‘ becomes the message’s current ‘ sender ‘ and the new destination’s SPF tests may fail.
- SPF is deficient in the documentation, making it more difficult to manage.
“Mail from” and “From” header: which one SPF checks
Every email carries two sender addresses, and SPF only looks at one of them. Think of a letter. The envelope has a return address, which the post office uses if the letter cannot be delivered. The letter inside is signed by its author. Email works the same way.
- MAIL FROM (the envelope sender) is given in the SMTP conversation, before the message itself is sent. Bounces and delivery errors go back to this address, so it is also called the return path. The standard name is RFC5321.MailFrom, after RFC 5321, which defines SMTP.
- From (the header) is part of the message, next to Subject, Date and To. It names the author, and it is the address your mail app shows. Its standard name is RFC5322.From, after RFC 5322.
The SPF standard, RFC 7208, checks the MAIL FROM domain (and the HELO name the sending server introduces itself with). Both addresses can be set to anything by whoever sends the mail. So a spoofed message can pass SPF for the attacker’s own envelope domain while the From header shows your domain. DMARC closes that gap: RFC 7489 protects the RFC5322.From domain by requiring that it match (align with) a domain that SPF or DKIM has verified.
For the other half of email authentication, see how DKIM signs messages, and our explainer on DMARC, DKIM and SPF alignment.