Sender ID Framework – SIDF

4.2 Sender ID Framework – SIDF [RFC 4406 (4405, 4407 & 4408)]

SIDF has been very much championed by Microsoft. The standard has been subject to a good deal of controversy and is defined in Experimental RFC 4406 and other RFCs. SIDF is generally considered obsolete with its role now fulfilled by DMARC, described later in section 4.5, although this may not be the case with Microsoft-operated Email services, i.e., &

SIDF is similar to SPF and uses the exact-same mechanism described above for SPF. The key difference is in the specific check performed by the receiving mail server is changed. As described, SPF compares the domain name of ‘The sender’ with a list of valid Email servers for the domain listed in the domain’s SPF record. The question then falls to; so what defines the sender?

SMTP Email contains a number of headers that ‘give indications towards’ the sender’s Email address including the ‘From’ address (RFC5322.From), the ‘Mail From’ address (RFC5321.MailFrom) used during the actual transmissions of the message and the optional ‘Sender’ (RFC2822.Sender) and ‘Reply-To’ (RFC2822.Reply To) addresses.

None of these addresses need match one another and you can sometimes see this in action where some mail clients will show a message as ‘from’ one address, but ‘sent on behalf of’ a different address. This will occur when the ‘From’ and ‘Mail From’ addresses differ, however, this visual presentation of sender information to the user is inconsistent across mail programs. Consequently a message can be sent quoting a sending address that will pass an SPF check, but quote a quite different ‘From’ address that will be shown to the user. This might be used to dupe the user into believing a message has been sent by the ‘From’ address displayed to them while in fact having been sent quoting a quite different address under a different domain name.

Both SIDF and DMARC (described later) attempt to close this possibility, but do so in different ways. DMARC introduces the idea of ‘domain alignment’ between the ‘From’ and ‘Mail From’ addresses while SIDF derives a ‘Purported Responsible Address’ (PRA) based on a set of rules defining how to handle the numerous ‘sender’ headers in a message. A receiving mail server operating SIDF can then complete either an SPF-like sending server validation or a similar check based instead on the domain quoted in the PRA.

SIDF uses a DNS text (TXT) record syntax borrowed straight from SPF, but replaces the SPF “v=spf1” declaration with “spf2.0” followed by whether the receiving Email server should check the PRA, the ‘Mail From’ (mfrom) address (as per an SPF check) or both.

At this point is would be reasonable to conclude that SIDF is the ‘version 2’ SPF given the spf2.0 declaration, however, this isn’t the case, and as mentioned, SIDF is now generally considered obsolete. Do not therefore fall into the trap of considering SIDF as the newer, bigger and better SPF.

SIDF offers DNS record options of:

  1. spf2.0/mfrom – e.g. verify based on the ‘Mail From’ address in an identical manner to an SPF check
  2. spf2.0/mfrom,pra (or spf2.0/pra,mfrom) – e.g. verify based on both the ‘Mail From’ and PRA
  3. spf2.0/pra – e.g. verify based on the PRA alone

We now stray into the areas of controversy; The SIDF specification instructs developers of mail filtering systems to consider a SPF
record as equivalent to spf2.0/mfrom,pra which is a SIDF check incorporating both a SPF-like ‘Mail From’ and PRA check. However, as this is in effect an ‘over-use’ of the SPF mechanism, not all developers have followed this advice and so SIDF implementations vary.

The use of your SPF (v=spf1) record for a PRA check can be significant as this dual check is comparable to the DMARC ‘SPF+’ domain alignment check described in section 4.5 below. The consequence of this is if you send mail, possibly via a third party Email service provider, where the ‘Mail From’ and ‘From’ addresses legitimately differ, then these messages will fail the PRA check because your SPF record was built considering an SPF-based ‘Mail From’ check only.

To overcome this issue you have two options:

  1. You publish an explicit SIDF PRA policy
  2. You publish an empty PRA policy – in effect a special case of option 1

The Sender ID specification forbids implementations to default to the use of a SPF v=spf1 record for PRA checking if a spf2.0/pra record exists, consequently both of these options prevent the ‘misuse’ of your SPF record. If all your Email is sent using identical domain names for both ‘From’ and ‘Mail From’, then SIDF should not cause you an issue.

So how might you sent an empty SIDF record as per option 2? IN TXT "spf2.0/pra"
Figure 7 – Example empty SIDF PRA policy record

If you wish to publish an explicit SIDF policy, then the record syntax follows that of SPF, namely: IN TXT "spf2.0/pra [list of servers] -all"
Figure 8 – Example SIDF PRA policy record

This paper does not attempt to provide the complete detail of SIDF (SPF) record syntax, so if you wish to set an explicit SIDF PRA policy, refer to the SPF record details on the Open SPF website.

Continue reading ‘Domain Key Identified Mail – DKIM’ »


tdraegen's picture

SenderID is obsolete, no new implementations or support will be happening with SenderID. Only Microsoft/ checks it, and their support will eventually end.