Terry Zink: Security Talk

Discussing Internet security in (mostly) plain English

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

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

  • Comments 2

In my previous post, I discussed how to structure email such that if it comes from a 3rd party on behalf of you, it will pass an SPF check.

But what about passing a SenderID check?

To solve this, we first have to remind ourselves what SenderID is. Let’s go back to the previous post where BigCommunications.com was sending on behalf of Oceanic Airlines (sample email here). Below was the email transaction:

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

To pass an SPF check, the connecting IP address is checked against the domain in the RFC5321.MailFrom address, in this case bigcommunications.com. Suppose that the connecting IP is 1.2.3.4 and the SPF record for bigcommunications.com is the following:

bigcommunications.com
”v=spf1 ip4:1.2.3.0/24 –all”

Because 1.2.3.4 is in 1.2.3.0/24, the SPF check passes.

SenderID is different. The process of extracting which domain to check is paraphrased (for simplicity) as follows:

  1. Check to see if the Sender: field exists. If so, use the domain in this field.

  2. If not, use the domain in the From: field.

In the above example, since there is no Sender: field, the domain in the From: field is news.oceanicairlines.com.

SenderID next checks the SenderID record in DNS. If it does not exist, it falls back to the SPF record.

In the above example, suppose that news.oceanicairlines.com does not publish SenderID records. But it does publish SPF records, per the following:

news.oceanicairlines.com
v=spf1 225.18.0.128/25 –all

Because the connecting IP of 1.2.3.4 is not in the range 225.18.0.128/25, this message will fail a SenderID check. Furthermore, it hard fails a SenderID check which weights heavily in spam filters to mark a message a spam and go to the junk mail folder.

How can we fix this?

The first option is to not fix it.

SenderID is a standard proposed by Microsoft which protects against spoofing the RFC5322.From address, the one that the user sees in their email client. However, SenderID does not have the same level of widespread industry deployment that SPF or DKIM do.

SenderID was primarily used in Hotmail and on-premise Exchange servers deployed locally within organizations. However, during the past year, Hotmail has stopped checking SenderID and starting checking SPF as that is what is what is required by DMARC. This leaves only on-premise Exchange servers.

The Exchange server MTA has its own built-in spam filter, Smartscreen. However, it is not dynamically updated the way that other services do (like Hotmail, Yahoo, Gmail, or our own service Forefront Online/Exchange Online). Therefore, most on-premise Exchange deployments will probably augment their filtering with another service that updates regularly. The reliance upon SenderID is then diminished since the other spam filter will already catch most of the spam. Therefore, many Exchange administrators may not even have the SenderID agent enabled, although others may enable it as a fail-safe against spoofed email.

But if SenderID is not used by Hotmail and may or may not be used by on-premise Exchange installations, senders may decide that it is not worthwhile complying with SenderID because the potential fallout is small.


The second option is to create SenderID records in DNS.

You may decide that creating SenderID records is worthwhile. There are advantages to doing it:

  1. You will ensure that you do not fail when delivering to email servers protected by Exchange.

  2. It’s good practice for passing DMARC.

 

To comply with SenderID:

    1. First, you should separate out your corporate email from bulk-advertised email. That is, if you send email from corporate users, send it from user@oceanicAirlines.com. For mail that comes from a third party, delegate a subdomain like news.oceanicairlines.com. These should be kept separate.

      This can even be taken a step further, and specialized messages like flight confirmations and alerts can be sent from alerts.oceanicAirlines.com, or confirmations.oceanicAirlines.com. This separates out subdomains by specialized function.

      But the key is to delegate a subdomain for mail sent by 3rd parties.

    2. Second, publish a SenderID record for this subdomain that contains the SPF record for this 3rd party. You can either put their IPs in there directly, or better yet, include them in the SenderID record. For example:

      news.oceanicairlines.com
      ”v=spf2.0/pra include:1.2.3.0/24 –all”

      OR

news.oceanicairlines.com
”v=spf2.0/pra include:bigcommunications.com –all”


The spf2.0/pra means “This is a SenderID record. The PRA means to apply this to the domain in the Purported Responsible Address, which is either the domain in the Sender: (rarely) or RFC5322.From (usually).”

That’s it. That’s how you comply with SenderID. It does mean that you must create and delegate a subdomain for 3rd parties to send on behalf of you and publish their SPF records in that subdomain’s SenderID record. If you ever change 3rd parties, you must update this SenderID record. And if this 3rd party ever starts sending spam using your subdomain, it will pass a SenderID check (it can also pass an SPF check).

However, even if it does go rogue, it can only pass a SenderID check for this delegated subdomain. In this example, it can only SenderID pass news.oceanicairlines.com. It will not pass oceanicairlines.com, confirmations.oceanicairlines.com, and so forth. The damage is contained (and can be revoked by unpublishing the IPs from the SenderID record).

 

Let’s go back to the original example:

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

For a machine that is checking SenderID, it extracts the domain in the From: field, news.oceanicairlines.com. It then takes the sending IP, 1.2.3.4 and does a SenderID lookup:

news.oceanicairlines.com
”v=spf2.0/pra include:bigcommunications.com –all”

The “include” says to do a SenderID lookup for bigcommunications.com:

bigcommunications.com
”v=spf1 ip4:1.2.3.0/24 –all”

SenderID looks for the spf2.0 syntax. Since it doesn’t see it, it falls back to spf1 syntax. It then compares 1.2.3.4 against 1.2.3.0/24, sees that the IP is in the range, and passes the SenderID check.

Success!

And we have an added bonus – the SPF check will also pass. So, whether an email receiver checks SPF or SenderID, this outsourced email will pass either one of them.

It’s a bit more work to set up SenderID, but not too bad. And you’ll have to do something similar anyway if you want to be DMARC compliant. But more on that in a future post.

 


Quick Navigation

Leave a Comment
  • Please add 6 and 8 and type the answer here:
  • Post
  • Hey Terry, I always liked your posts and insights to email communications. I just wanted to clarify on the SenderID records if "v=spf2.0" in indeed a valid record for SenderID. I was always under the impression that "spf2.0" was the only correct method "version."

  • v=spf2.0 is only used for SenderID; SPF does not support it. If v=spf2.0 does not exist, SenderID will fall back to the SPF syntax.

Page 1 of 1 (2 items)