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

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,



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, 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, picks a name associated with Oceanic Airlines. This can be descriptive, like, or it can be more cryptic, like 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:

Subject: Discover Ireland from $768* RT
From: Oceanic Airlines <>
<Everything else in the email>

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 against the sending domain of 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
  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.


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 (4)
  1. Paul de souza says:

    Thank you. Ive been everywhere trying to understand all this. This makes perfect sense.

  2. Guido says:

    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., so that the SPF checks are actually two? What if one fails and the other suceeds? Thanks! Guido

  3. Michal says:

    thanks for the article, as well as for the one about DKIM. I have gone through several other ones on this topic and would like to ask you for a clarification and your opinion:
    The model situation is the following: I own a domain and would like to provide bulk e-mail services to my client who owns a domain Let’s presume that I, myself, use a SMTP server provided by my webhosting.
    Now, what DKIM and what SPF records should be published on whose DNS?
    I would suggest that I put my public DKIM to my DNS. Then I and my client, both, put a SPF record to our individual DNS which will consider for my webhosting’s SMTP server (i.e. to make this SMTP server an official sender for my and my client’s domain). Finally, I will send out e-mails signed by my DKIM private key and the 5321.From would be “” whereas the 5322.From would be “”.

    Will this do? So the DKIM of my client is never used? And will gmail show a message that “..this e-mail has been sent using the domain”?

    1. tzink says:

      You should publish this for your SPF: 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) IN TXT “v=DKIM; k=rsa; p=[public key]” (without the square brackets)

      Your client should publish this in their SPF: IN TXT “v=spf1 -all” (or ~all)

      And this in their DKIM: IN CNAME

      You can then send out emails with 5321.MailFrom “” and 5322.From “”, but you have to sign with DKIM signature “s=webhosting;”. That will align the DMARC record on the DKIM domain and 5322.From address.

Comments are closed.

Skip to main content