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

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 was sending on behalf of Oceanic Airlines (sample email here). Below was the email transaction:

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

To pass an SPF check, the connecting IP address is checked against the domain in the RFC5321.MailFrom address, in this case Suppose that the connecting IP is and the SPF record for is the following:
”v=spf1 ip4: –all”

Because is in, 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

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 does not publish SenderID records. But it does publish SPF records, per the following:
v=spf1 –all

Because the connecting IP of is not in the range, 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 For mail that comes from a third party, delegate a subdomain like 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, or 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:
      ”v=spf2.0/pra include: –all”

”v=spf2.0/pra –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 It will not pass,, 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:

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

For a machine that is checking SenderID, it extracts the domain in the From: field, It then takes the sending IP, and does a SenderID lookup:
”v=spf2.0/pra –all”

The “include” says to do a SenderID lookup for
”v=spf1 ip4: –all”

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


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

Comments (4)

  1. Andrew Wingle says:

    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."

  2. tzink says:

    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.

  3. Daniel says:


    I have been jumping up and down with a team of 5 people here to solve the Mystery of outlook and hotmail not accepting our emails, reading this article saved us at the end.

    Our problem *(just incase if anyone has the same issue):

    Emails from our servers were going to the spam or sometimes not even delivered to outlook at all!

    We had all these setting right:

    spf: pass

    dkim: pass

    also dns and rdns and ptr records were setup correctly.


    we were missing the senderid record in our dns zone:

    ”v=spf2.0/pra –all”

    and bang! it is now working.

    Thanks alot for writing this article!


  4. Terry,

    Thank you for such a nice article.