Sender Policy Framework (SPF) Records are used to validate the sources of sent email for a domain to ensure they are legitimate messages and not spam. The purpose of an SPF Record is to prevent email forgery. An SPF Record allows you to ensure that emails using your domain are authorized to do so. SPF Records are configured on your authoritative DNS server in the configuration settings and are a necessary requirement to successfully use our Email-to-fax service. Our Email-to-fax service has several steps that must complete for success. The very first step in the process is to check the SPF Record of the sending email address (domain). If the SPF Record check passes, the process moves on to the next steps of converting the file to necessary format and sending the fax. If the SPF Record check fails, the process stops and no further action occurs; hence, the fax you are attempting to send will fail. Therefore, it is imperative that you correctly configure your SPF Record for your domain. Since a domain name owner publishes an SPF record in DNS that declares which server(s) are permitted to send email on behalf of that domain, we use this information to essentially authenticate that the email is authorized to send on the domain’s behalf. This article aims to assist you in understanding SPF Records and aid you in configuring and verifying your SPF Record. The information contained in this article may differ slightly for your mail server but the principles will still apply.
The first thing you will need to determine is the number of SMTP servers that will be sending as @yourdomain.com. For example, if lisa@yourdomain.com is sending via Comcast SMTP servers (smtp.comcast.net), your SPF record will need to include IP 68.87.26.155; or to put it in context, ip4:68.87.26.155 (Comcast SMTP Server IP address). Additionally, if there are IP ranges in which mail can pass through, you will need to add those appropriate ranges. This information can typically be obtained through your email provider or system administrator if you do not readily have this information available. An IP range will have a forward slash at the end of the IP address. For example, Google’s SPF Record has this range: ip4:74.125.0.0/16.
The most common (easiest) entries you will need for your SPF records will closely mimic the VoIP Innovations eFax record, which contain basic A, MX, and IP listings and will be sufficient in most applications. Think of these as attributes. An SPF Record can contain any combination of these attributes meaning it can have one or several of them. For example, an SPF Record can contain an mx record, a single IP address, a range of IP addresses, a domain name, etc. Note that SPF Records will end with one of several methods, each containing the word ‘all’. These methods determine what happens if the email is received from a server not listed in the SPF Record. These methods are ‘-all’, ‘~all’, ‘?all’, and ‘+all’. The recommended method is ‘-all’ however, you may need to use ‘~all’ for success. Here is a description of each method: -all Fails (email is viewed as a forgery)
~all Soft Fail (the email is possibly a forgery, but the domain may be in transition)
?all Neutral (cannot determine if the email is a forgery or not)
+all Pass (this is never a forgery; do not use this method as it is only listed here for completeness)
Below are example SPF Records for Gmail and Apple as well as IntelliVoice eFax
Apple
v=spf1 ip4:17.0.0.0/8 ~all
IntelliVoice eFax
v=spf1 mx ip4:64.136.174.217 ip4:64.136.173.84 a:titaniumvfax.com ~all
Gmail*
v=spf1 redirect=_spf.google.com
Once you have configured your SPF Record, you will need to allow time for it to propagate.
The amount of propagation time is determined by the Time to Live (TTL) parameter you have configured in the server. The TTL is the length of time your record will remain in cache on systems requesting your record. Do not expect a previously failed SPF Record to take immediate effect once you have updated the record. The new record will not update until the current TTL has expired.
