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
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:192.0.2.0/24 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 email@example.com using the "afrf" format, a simple XML-based report format.
v=DMARC1; p=reject; rua=mailto:firstname.lastname@example.org; 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 first published in February 2014