Enabling SPF | Predictive Response
- If you already have a SPF record in place, add the following.
- Note – if your SPF record already includes ~all, you can omit adding it again.
- If you do not have a SPF record in place, add this:
v=spf1 include:spf.predictiveresponse.net ~all
Enter the appropriate statement as a TXT record in your DNS records. You can test your entry by using this link:
The following success message should display:
SPF record passed validation test with pySPF (Python SPF library)!
You can add other domains as needed.
The Sender Policy Framework (SPF) is an open standard specifying a technical method to prevent sender address forgery. More precisely, the current version of SPF — called SPFv1 or SPF Classic — protects the envelope sender address, which is used for the delivery of messages.
Even more precisely, SPFv1 allows the owner of a domain to specify their mail sending policy, e.g. which mail servers they use to send mail from their domain. The technology requires two sides to play together: (1) the domain owner publishes this information in an SPF record in the domain’s DNS zone, and when someone else’s mail server receives a message claiming to come from that domain, then (2) the receiving server can check whether the message complies with the domain’s stated policy. If, e.g., the message comes from an unknown server, it can be considered a fake.
Why should I implement SPF?
One reason to implement SPF is to reduce the chance that spammers and phishers will choose your domain as their “cover” domain.
This is because spammers will seek domains which do not implement any form of email authentication as there is a higher chance they will get through spam filters at the receiving domain. Without SPF/email authentication when the remote mail server receives an email it will have no way to verify or check whether the email is likely to be genuine or not and will therefore have to rely on unreliable content filtering to establish whether the email is likely to be spam or not. Content filtering relies on patterns like words or phrases within the body or subject of the message and the receiving mail server will make a decision on whether your email is genuine purely on the content of your message. With SPF the spam filter at the remote mail server will be able to make a more informed decision as to whether the message is genuine or not.
If you do implement SPF however it is still possible that spammers will attempt to use your domain as their cover domain and attempt to deliver messages using it. When this happens the remote mail server will check against your SPF record and recognize that the source of the email it has just received is not authorized to send email for your domain and is likely to block or quarantine your message. This means that if your customers or potential customers are the target of the spam the vast majority of the emails will be blocked which will reduce the impact to any of your non internet savvy client base. In addition to helping your own client base and protecting your own brand you are also allowing the wider internet community to cut down on the amount of spam on the internet by being able to pick up on more of it and block it.
SPF can also help you reduce the amount of users that blacklist your domain. Let’s imagine a scenario when you have not implemented SPF, a spammer has successfully delivered email to many domains around the word seemingly coming from your domain/brand. In this instance there are likely to be many people around the world marking these emails as spam. Many spam filters use Bayesian techniques for the spam filter to “auto learn”. This means that once a user has marked an email coming from your domain as spam, the spam filter will analyse every part of the email, looking for phrases, html patterns, images and the from domain and email address. If the spammer is sending many different emails using your domain one of the few things that will remain consistent will be your domain name and the spam filter will pick up on this. If you then send the mail server that has auto learn about your domain and the large amount of spam coming from it, a genuine email, and the chances are it will be blocked. The chances of this happening will be much reduced if you had implemented SPF.
Spam filters don’t only negatively score emails which fail the SPF check. If an email from a domain passes an SPF check, it is quite feasible that the administrator of that spam filter has added a policy to positively score that email. This means that genuine email from your domain is MORE likely to be delivered to the inbox of the person you are sending an email to.
Information: For more information on email headers, click here.
You can add other domains as needed.
Step Three: Click here to submit a support ticket.
Step Four: We will verify the entry and enable SPF for your domain.
In summary, the reasons for implementing SPF are:
- Your domain is less likely to be used by a spammer.
- If your domain is used by a spammer, the emails are far more likely to get blocked.
- You help reduce the amount of overall spam on the internet.
- Your domain is less likely to be blacklisted by Bayesian spam filters.
- Genuine email is more likely to get through spam filters.
Example Sender Formats
If you choose to have your emails appear to come directly from you as the sender you will need to enable SPF and provide an SPF record in your DNS configuration. You need a SPF record that returns PASS in order to maximize your deliverability
Without SPF, your outgoing email will display this sender info.
Sender Name <firstname.lastname@example.org> on behalf of Sender Name
With SPF, your outgoing email will display this sender info.
Sender Name <email@example.com>
While sending with SPF, your emails will have the same appearance as if they were sent from your desktop mail program, however, if you do not also set up the SPF record in your domain DNS, businesses that filter for SPF will reject your messages.
If you want to learn more about SPF, go to http://openspf.net. This website includes information on:
- SPF Record Syntax
- Testing Tools
- Information on common mistakes
- Resource for SPF implementation
- SPF Specifications, and more
What are DNS Records?
DNS records are used for mapping URLs to an IPs. Located on servers called the DNS servers, these records are typically the connection of your website with the outside world. Requests for your website are forwarded to your DNS servers and then get pointed to the WebServers that serve the website or to Email servers that handle the incoming email.
The DNS Record type required for the Sender Policy Framework (SPF) is known as a TXT Record. A TXT record allows an administrator to insert arbitrary text into a DNS record. For example, this record is used to implement the Sender Policy Framework specification.