In the previous two blog posts I have discussed SPF and DKIM as a way of validating the authenticity of email messages. SPF is using an SPF record in public DNS where all legitimate outbound SMTP servers for a domain are listed. A receiving SMTP server can check this DNS record to make sure the sending mail server is allowed to send email messages on behalf of the user or his organization.

DKIM is about signing and verifying header information in email messages. A sending mail server can digitally sign messages, using a private key that’s only available to the sending mail server. The receiving mail server checks the public key in DNS to verify the signed information in the email message. Since the private key is only available to the sending organization’s mail servers, the receiving mail server knows that it’s a legitimate mail server, and thus a legitimate email message.

As a reminder, my test environment is configured as follows:

There’s an Exchange 2016 CU2 Mailbox server hosting several Mailboxes, and there’s an Exchange 2016 CU2 Edge Transport server. Using Edge Synchronization all inbound and outbound SMTP traffic is handled by the Edge Transport server.

In the previous two blog posts an SPF record was created and implemented, and DKIM including a DKIM signing module on the Edge Transport server was implemented and functioning correctly.

This last blog in a series of three discusses DMARC, which is built on top of SPF and DKIM.

DMARC or Domain-based Message Authentication, Reporting & Conformance

DMARC which stands for Domain-based Message Authentication, Reporting & Conformance is an email validation mechanism, built on top of SPF and DKIM. DMARC is using a policy which is published in DNS. This policy indicates if the sending mail server is using SPF and/or DKIM, and tells the receiving mail server what to do if SPF and/or DKIM does not pass their respective checks.

One “problem” with SPF and DKIM is that the sending organization never knows how SPF and DKIM are used, and what the impact of the usages is, whether it works or not. Therefore DMARC also contains a reporting mechanism. The receiving organization can report back to the sending organization about failure or passing the DMARC checks.

This is how it works:

1. A user sends a new message to an external recipient, the mail server signs the message and inserts the DKIM header.
2. The mail server sends the message to the recipients mail server.
3. The recipients mail server checks DNS for the SPF record, the DKIM records and the DMARC record containing the DMARC Policy.
4. After checking the SPF and DKIM, the policy is applied which determines what needs to happen.
5. If the DMARC check passes the message is delivered to the recipient’s mailbox
6. If the DMARC check fails (block or quarantine) a report is sent back to the sender’s organization.

So, how does a typical DMARC record look like?

Is should read something like:

v=DMARC1;p=quarantine;sp=quarantine;pct=100;rua=mailto:reports@contoso.com

The following tags can be identified in this DNS record:

• v = version
• p = policy for organizational domain (none, quarantine or reject)
• sp = policy for subdomains of the organizational domain (none, quarantine or reject)
• pct = percentage of messages that are filtered
• rua = reporting URI or address for aggregate reports

The following tags can be used as well:

• ruf = reporting URI or address for forensic reports
• adkim = alignment mode for DKIM (relaxed or strict, “s” or “r” which is default)
• aspf = alignment mode for SPF (relaxed or strict, “s” or “r” which is default)

More information regarding all available tags can be found in the DMARC RFC7489.

How to implement DMARC

As mentioned before DMARC is built on top of SPF and DKIM, so the first step is to implement both in your environment and make absolutely sure both work correctly.

Assuming you already have created a Mailbox for receiving the reports you can create a DMARC record with an organizational domain policy set to “none”. This way DMARC will start to work, but won’t take any action while you can analyze the messages that are received in your reporting Mailbox.

So, for my exchangelabs.nl domain the following DNS TXT record _dmarc.exchangelabs.nl will be created:

v=DMARC1;p=none;sp=none;pct=100;rua=mailto:dmarceports@exchangelabs.nl

When entered you can use the http://mxtoolbox.com/dmarc.aspx site to check the DMARC record:

When I send an email from my exchangelabs.nl testenvironment with SPF, DKIM and DMARC in place to my Office 365 Mailbox I can see the following information in the email header:

Authentication-Results: spf=pass (sender IP is 176.62.196.244)
smtp.mailfrom=Exchangelabs.nl; wesselius.info; dkim=pass (signature was
verified) header.d=Exchangelabs.nl;wesselius.info; dmarc=pass action=none
header.from=Exchangelabs.nl;wesselius.info; dkim=pass (signature was
verified) header.d=Exchangelabs.nl;
Received-SPF: Pass (protection.outlook.com: domain of Exchangelabs.nl
designates 176.62.196.244 as permitted sender)
receiver=protection.outlook.com; client-ip=176.62.196.244;
helo=smtphost.exchangelabs.nl;

When sending an email to my Hotmail account I can see the following header information:

Authentication-Results: hotmail.com; spf=pass (sender IP is 176.62.196.244; identity alignment result is pass and alignment mode is relaxed) smtp.mailfrom=J.Wesselius@Exchangelabs.nl; dkim=pass (identity alignment result is pass and alignment mode is relaxed) header.d=exchangelabs.nl; x-hmca=pass header.id=J.Wesselius@Exchangelabs.nl

Based on the header information we can conclude that all DMARC information is correct, and that receiving server can validate the information when available.

Summary

DMARC is built on top of SPF and DKIM, and to have DMARC function properly you need to configure both SPF and DKIM. DKIM is policy based, and this policy is entered in public DNS, and therefore available to everyone. This policy can be set to “none” where DMARC is checked, but not action is taken, or it can be set to “quarantine” or “reject”. This latter is very strict, and when SPF and DKIM are not correct the incoming email is rejected and thus never delivered.

An interesting feature of DMARC is the reporting functionality, where information regarding DMARC features at the receiving server are reported back to the sending server, making it possible for an (Exchange) administrator to analyze DMARC functionality and behavior.

In the last three blog posts I have discusses SPF, DKIM and DMARC. For outbound messages all three are configurable in DNS and on the Exchange server itself, but inbound is still limited. At this moment (august 2016) I haven’t found a proper (open source) DKIM verifying module, nor have I seen a DMARC validation module for the Exchange server. As soon as I find more information I will update my blogposts.

More Information

• DMARC on Wikipedia – https://en.wikipedia.org/wiki/DMARC
• Enhanced email protection with DKIM and DMARC in Office 365 – https://blogs.office.com/2015/01/20/enhanced-email-protection-dkim-dmarc-office-365/
• Overview and status of DMARC – http://www.dmarc.org
• Why is DMARC important – https://dmarc.org/wiki/FAQ#Why_is_DMARC_important.3F

Special thanks to Ashley Flentge for the corrections 🙂