SIDF (Sender ID Framework)
Learn what SIDF (Sender ID Framework) is, how it built on SPF to verify sender identity, and how DMARCeye detects legacy SIDF records still present in DNS.
What is SIDF (Sender ID Framework)?
SIDF (Sender ID Framework) is an email authentication protocol developed by Microsoft to help prevent spoofing and phishing. It was designed as an extension of SPF (Sender Policy Framework) and uses DNS records to verify whether an email message comes from an authorized mail server for a given domain. While SIDF is largely obsolete today, it played an important role in the early evolution of domain-based authentication standards.
Like SPF, SIDF aimed to reduce forged sender addresses by validating the IP address of the sending mail server. However, it expanded SPF’s functionality by analyzing both the envelope sender (the address used during SMTP transmission) and the visible From header (the address shown to the user). This was an attempt to verify not only who technically sent the message, but also who appeared to send it.
How SIDF Works
SIDF checks the sender’s identity by querying DNS for a TXT record similar to SPF. These records usually begin with v=spf1 or spf2.0. The receiving mail server compares the IP address of the sender against the authorized list defined in the DNS record.
Example of a Sender ID record:
example.com. IN TXT "spf2.0/pra ip4:192.0.2.0/24 -all"In this record:
spf2.0/praspecifies the protocol version and scope (PRA stands for Purported Responsible Address, the header address being verified).ip4:192.0.2.0/24lists authorized senders.-allinstructs receivers to reject mail from any other sources.
If the IP address of the sending mail server matches an authorized sender in the domain’s record, SIDF validation passes. If not, the message is marked as failing and may be filtered or rejected depending on the receiver’s policy.
Limitations and Legacy of SIDF
Despite its goal of improving SPF, SIDF faced several challenges. The most significant issue was incompatibility with the existing SPF standard. Many organizations had to choose between maintaining separate SPF and SIDF records or risk validation conflicts. Additionally, SIDF’s approach to checking the Purported Responsible Address (PRA) often led to inconsistent results when messages passed through forwarding systems or mailing lists.
By the late 2010s, most mailbox providers and email security systems deprecated SIDF in favor of SPF, DKIM, and DMARC. These newer protocols offered better alignment between sender identity and message authentication, eliminating the need for separate Sender ID validation.
While SIDF is no longer actively supported, understanding it provides historical context for how email authentication evolved. It was one of the first attempts to link visible sender information with technical authentication data, paving the way for modern standards like DMARC.
SIDF and DMARCeye
DMARCeye focuses on current authentication protocols such as SPF, DKIM, and DMARC, but its analytics engine can still detect legacy records like SIDF that remain in DNS. These outdated configurations can cause confusion or minor compatibility issues if left in place.
DMARCeye flags old or unused SPF2.0 entries and helps administrators update their DNS to conform to modern standards. By ensuring that authentication relies on SPF, DKIM, and DMARC only, organizations can streamline mail validation and improve deliverability without legacy protocol conflicts.
Sign up for a free trial of DMARCeye today and secure your email domain.
To learn more about DMARC and DMARC-related terms, explore the DMARCeye Glossary.