Getty Images
How SPF records prevent email spoofing, phishing and spam
Forged email has long been used by hackers to break into protected systems. Learn how the Sender Policy Framework protocol helps stop spoofing, phishing and other malicious mail.
Organizations have a right to be concerned about the never-ending flood of unwanted email messages, but it wasn't until about a decade ago that emerging standards for fighting spam, phishing and other malicious email came on the scene to give strong defenses to email-sending organizations.
Sender Policy Framework (SPF) is one of three internet standards for email authentication that help organizations fight against email fraud, spam, phishing and other attacks that depend on forging email. SPF is designed to be used along with the DomainKeys Identified Mail (DKIM) and Domain-based Message Authentication, Reporting and Conformance (DMARC) protocols. SPF provides email senders with a toolkit to prevent unauthorized users from using their domain to send forged or spoofed email.
The email security problem
Simple Mail Transfer Protocol (SMTP) has been how all internet email gets from sender to recipient since 1982, when the protocol was specified in RFC 821. SMTP offers no security features, instead relying on other protocols for email security. For example, encrypting email transfers is a matter of enabling the TLS protocol on the email server.
None of the standard email protocols provide mechanisms to validate whether a server is authorized to send mail on behalf of the email-sending domain, however. Email may be encrypted when it is being transferred between email servers, but that doesn't give recipients confidence that the email purported to originate from a legitimate organization is being sent by that organization.
Further complicating the problem is that any email validation tool must not negatively affect email deliverability. Whatever mail-sending organizations do to protect against email forgery must be implemented in a way that keeps email moving and doesn't affect delivery of legitimate messages.
Threats from unauthenticated email
When all email is handled as if it were legitimate -- which is what happens when no email validation or authentication protocols are in use -- it opens the door to several types of attack:
- Spam is unwanted email. Spammers send email for many reasons, sometimes to promote an otherwise-legitimate product. But, more often, it is to promote scams, gather information or attack the email infrastructure of an organization with the intent to disrupt email services.
- Spoofing is a technique email attackers use to convince the recipient that their messages are being sent by someone other than the apparent sender. Email spoofing is often a part of business email compromise and whaling attacks.
- Phishing is a type of attack carried out through email that aims to manipulate recipients into taking action that furthers the attacker's goals.
The combination of these protocols gives the ability to significantly reduce email threats. SPF works best when email-receiving entities run an SPF check on the domain owner or the email service provider that sends email on behalf of a domain owner.
What is SPF?
The SPF protocol is defined in RFC 7208, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1. SPF, with DKIM and DMARC, constitute the three protocols that, when used together, provide the most important email authentication method to protect against spam, spoofing and phishing. They provide email-sending organizations a set of tools to do the following:
- identify which mail servers are authorized to send mail for a domain, subdomain or hostname, using SPF records;
- include a digital signature in the header of outgoing messages, using DKIM records; and
- use DMARC to notify a receiving mail server how to process email from a domain or hostname when it is received from an unauthorized server or when the digital signature fails to authenticate.
All three of these protocols use DNS TXT records to store information about email servers that serve a domain, how email from those servers can be authenticated, and what to do when email is received from unauthorized servers or when messages fail to authenticate.
Setting up a DNS record for email authentication using any of these protocols is usually done by domain administrators. Email receivers can do an SPF check on inbound email to determine whether legitimate email is being delivered. The SPF check is done using a DNS lookup, which verifies there is an SPF DNS TXT record and validates that the email has been sent from a legitimate email server.
How does SPF protect against spam and phishing?
SPF is the first leg of the tripod on which email authentication protocols stand. Together with DKIM and DMARC, these three protocols give email-receiving organizations the information they need to prevent spoofing, spam and phishing. They resolve the following issues:
- Who is authorized to send email for a domain? SPF records identify the domain names and IP addresses of email servers authorized to send mail for the associated domain.
- What should be done when email is sent from an unauthorized domain? DMARC records specify what to do with an email message sent from an unauthorized email server based on the SPF record for the domain.
- How can individual email messages be authenticated? DKIM records provide a public key, which gives email-receiving organizations a way to authenticate individual email messages.
When an email-sending organization publishes its SPF DNS record, it gives email-receiving organizations a simple tool that can flag email for potential spam, spoofing and phishing attacks.
Since these records are all forms of the basic DNS TXT record, knowing how to add a DNS TXT record is a large part of the process of creating any SPF, DKIM or DMARC record.
SPF works when an email server receives messages from an email sender. If the receiving server supports SPF, it queries DNS for the domain specified in the return-path address in the message header. The query is for the SPF record, which indicates authorized email servers; if the email server that sent the message is in the SPF record, the message is SPF-authenticated.
Implementing SPF
Individuals or small organizations that get email through email service providers should check with their providers to make sure their email servers implement SPF. Most large email service providers currently use SPF, DKIM and DMARC to reduce email forgeries, spoofing and other malicious email.
Domain-owning organizations that want to implement SPF should consider a gradual rollout of SPF, DKIM and DMARC together. To support these protocols, the domain owner must do the following:
- publish DNS TXT records for each protocol; and
- configure email servers to accept and take action on email authenticated using these protocols.
SPF works best when it is deployed along with DMARC, which publishes the policies the domain owner has in place for unauthenticated email sent from the domain. Without DMARC, the receiving organization may have its own policies in place for how to handle unauthenticated email. If a message fails SPF authentication, however, the receiving server also queries the domain for a DMARC record to discover what action the domain owner wants recipients to take in that case.
