Sender Policy Framework (SPF) with SocketLabs Email On-Demand
What is SPF?
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.
Two "From" Addresses?
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.
Who uses SPF?
Every major mailbox provider and anti-spam system, including Gmail/GoogleApps, Microsoft/Office365, Yahoo, AOL, Comcast, RoadRunner, Verizon, and many more have implemented SPF authentication checks.
SenderID, which was once implemented by its primary backer, Microsoft, is no longer widely deployed. Although some privately operated Exchange servers still implement SenderID, its use in spam filtering is rare.
How does SocketLabs help?
SocketLabs’ use of a variable encoded return path (VERP) allows us to automatically authenticate all outbound messages with our own SPF record. For more information about VERP addresses see our knowledgebase article: What is a Variable Encoded Return Path?
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 Email 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.
How do I create my own SPF record?
SocketLabs Email 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:
Keep in mind that changes to DNS records may take up to 48 hours to propagate throughout the internet.
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. The critical portion of our record is “include:email-od.com” which can be added to any pre-existing record for proper authentication. 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.
DMARC Aligned SPF
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 Domain. 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 are available:
The SocketLabs Email 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.