What is SPF (Sender Policy Framework)?
SPF is a DNS TXT entry for your domains and subdomains that list the services and individual IP addresses that you use to send emails.
v=spf1 include:_spf.google.com include:_something.amazonaws.com ~allHypothetical SPF record. This says that I use Google and AWS to send emails
SPF helps prevent email address spoofing because ISPs can look up the TXT record and compare with the email headers to verify that I acknowledge that I want Google or AWS to send emails for me.
Here is a larger SPF record. Note that in the block above I have 4
include: lines. That means I have 4 SPF records for my domain.
# infoentropy.com v=spf1 include:_spf.google.com # 1 include:u123456.wl.sendgrid.net # 2 include:other.service.com # 3 include:other.service2.com # 4 -all
Now, a problem: according to specificiations, each domain can have a maximum of 10 SPF records in each DNS TXT record. If you have more than 10 SPF records the ISP could ignore the entire DNS record or only look at the first 10 while ignoring the rest.
If I used my root domain for all email services, I would reach the 10-record limit quickly. Look at the table below — a medium-sized company could end up using many different SaaS platforms, each of which vies for space on the root domain.
|Software service||Department||what do they send?|
|Blog platform (WordPress, Squarespace, etc)||Marketing||Blog announcements|
|CRM (Salesforce, Hubspot, etc.)||Sales||Correspondence with customers|
|e-commerce (Squarespace, Magento, etc.)||Sales||Purchase receipts|
|Customer Support (Zendesk, etc.)||Support||Help tickets|
|Surveys (SurveyMonkey, etc)||Miscellaneous||Product survey, customer satisfaction survey, etc.|
|Transactional emails (Mailgun, Sendgrid, Sparkpost, AWS SES)||Engineering||Things related to your apps|
|Engineering Internal Services (Jenkins, datadog, github)||Engineering||Stuff engineers look at|
|Legal things (DocuSign, etc)||Legal|
|Finance (ADP, Carta, etc)||Finance|
|More stuff! JIRA, ASANA, Slack, BOX, Dropbox||Everyone|
This is 13 SPF records trying that would need SPF records. However, not all of these services necessarily need to be on the root infoentropy.com domain. I can have more than 10 SPF records by using multiple subdomains. Each subdomain can have 10 records.
Use multiple email subdomain names to stay under the SPF 10-record limit.
My proposed solution is to, loosely, divide my email domains according to business function: sales, customer support, marketing/bulk email and product, and internal.
Doing so will (1) give recipients have some clue of who is sending the email and (2) allow you to identify vendor deliverability issues. For shared SaaS services you might include that sender in more than one subdomain SPF record. SurveyMonkey, for example, might be used for more than one business function.
- Sales: biz.infoentropy.com
- Help: help.infoentropy.com
- Transactional (password reset, billing?)
- AWS SES*
- Marketing: email.infoentropy.com
- High volume bulk email
- Product: app.infoentropy.com
- Transactional (you did something in the app!)
- Sendgrid/Mailgun/AWS SES*
- Notifications (X sent you a message)
- Sendgrid/Mailgun/AWS SES*
- Internal/corporate: corp.infoentropy.com
- Gmail/Outlook 365?
*Single service used on multiple subdomains.
In this situation I need 5 separate SPF TXT records, 1 for each domain. Each domain lists the specific services that I use to send emails.
# help.infoentropy.com v=spf1 include: _spf.zendesk.com # 1 Zendesk include: _spf.amazonaws.com # 2 AWS -all
In this case I only use 2 services to send email@example.com emails. If I tried to send with the address firstname.lastname@example.org via Mailchimp, the verification would fail DMARC and the email would end up in the SPAM folder.