One of the many facets of secure, healthy email is to show your recipients that your email comes from a legitimate place. Email spoofing is a tactic someone uses to appear like someone else when they send an email. It is a very common tactic and is very simple for an attacker to automate and attempt in a passive manner.

One counter to this problem is to use Sender Policy Framework, or SPF.

SPF acts as a record that your recipients’ email systems can query to see if an email came from where it should. This can be from your domain address, like findingthelight.net, or from another address. That’s right: you can also designate other domains that are allowed to send email on your behalf. This is useful when you use third-party senders, like a marketing client. It’s up to you ( or your technical folks ) who is allowed to send on your domain’s behalf.

SPF records are setup on your Domain Name System server, or DNS server. This means recipient systems can easily query the record to see if the email they receive is from a legitimate source. SPF has many advantages because it works through DNS. The system is simple, so it is easy to manage. This also makes it a very lightweight system, so it works quickly and does not add a lot of overhead to an email transaction.

How SPF Works

Here is a simple example of how SPF works:

Like most technical solutions, SPF is not a “set it and forget it” tool; it must be managed. Whenever you have another domain that you want to send email for you, the SPF record must be updated with the IP address or domain name. Likewise, whenever you stop using another domain to send email for you, the SPF record should be updated and the portion with the new domain removed.

Either instance is important if you use one of many email solutions for sending large amounts of email and maintaining email reputation, such as SendGrid, MailChimp, or HubSpot. Any time you start or stop using such a service, you must update your SPF record. This is also true if you allow any outside organizations to send email on your behalf, such as affiliates, business partners, security appliances, or SMTP relays.

SPF Drawbacks

Intervening Systems

Unfortunately, there are no perfect solutions, and SPF has its downsides. One of the primary problems with SPF is that many organizations use security infrastructure that can be disruptive to SPF’s functioning. In the example above, the email transaction is simple, and there are no systems in between the transaction. Consider the following example:

The recipient’s intervening system becomes the receiver, and forwards the email to another of its email systems. The intervening system is not an authorized sender in your SPF record, nor can you account for all such systems. When that system forwards your email, it breaks the SPF contract. This creates a false positive: it appears like something bad has happened, even though your recipient’s systems have received the email.

Such an instance can hurt email deliverability, because the recipient may view your email as something malicious due to the false positive. The recipient’s systems may send your email directly to a Spam or Junk folder. Their systems may instead quarantine your email, requiring their administrators’ intervention to release. They may even outright reject your email. In all these cases, the intended recipient is likely to never see what you sent them.

This does not mean that you should not implement SPF. Most systems are checking to see if your messages are sent from a source that matches your SPF record. If you don’t have one at all, your email may get the same treatment as if the SPF check was a bad one.

Identification, Not Authorization

Another issue occurs under a very specific circumstance. SPF does not directly stop email spoofing; it is not a strict authentication mechanism. If someone wants to spoof an email from you, they still can, even if you have implemented SPF. SPF only provides a record of who you say can send email for your domain; it does not directly stop it. In the same way, SPF does not stop someone sending email if they compromise a legitimate email account in your domain.

No Reporting

The last problem with SPF is that there is no in-built reporting mechanism regarding its use. While there are methods of obtaining such reports and reporting capabilities, these are a part of a complete email health and security approach. SPF alone is not enough to provide the most risk mitigation, and reporting is a major part of that.

Summary of SPF

Here is a summary of SPF capabilities and advantages:

• Provides a record of IPs and domains that can send your email.
• Easy to setup and add in DNS.
• Fulfills a soft requirement many recipients are looking for.
• Overall, provides some security and email deliverability improvements.

Here is a summary of SPF shortcomings:

• Many forwarding systems break the policy.
• Requires management: adding and removing domains authorized to send on your behalf.
• Does not stop issues when an email account itself has been compromised.
• Does not provide strict authentication; spoofed emails can still be sent.
• No in-built reporting mechanism: email health must be monitored separately.

Despite its drawbacks, SPF is a simple, lightweight addition that can make a big difference. Implementing SPF can help your email security, reputation, and deliverability. However, SPF should not be implemented on its own. Other tools like DKIM and DMARC can help cover each others’ gaps and better protect your email.

Do you have issues with your email deliverability or security? We can help. Contact us today for a free consultation.