AOTA Email & Domain Authentication Survey

In an effort to aid brand owners in protecting their brand and domains from exploits as well as to aid organizations to adopt email authentication, AOTA will be publishing a directly of third party solutions, marketing services providers and ISPs.  To be considered please provide the following to the easurvey at aotalliance.org.  Information will be updated monthly. 

1. Contact name, title & phone]
2. Company name and URL
3. Product / Service name
4. Statement of adoption and available for customer use as of Jan 15, 2008, (please indicate support for outbound, inbound authentication)
   • Sender ID Framework / SPF
   • DomainKeys
   • DomainKeys Identified Mail (DKIM)
   • Transport Layer Security (TLS)

Protocol Overviews

Sender ID (SIDF / SPF) Sender ID Framework (SIDF) is the email authentication protocol which emerged from the MARID IETF working group that joined Sender Policy Framework (SPF) and Caller ID. It was accepted as an Experimental RFC by the Internet Engineering Task Force, as is, on December 8th, 2005.  Sender ID utilizes the SPF record syntax and providing the receiving network the choice of utilizing the MAIL From or Purported Responsible Check (PRA) check mechanism. 

Domain Keys (DK) DomainKeys is an e-mail authentication system designed by Yahoo to verify the DNS domain of an e-mail sender and the message integrity. The DomainKeys specification has adopted aspects of Cisco's Identified Internet Mail to create an enhanced protocol called DomainKeys Identified Mail (DKIM). This merged specification is the basis for an IETF Working Group which guided the specification toward becoming an IETF standard.  The DKIM standard was issued in May 2007. The DomainKeys draft was also issued under "historical" status at the same time. DomainKeys Identified Email (DKIM)

Transport Layer Security (TLS) An IETF-sponsored protocol intended to secure and authenticate communications across a public network through data encryption. It is designed as a successor to SSL.  The protocol consists of two layers - a TLS Handshake Protocol and, below that, a TLS Record Protocol. The handshake protocol creates a "secret" used by the record protocol to encrypt messages. The record protocol also provides mechanisms for preventing a message from being altered.  The overall protocol is designed to be application independent, so that application or higher-level protocol developers can choose the best way for initiating TLS handshaking and interpreting authentication certificates.

 Back To Top

revised 1/2/08