Sender Policy Framework (SPF) is an open standard specifying a technical method to prevent from address forgery in email messages. SPF allows the owner of a domain to specify which mail servers they use to send mail from that domain. Before diving further into SPF, it is first critical to understand that email messages actually have two different "From" address.
Email messages contain two “from” addresses, the first is the return path address. It is a value that is also called the “envelope from” or "mail from". The return path address informs receiving mail servers where to return, or bounce, a message back to if there is an error. The return path address is not displayed to the recipient.
The second address is the one that is visible to recipients and is located in the headers of the email message. It is also called the “header from” address or the "friendly from" address. Since this is visible to recipients it is the only from address that most people are aware of in an email.
Spf specifically protects and authenticates the return path address used in the message delivery process
The biggest complaint about SPF authentication technology is that it does not really protect what many consider the real "From address" field because it protects the return path which is not displayed to the recipient. For this reason there was once a technology called SenderID. It is a now defunct framework but it was very similar to SPF, as it also attempted to prevent address forgery. SenderID differed when compared to SPF in that SenderID tried to protect the header from address, the one visible to recipients. SenderID was also referred to as version 2 of SPF (SPFv2) before its demise.
Although some privately operated Exchange servers still implement SenderID, its use in spam filtering is rare.
Every major mailbox provider and anti-spam system have implemented SPF authentication checks, including:
SocketLabs’ use of a variable envelope return path (VERP) allows us to automatically authenticate all outbound messages with our own SPF record. Click here for more information about VERP addresses.
No actions are required to pass SPF authentication checks that are performed by most domains.
Despite this fact, SocketLabs still recommends that all customers create an SPF record for any sending domain that authenticates the SocketLabs on-demand platform.
This is partially due to outdated systems that still implement SenderID. It is also something that we've seen a few providers have added in to the anti-spam process as a last resort when trying to make an inbox/spam folder placement decision about a message they are not sure is authentic.
SocketLabs On-Demand customers should deploy a TXT DNS record to any domain that will be used in the header from address field of messages. It is important to note that further steps may be required to authenticate other forms in which messages may be processing on behalf of your domain outside of the SocketLabs service.
If you do not already have an SPF record for your domain:
1) Log in to the administrative area for your domain.
2) Locate the page from which you can update the DNS records.
3) Create a TXT record containing this text:
v=spf1 include:email-od.com ~all
Keep in mind that changes to DNS records may take up to 48 hours to propagate throughout the internet.
The critical portion of our record is “include:email-od.com” which can be added to any pre-existing record for proper authentication.
If you already implement an SPF record on your domain then you will need to merge the provided SocketLabs include statement into your existing record. Proper SPF syntax permits only a single TXT DNS SPF record per domain.
For example if your domain already has an SPF record that looks something like this (authenticating Google Apps):
v=spf1 include:_spf.google.com ~all
Adding in our record would change the above example to:
v=spf1 include:_spf.google.com include:email-od.com ~all
This would allow both SocketLabs and Google Apps to transmit messages on-behalf of your domain.
Adding a valid SPF record to your domain that includes the SocketLabs platform (email-od.com) is a best practice, but is not enough to achieve a passing SPF alignment result for DMARC. By default, the "relaxed" alignment settings in DMARC require that the organizational domain used in both of the two "From" addresses are the same. That means if the domain you use in your from address in the message headers is [ @example.com ], then your return path address also needs to use an email address like [ @example.com ] or a subdomain such as [ @bounces.example.com ].
To help SocketLabs customers achieve passing SPF records that meet DMARC requirements we offer a feature called Custom Bounce Domains. This allows you to white-label the domain portion of the VERP address used in message delivery.
To check that you record is properly established and syntactically valid you can use any of the following third-party resources:
For more information about SPF and SenderID, the following resources
The SocketLabs On-Demand Support Department is always available to assist you with any further questions that you may have. Contact us at firstname.lastname@example.org if you require assistance.