Question: What is
email authentication and how is it currently affecting
my email delivery?
Answer: Many legitimate email marketers
and Internet ecommerce professionals are encouraging
the implementation of email authentication standards
to combat unsolicited bulk email (read: spam and
phishing emails) that impinge on legitimate bulk
email campaigns.
Email authentication verifies the identity of
the source computer sending the email, matching
the sender of the message to the domain that the
email message is purportedly coming from. Currently,
there are two common types of authentication enjoying
widespread use: Sender Policy Framework (SPF)
and DomainKeys.
SPF
Sender Policy Framework or SPF is an extension
of Simple Mail Transfer Protocol (SMTP), the current
standard for sending email. SPF was designed to
address email spoofing (a spammer practice of
forging an email sender's address) by verifying
information from the email message "envelope,"
mainly the return-path email address. Like a postal
mail envelope, the email message envelope describes
who the email message is from, and to whom it
is going.
The authentication of the SPF record on the
Domain Name System (DNS) server responsible for
a particular web domain is what determines the
message status (pass, fail, softfail, etc.) that
is subsequently passed to the recipient mail server.
The SPF record specifies which email servers
are allowed to send email for a particular domain.
The DNS server manages the network of computers
connected to a domain. These include the "A"
record, which indicates the web server for that
domain, a pointer record (PTR) that manages the
reverse DNS lookups, and mail exchange (MX) records,
which are the mail servers responsible for delivering
email for the domain. SPF simply performs a check
on one or more of these computers to verify to
the recipient mail server their status. In other
words, it authenticates them.
SPF by itself does not prevent spam (the recipient
mail server reads the information in the SPF file,
then makes a delivery determination based on the
status); however, there are many larger ISPs using
SPF for authentication, including MSN and Gmail.
The way to tell for sure if SPF is being used
is to look for the SPF status in the email headers.
A typical response from a server with SPF implemented
may have a header that looks like this:
Received-SPF: pass
The SPF record is a text file built of mechanisms
and qualifiers and is located on the DNS server.
Mechanisms:
| all |
Matches always, used for a
default result like -all for all criteria
not matched by prior mechanisms. |
| a |
If the domain name has an A
record corresponding to the sender's address,
it will match. (That is, the mail comes directly
from the domain name.) |
| ip4 |
ip4 If the sender is in a given
IPv4 range, match. |
| ip6 |
ip6 If the sender is in a given
IPv6 range, match. |
| mx |
mx If the domain name has an
MX record resolving to the sender's address,
it will match. (That is, the mail comes from
one of the domain's mail servers.) |
| ptr |
ptr The domain Pointer record
which manages reverse-DNS lookups. |
| exists |
If the given domain resolves,
match (no matter the address it resolves to).
|
| include |
If the included policy passes
the test this mechanism matches. This is typically
used to include policies of more than one
ISP. |
Qualifiers:
Each mechanism can be combined with one of four
qualifiers:
| + |
for a PASS result, this can
be omitted, +mx is the same as mx. |
| ? |
for a NEUTRAL result interpreted
like NONE (no policy). |
| ~ |
for SOFTFAIL, a debugging aid
between NEUTRAL and FAIL. |
| - |
for FAIL, the mail should be
rejected. |
A very basic SPF text file may look like this:
"v=spf1 a mx
ptr ip4:10.0.0.0 include:anotherdomain.com ~all"
The mechanisms go in order, so if the first
mechanism matches, the corresponding qualifier
is assigned, and the rest of the SPF text is ignored.
In this example, the A record, MX record and PTR
record are checked and any computer listed as
such will PASS, as well as the specific IP address
10.0.0.0. All others will SOFTFAIL.
Figure 1. A Sample of an
SPF Check
Sample SPF Check
Here's a typical routing for an SPF check (see
Figure 1). SMTP Server 1 sends mail to some ISP
mail servers. The recipient mail servers make
a check on the DNS server associated with the
SMTP server, reading the SPF record. The IP address
is specifically listed in the SPF record, assigning
a status of PASS. The Recipient mail servers apply
the status to a rule, and send the email.
SMTP Server 2 sends email to some ISP mail servers.
The recipient mail server checks the DNS server
associated with the SMTP server, reading the SPF
record. The IP address is not specifically listed.
The next mechanism, -all, indicates that if none
of the previous checks passed, then a FAIL status
should be sent to the recipient mail server. In
this example, one mail server doesn't care what
the SPF indicates; it sends the email messages
out anyway. The other implements a rule based
on the FAIL status passed to it from the DNS server
and sends a bounce email notification.
DomainKeys
DomainKeys is an authentication system independent
of SMTP protocol and deals with email headers
which are outside the message envelope. DomainKeys
was designed to identify email spoofing and does
not directly prevent abusive behavior, but it
does make such behavior easier to track. Yahoo!
implemented DomainKeys in 2004 for its outbound
email, and since 2005 has tracked incoming keys.
To implement DomainKeys, the SMTP server operator
specifies a public/private key pair. The public
key is located on the DNS server, and the private
key is configured on the SMTP server. When sending
emails, the SMTP checks in with the DNS, and if
verified, adds a DomainKeys signature to the message
headers. The receiving server then reads the signature
and checks the public key on the DNS server to
verify the signature. It then uses that information
to apply a rule or deliver the email to the final
recipient. If there is no match, the message can
be ignored, since it is apparently a spoof.
When Yahoo! receives an email that doesn't have
a key pair specified, it will simply indicate
in the message header a neutral domain key signature.
Yahoo! could eventually reject email messages
that are not digitally signed, but currently it
delivers neutrally sighed messages. To determine
if a server implements DomainKeys, look at the
full headers of the email received. A typical
DomainKeys header looks like this:
Authentication-Results:
mail.someisp.com from=email.somedomain.com;
domainkeys=pass (ok)
And a typical DomainKeys check can be followed
in Figure 2.
While Yahoo! will still receive an email that
doesn't have a key pair specified, in the future
it could reject email messages that are not digitally
signed.
Figure 2. Typical DomainKeys
Signature Check
Summary
Email message senders are responsible for implementing
both SPF and DomainKeys at the SMTP server and
DNS level, although neither authentication format
is mandatory at this time. While these authentication
policies are not required now, as more ISP email
providers utilize these methods to determine legitimate
email messages, the greater impact they will have
on email message delivery.
References
Return
to Articles |
