Share via

How to set up your SPF records if you are outsourcing some, or all, of your email

  • Article

I thought I would do a few posts on email authentication, specifically, how to ensure that you have good sending reputation and the proper way to set up your SPF records. In future posts, I plan to get into how to set up your DKIM records as well as your DMARC records in the case that you are an organization, or even a small sender, who wants to have others send on behalf of you.

What do I mean by this?

Suppose you are a large airline, OceanicAirlines.com.

image

 

You regularly communicate with your customer base when they purchase tickets from your website and they get an email confirmation, or send them an email alert the day before their flight leaves about online check-in.

However, you also want to send marketing email to your customers. You do this on a regular basis in order to advertise that you have a deal upcoming for nationwide flights to Salt Lake City, or about last minute holiday deals.

However, OceanicAirlines.com knows that sending bulk email is difficult:

  1. It has to process complaints.
  2. It has to constantly maintain its IP reputation.
  3. It has to constantly process bounce messages.

These are just some of the things it has to do when sending bulk email. Oceanic decides to outsource its advertising email campaigns to Big Communications, Inc. They specialize in sending bulk email; they are good at it. You just give them a list of recipients and craft the email, and they will take care of the rest. If you’re a bad sender, they’ll kick you off their list.

 

Okay. So Oceanic is outsourcing its email campaigns to Big Communications. How does each party set up its SPF records so that they pass SPF checks?

The short answer is: It’s really easy.

The longer answer is: It’s really easy if you just want to pass SPF. It’s more complicated if you also want to pass SenderID.

To pass an SPF check, remember that in email, there are two From: addresses:

  1. The SMTP MAIL FROM, otherwise known as the RFC5321.MailFrom. This is the email address that is used to do SPF checks, and if the mail cannot be delivered, the path where the bounced message is delivered to. It is this email address that goes into the Return-Path in the message headers.

  2. The From: address in the message headers, otherwise known as the RFC5322.From. This is the email address that is displayed in the mail client.

Frequently the 5321.From and 5322.From are the same, but not always. They can be different, depending on the circumstances.

To pass the SPF check, BigCommunications.com picks a name associated with Oceanic Airlines. This can be descriptive, like oceanic.airlines@bigcommunications.com, or it can be more cryptic, like email-bounces-10ask213@bigcommunications.com. This email address goes into the RFC5321.MailFrom.

In the RFC5322.From goes Oceanic Airlines’s From: address. This is the one that is seen by email users.

The email is sent from BigCommunication’s email servers, and the SMTP transaction looks like this:

HELO mail.bigcommunication.com
MAIL FROM: oceanic.airlines@bigcommunications.com
RCPT TO: user@example.com
DATA
Subject: Discover Ireland from $768* RT
From: Oceanic Airlines <oceanic@news.oceanicairlines.com>
<Everything else in the email>
.
QUIT

If you look at the message below, you can see that the From: address in my email client shows the RFC5322.From address. This is exactly what Oceanic wanted.

However, when my email server gets the message, it did an SPF check on the connecting IP (which belongs to BigCommunications.com) against the sending domain of bigcommunications.com. This will pass an SPF check which is what we want. This domain does not show up anywhere in the email client, but spam filters use it to authenticate the message with SPF. It is transparent to the end user.

The lesson is this: If you want to have your mail sent by someone else on behalf of you, and all you want to do is pass an SPF check:

  1. Make sure that the RFC5321.MailFrom belongs to the actual sender (i.e., the email servers that emit the email to the Internet). It must not be the “legitimately spoofed” domain (in the example, it must not be OceanicAirlines.com).
  2. Make sure the RFC5322.From belongs to you as because that is what will show up in the user’s email client, and it is this brand you want to reflect to the user.

Of course, the bulk email sender – who is responsible for actually sending your email out to the Internet - must publish SPF records.

image

See? It’s easy to pass an SPF check this way! But it’s not the end of the story. We still have to deal with the SenderID, DKIM, DMARC, and the potential problem of abuse.

 

Quick Navigation

Comments

  • Anonymous
    February 24, 2016
    Thank you. Ive been everywhere trying to understand all this. This makes perfect sense.

  • Anonymous
    April 28, 2016
    Hi Terry! Thank you for this great explanation! When does the SPF record on my server (ie. on Oceanic's server) come into play? Is it checked by the mail server at the same time as the sender's (ie. bigcommunications.com), so that the SPF checks are actually two? What if one fails and the other suceeds? Thanks! Guido

  • Anonymous
    December 05, 2016
    The comment has been removed

    • Anonymous
      December 05, 2016
      You should publish this for your SPF:mydomain.cz IN TXT "v=spf1 ip4:[your IPs] -all" (or ~all, and without the square brackets)And this in your DKIM (using an example selector of webhosting)webhosting._domainkey.mydomain.cz IN TXT "v=DKIM; k=rsa; p=[public key]" (without the square brackets)Your client should publish this in their SPF:myclient.cz IN TXT "v=spf1 include:mydomain.cz -all" (or ~all)And this in their DKIM:webhosting._domainkey.myclient.cz IN CNAME webhosting._domainkey.mydomain.czYou can then send out emails with 5321.MailFrom "myself@mydomain.cz" and 5322.From "client@myclient.cz", but you have to sign with DKIM signature "s=webhosting; d=myclient.cz". That will align the DMARC record on the DKIM domain and 5322.From address.