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.
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:
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:
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 email@example.com, or it can be more cryptic, like firstname.lastname@example.org. 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: email@example.com RCPT TO: firstname.lastname@example.org DATA Subject: Discover Ireland from $768* RT From: Oceanic Airlines <email@example.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:
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.