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.

v=spf2.0/pra include:1.2.3.0/24 –all

OR

news.example.com

v=spf2.0/pra include:advertize.com –all

• spf2.0/pra means that this is a SenderID record.
• 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).“

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.example.com. It will not pass example.com, confirmations.example.com, and so forth. The damage is contained (and can be revoked by unpublishing the IPs from the SenderID record).