Since your new website resides or will reside, on Campus Suite servers, it will need to send an email on your behalf from time to time. For example, if a new user is added to the system, Campus Suite will send an email to the administrator on your team letting them know. There are various messages that Campus Suite will send out to users in your organization as necessary and on your behalf. In this case, it needs to be recognized as an authorized sender.
The purpose of an SPF record is to prevent spammers from sending messages with forged 'From' addresses at your domain. Recipients can refer to the SPF record to determine whether a message purporting to be from your domain comes from an authorized mail server.
For example, suppose that your domain example.com uses Gmail. You create an SPF record that identifies the Google Apps mail servers as the authorized mail servers for your domain. When a recipient's mail server receives a message from email@example.com, it can check the SPF record for example.com to determine whether it is a valid message. If the message comes from a server other than the Google Apps mail servers listed in the SPF record, the recipient's mail server can reject it as spam.
If your domain does not have an SPF record, some recipient domains may reject messages from your users because they cannot validate that the messages come from an authorized mail server. We have seen important messages sent from Campus Suite never be delivered because an SPF record does not exist, or there is an improperly configured SPF record. It's important to identify this early on so messages get delivered in a timely manner.
Very often, the IT person at your organization may not be familiar with SPF records, especially if someone else manages your DNS. Many schools use upstream providers to manage their DNS and this information should be provided to them.
The SPF is a TXT type record that specifies what servers may send an email on behalf of your domain. In the figure below, you can see how a system uses SPF to make decisions about how to route an email.
If you follow the flow, you will see that the recipient server (2) tries to verify the SPF record or Sender ID Framework in Microsoft’s nomenclature. The pass/fail status of the SPF record is then passed from the check stage in step 3 to the reputation data filter in step 4. If you fail SPF authentication, most ISPs will give you a poor reputation score and route your email to the spam or junk folder — some may even just block the email entirely.
Here is an example of a SPF record, again using example.com:
example.com. 3600 IN TXT "v=spf1 include:_spf-a.example.com include:_spf-b.example.com include:_spf-c.example.com include:_spf-ssg-a.example.com include:spf-a.hotmail.com ip4:18.104.22.168 ip4:22.214.171.124 ip4:126.96.36.199 ip4:188.8.131.52 ip4:184.108.40.206 ~all"
This is a DNS TXT record that specifies what IPs and other systems are allowed to send an email on behalf of microsoft.com. Here you will notice that the SPF record uses IP addresses and include statements, but you can also simply include A or MX records.
Fortunately, there are many SPF wizards available to help you automatically generate these records.
Google Apps Customers
Find this beneficial information on understanding SPF records and adding them in your domain:
Creating SPF Records
Here's a link for Google Apps customers to create an SPF record in their DNS:
Here's another tool we have found very helpful for looking to see if you already have an SPF record in your DNS, and it can also assist you in creating one to add to the interface you use to manage your DNS.
Common SPF Errors
If you cannot configure SPF records correctly, you are better off not having them at all. As with the reverse DNS issues, if you use shared hosting or have multiple sites on the same domain, you need to check what IP your email uses. Many control panel systems will include the IP for the domain’s DNS A record, but for a site on a dedicated IP address, this may not be the IP used by the email system. In these cases, you need to add the ip4 record with the server’s main IP.
Don’t forget 3rd parties that may send an email on your behalf. For example, if you use MailChimp, Sendgrid or some other email delivery service, they should provide you with an include record to add to your SPF TXT statement.
If you use your ISP’s SMTP server, Gmail or similar 3rd party email service provider, you will need to get them to provide you with an SPF include record. I often see marketing firms using their web servers for sending out campaigns but then use Gmail for their own email. Google provides some good info on SPF records if you use their email services
AGAIN, you are often better off not having an SPF record at all than having an incorrect one. If you have an incorrect SPF record, some systems will reject your email while if you simply lack an SPF record, your message is accepted but undergoes more rigorous spam checks.