SPF or Sender Policy Framework is an authentication system for email aimed at preventing spoofing. It verifies that the source of an email is legitimate, that is, its IP address is authorized. It is an open standard that protects from spammers and phishers.
The goal of it is to protect address holders from receiving email abuse by verifying every IP address from where an email is sent is authorized. The permission to send comes from the email Envelope From.
Sender Policy Framework uses a TXT record that belongs to a domain’s DNS (Domain Name Service). This TXT record details all the authorized hostnames and IP addresses that have permission to send emails from the domain.
These records are used to:
Prevent attacks– The risks of phishing, spoofing, and spamming is always present. SPF records make it more difficult for hackers to target you with these attacks.
Improve deliverability– Domains with SPF records have a lower bounce-back rate. Bounced emails can be flagged for spam, affecting your ability to communicate with your audience, which ultimately hurts your business.
Meet compliance- It helps with DMARC compliance, a recognized validation system that affects how emails are perceived.
SPF Mail Flow
To better comprehend Sender Policy Framework, you first need to know how SPF manages email traffic when it is first introduced. When a server receives an email, it investigates its return-path, which, as an example could be email@example.com. For the SPF check, these are the steps that are undertaken.
- The receiver’s server checks the DNS records for the SPF records corresponding to the example.com domain.
- The receiver’s server then investigates the SPF records for IP addresses that have been authorized by the domain to send emails.
- Once this check grants approval, the receiver’s server has the reassurance that the email emanates from a legitimate source, and processes it as such.
- If this check does not pass, the perception is that the email is suspicious, or from an unauthorized source. It is therefore processed as a failure.
Compliance with SPF
There are three tasks associated with compliance with Sender Policy Framework:
Policy publishing– Domains and hosts outline the machines that are allowed to send emails. This is done by adding their records to their DNS database.
Processing SPF information– Receivers use DNS queries then analyze the Sender Policy Framework information as required and respond based on the feedback.
Forwarding– Sender Policy Framework does not support mail forwarding. Instead, it either remails by using a local domain in place of the original sender, refusing it, or whitelisting it for acceptance as a forwarded message.
Once you finish authenticating your domain, an automated security feature is activated. It handles among others, your SPF records and DKIM records. We provide CNAME records that can be updated into your DNS records. Thereafter, you can include new IP addresses or make account updates and edits without revisiting your SPF records. If you do not wish to have the feature, you can disable automated security as you are authenticating the domain. This will switch you to TXT records from the CNAME records.
Custom SPF Records
When you have already defined your SPF record, proceed to add a unique string, ideally alphanumeric, before the a11 to authenticate the sending of emails through your account. If you have not created any SPF records, you must first write a TXT record using the values assigned to you as you authenticated the domain. Each account gets an exclusive TXT record to be used for their outbound messages. This record will appear as
v=spf1 include:u123456.wl.sendgrid.net -all
From the above example, you can see the SPF record that offers permission for outbound messages. The –a11, and not ~a11 signifies that this particular record is the only one in use in your domain for authenticating emails. If there are other authorized senders, remember to include them in this record for the sources to be authenticated.
One SPF1 record corresponds to only one domain. If you have more than one in your domain, merge it into one SPF record. There is an upper limit of 10 as single SPF records cannot support more.
Existing SPF records
If you have your SPF records in place already, you can add any new unique SPF into it seamlessly. You only need to add the new record before the –a11
v=spf1 a mx include:\_spf.google.com include:spf.protection.outlook.com –all
No Room Left for another Hostname?
If you are unable to add a new SPF hostname because you already have exhausted your allowance, you can give the new IP address special permission to handle outbound mail for your domain. To do this, you work with the ip4 mechanism.
You reserve the option of listing the IP address you want to enroll as a lookup. This means that only that address will have permission to send emails. The end result will look like this.
v=spf1 a mx include:\_spf.google.com include:spf.protection.outlook.com ip4:188.8.131.52 -all
If your account supports several dedicated IPs that all have to send permissions and wish to add more ip4 lookups, you can add and include them in your record, ensuring you separate them with spaces. Only include:hostname lookups have limited ip4 includes so you need not worry as your SPF1 records offer support for much more.