Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Return to sender: Improving security with DMARC email authentication

Learn how domain-based messaging authentication, reporting and conformance, or DMARC, can enhance your email security.

Many high-stakes modern exploits start out with a simple email. The ability of the sender to impersonate a trusted business partner or colleague is a big step toward making a malicious email plausible. Traditionally, email provides little to authenticate the sender. Headers are easily spoofed, and the recipient, who is the target of the attack, is left defenseless trying to figure out which emails are legitimate and which are not.

DMARC allows the sender domain to specify how to deal with nonconforming email.

Email can be authenticated in one of two ways: either person-to-person or server-to-server. The first option is to add a digital signature: The sender adds these digital signatures, and the recipient has to verify them. But the digitally signed email approach has not been broadly adopted due to the difficulties in rolling out the required certificates securely and efficiently to large user populations. Individuals using multiple devices to read and send email have problems configuring consistent certificates, and Web mail systems are often not supported.

As a result, email authentication methods that can be enforced on mail servers are easier to implement across an organization. Two mechanisms have traditionally been used to accomplish this -- DomainKeys identified mail (DKIM) and sender policy framework (SPF). Recently, these standards have been integrated into DMARC (domain-based messaging authentication, reporting and conformance), an emerging specification that Google, Yahoo, Microsoft and many others use that helps to enforce email security by aligning sender and recipient information.

In order to take advantage of DMARC, an organization first publishes DKIM and SPF information via special DNS records. DKIM uses public-private key cryptography to sign email headers on the server. An organization publishes the public key via DNS and deploys the private key on its mail servers to sign headers of email sent by the mail server. This authenticates that a server is authorized to send mail on behalf of the domain that sent the message. DKIM can be difficult to deploy if third-party email services are used. But some email providers, such as Google Gmail, now allow commercial users to add respective keys.

SPF does not rely on cryptography and is easier to configure. The SPF DNS record lists all mail servers permitted to send email on behalf of the domain. It works well if a limited set of mail servers is used, but third-party mail servers can easily be added, and SPF records the third party publishes can be referenced easily.

DMARC not only uses DKIM and SPF to authenticate whether the email was received from a server authorized to send email on behalf of the domain, it also provides feedback to the sender if delivery fails and allows the sender domain to specify how to deal with nonconforming email.

Just like DKIM and SPF policies, the information used to make these decisions is published via DNS records. DNS is a very scalable low-latency method to publish information; an added benefit is that the recipient can cache it, which limits repeat lookups.

With DMARC, an organization publishes a list in the form of an SPF record of mail servers authorized to send email on its behalf. In addition, it publishes a DMARC record identifying what to do if email doesn't comply with this requirement. Usually, the email is either quarantined or discarded.

In the following example, the SPF record identifies two networks from which email may be sent for this domain. It also specifies that Google may send email for this domain because some users may use Gmail accounts to send email.

v=spf1 mx ip4: ip6:2001:db8::/48 include:_spf.google.com

As the DMARC text-resource record below shows, recipients are instructed to reject email unless DKIM and SPF are validated. If a recipient rejects email violating the policy, it sends daily reports about rejected email to dmarc@example.com using the "afrf" format, a simple XML-based report format.

v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=r\; aspf=r; pct=100; rf=afrf; ri=86400;

Many organizations are cautious about implementing SPF or DKIM. A misconfigured SPF or DKIM record may lead to discarded email. By adding a DMARC record, the organization may now also provide an email address that will be used to send reports in case the policy leads to rejected emails. For example, Google supports this feature, and if the search giant rejects email, it will summarize these failures and report them to the published recipient. Unlike normal non-delivery messages, these reports are not sent for each message individually; instead periodic summaries are sent, typically once a day. In addition to identifying configuration issues, these summaries may include information about attempts of criminals to spoof your domain. If a participating organization rejects fraudulent email, it will be included in the summary report. The reports use a standard format to easily generate reports.

About the author:
Johannes B. Ullrich, Ph.D., GIAC, GCIA and GWEB, is the dean of research at the
SANS Technology Institute and head researcher at its Internet Storm Center. Follow him on Twitter @johullrich.

This was last published in February 2014

Dig Deeper on Email and Messaging Threats-Information Security Threats

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

DMARC is quickly becoming must-do to get your email delivered.