How to set up your email domains and SPF records

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 ~all

Hypothetical 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 serviceDepartmentwhat do they send?
GmailEveryoneall emails
MailchimpMarketingEmail blasts
Blog platform (WordPress, Squarespace, etc)MarketingBlog announcements
CRM (Salesforce, Hubspot, etc.)SalesCorrespondence with customers
e-commerce (Squarespace, Magento, etc.)SalesPurchase receipts
Customer Support (Zendesk, etc.)SupportHelp tickets
Surveys (SurveyMonkey, etc)MiscellaneousProduct survey, customer satisfaction survey, etc.
Transactional emails (Mailgun, Sendgrid, Sparkpost, AWS SES)EngineeringThings related to your apps
Engineering Internal Services (Jenkins, datadog, github)EngineeringStuff engineers look at
Legal things (DocuSign, etc)Legal
Finance (ADP, Carta, etc)Finance
Recruiting emailsHR
More stuff! JIRA, ASANA, Slack, BOX, DropboxEveryone
Various outbound emails & vendors that might use your domain name

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
    • reports@biz.infoentropy.com
    • Sales
      • hubspot
      • salesforce
      • squarespace
      • SurveyMonkey*
  • Help: help.infoentropy.com
    • support@help.infoentropy.com
    • Support
      • zendesk
    • Transactional (password reset, billing?)
      • AWS SES*
  • Marketing: email.infoentropy.com
    • deals@email.infoentropy.com
    • High volume bulk email
      • Iterable
      • Mailchimp
      • Pardot
      • Marketo
    • Surveys
      • SurveyMonkey*
  • Product: app.infoentropy.com
    • notifications@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
    • jeff@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 something@help.infoentropy.com emails. If I tried to send with the address jeff@help.infoentropy.com via Mailchimp, the verification would fail DMARC and the email would end up in the SPAM folder.

How to make your logo visible in the inbox with a BIMI record

I just heard of BIMI for the first time a few weeks ago. Most of the resources I can find are trying to sell DMARC management services. While these services are useful and valuable I was trying to figure out some rules of thumb to self manage my own DNS with regard to DMARC/DKIM/SPF/BIMI compliance.

First thing to note is that in order to get your email logo on the inbox, you need to comply with BIMI standards. That means you need to:

  • Create a BIMI record
  • Configure domain names
  • Configure DKIM & SPF
  • Create your DMARC rules
  • Monitor your DMARC
  • Lock down your DMARC

Set up your BIMI record

I have this step early in the blog because you can set it’s the simplest step. You won’t get the snazzy BIMI logo until you complete all of the steps.

Create an SVG version of your logo and upload it somewhere on your CDN or wherever you serve your images. You can probably put it in the same directory as the ubiquitous favicon.ico file.

Add a TXT record to your DNS that points to the newly uploaded SVG file.

default._bimi.acme.com

v=BIMI1; l=https://cdn.acme.com/_email/logos/acme-icon.svg

Configure your domain names

If you’re putting together your email system from scratch, (i.e. you work for a 1-10 person startup and you happen to be the devops guy) see other post for guidance on how to Setup your email domains and SPF records. This is a hairy process that IT people need to be involved with because it requires mucking with DNS and planning out how you will send emails in the future. Do it right early!

Configure DKIM & SPF for your domains.

In order to pass DMARC both your SPF and DKIM need to validate.

The SPF record means that you added the 3rd party services to your DNS, as described above.

The DKIM is a signature key that you share with your email sending service(s). These services will add the DKIM signature to the email headers of every message they send for you so that recipient ISPs can verify that emails that have your domain on it are coming from you.

In order to qualify for BIMI, you need to make sure the SPF and DKIM are “aligned“. For example, f you use Sendgrid, you should have sengrid in your SPF and sendgrid in the DKIM signature.

Create your DMARC rules

In order for your logo to show up on emails, your DMARC must be set to “quarantine” or “reject”.

Now, monitor the results of your DMARC (SPF+DKIM) configuration

Using a service such as Valimail, you can get reports of which domains and IP addresses are attempting to send mail using your domain names. If you recognize IP addresses or domains that are “failing” that should not be, then you need to check configuration of those services. In keeping with the Sendgrid example, if you are using them as your provider and you see a sendgrid.net in your “Mostly failing IPs” box then something is wrong with your SPF/DKIM DNS configuration.

Definitely a phish/spam/spoofer

Once DMARC you have quarantine on, and your SPF and DKIM are “aligned” your BIMI logo might start showing up!

I say “might” because not all email providers suppport the the BIMI standard. Anecdotally, as of 2020, I do believe Hotmail, Yahoo mail have logos in emails. Gmail has its own brand of JSON-LD syntax to jam logos into the inbox