WHY SHOULD EMAIL AUTHENTICATION CONCERN YOU?
Authentication is one way of making email more reliable and secure. Authentication improves the likelihood that legitimate
email will get through to the intended recipient. Although authentication is currently a recommended practice, it won’t be
long before it is a required practice in order to have email delivered into the inbox. It could also potentially affect the
recipient experience through image rendering and security icons. Additionally, authentication may help to reduce spoofing
and phishing attacks against your domain, helping to protect your brand.
Good practice is to implement at least one of these standards. Best practice would be to implement all, if that is practical
for your business. If you are a member of the Direct Marketing Association (DMA) you are now required to implement at
least one method. The DMA, in partnership with Return Path, has created a Reputation Registry for its members to check
whether they are authenticated. It's a great resource and can really help you rally internal support for authentication.
WHAT IS EMAIL AUTHENTICATION?
Email authentication verifies the domain name, or identity, of the sender to protect the sender’s brand name and online
reputation, and helps ISPs remove spoofing and phishing messages. Spoofing refers to imitating a legitimate company or
source in an email or on the Web. Phishing wrongly “phishes” for a user’s private information by using deceptive
schemes,
In the future, ISPs may require email authentication to help other ISPs and reputation assessors evaluate the quality of
the sender’s reputation. Since spammers are also able to validate email, reputation assessors may be leery of senders
who do not certify email.
Email authentication is analogous to a driver’s license. Email authentication, just like a driver’s license, accurately
confirms your identity. But neither a driver’s license no an email authentication can confirm the quality for your driving
ability email reputation.
To facilitate email authentication, each technology publishes records using the Domain Name System (DNS), which
translates a hostname into an IP address such as www.example.com to 208.77.188.166. Sender Policy and Sender ID
designate the hosts authorized to send email for a specific domain. Before delivering a message to an inbox, ISPs try to
verify that the email is coming from an authorized source by checking email authentication records. With Domain Keys
Identification Mail (DKIM), the record carries a public encryption key, which receivers can retrieve via DNS and use to
decode the DKIM signature in a message and verify the message authenticity.
LEADING EMAIL SENDER AUTHENTICATION TECHNOLOGIES
Sender Policy Framework (SPF) grants the administrator the right to determine which hosts can send email for the
domain, filtering legitimate mail from illegitimate sources for their domain. SPF prevents the transmission of forged email.
Since not all spam is forged, it cannot stop spam, or junk email. The receiving mail server checks the sending domain's
record in the DNS zone file against the sender’s IP address. The Domain Name System (DNS) serves as the "phone
book" for the Internet by translating human-friendly computer hostnames into IP addresses. For example,
www.example.com translates to 208.77.188.166.

SenderID Framework (SIDF) verifies the sender’s IP address against the owner’s sending domain and helps
address the problem of spoofing and phishing.

Domain Keys (DK) are used mostly as an additional anti-spam and anti-phishing method for sending and
receiving email messages.
o Sending email messages

o

The domain owner generates a public / private key pair to use for signing all outgoing
messages. The public key is published in DNS, and the private key is made available to
their DomainKey-enabled outbound email servers.
 When each email is sent by an account within the domain, the DomainKey-enabled email
server automatically uses the stored private key to generate a digital signature of the
message. This signature is embedded as a header in the sent email, and the email is sent
on to the target recipient's mail server.
Receiving emails
 The DomainKeys-enabled receiving email server extracts the signature and claimed
From: domain from the email headers and fetches the public key from DNS for the
claimed From: domain.
 The public key from DNS is then used by the receiving mail server to verify that the
signature was generated by the matching private key. This proves that the email was
indeed sent by, and with the permission of, the claimed sending From: domain and that its
headers and content weren't altered during the transfer.
 The receiving email server applies the local policies based on the results of the signature
test. If the domain is verified and no other anti-spam tests catch it, the email can be
delivered to the user's inbox. If the signature fails to verify, or there isn't one, the email
can be dropped, flagged or quarantined.
Domain Keys Indentified Mail (DKIM) lets an organization handle and/or take responsibility for a message while
it is in transit. The reputation of the domain name is the basis for evaluating whether to trust the message for
delivery. Technically DKIM provides a method for validating a domain name identity that is associated with a
message through cryptographic authentication.
HOW DO YOU AUTHENTICATE?

You can find detailed information about the standards on the following Web sites:
 DKIM: http://www.dkim.org/
 SenderID: http://www.microsoft.com/senderid

SPF: http://www.openspf.org/

Make sure you take inventory of all mail servers that you send email from so that they are all included in your
authentication.

Create your authentication records. There are excellent online tools available for creating valid SPF and
Sender ID records. The following tools can help you:

DKIM: http://testing.dkim.org/

Sender ID: http://www.microsoft.com/senderid

SPF: www.openspf.org/wizard.html

Make sure you publish your authentication records. Work with whoever manages your DNS records to
publish the email authentication records you've collected. For DK and DKIM, your MTA administrator will need to
configure the server as well.

Test your authentication records. SPF, SenderID, and Domain Keys provide options to publish your records in
"test" mode. This provides the opportunity for testing without risking delivery failures for mistakes in your record.
Testing will ensure that the mail servers you've authorized are being verified by receivers and will determine if
you've missed identifying any mail servers in your inventory.

Don’t forget to check your authentication regularly, especially if you make any changes to your sending
infrastructure.