DMARC: moving from Monitor to Reject mode

Editor's note: This blog has been updated since publishing.

In a previous post, I introduced DMARC, a new tool to detect genuine emails. By publishing a DMARC record, you can start receiving aggregate reports from email receivers, and analyze them to identify genuine email streams and the emails streams that impersonate your domain.

Now, it's time for the next step: move to reject mode, so that email receivers can safely reject emails not originating from your infrastructure.

Finding the tree in the forest

Before moving from monitor mode to reject mode, it's a good idea to closely study the aggregate reports. They will help you estimate how many emails you may lose by enforcing the DMARC reject policy: a loss rate of less than ~1% of genuine emails should be achievable.

There are a few particularly common cases for losing genuine emails:

• Email forwarding: users of educational or webmail email providers often forward all of their emails to one mailbox at a preferred provider. Forwarding will break the SPF alignment and some mail server configurations will also break the DKIM signature. A workaround is for receivers to passlist these servers as “known forwarders”.
• Mailing lists: mailing lists will often break the alignment by specifying their own domain in the envelope From field. The DKIM signature will often also break because a lot of mailing lists will modify the Subject of the email (e.g. add the list topic). A workaround is to passlist mail servers operating known mailing lists.

Once you get the rate of loss for genuine emails low and the rate of detecting phishing high, DMARC becomes a very valuable tool.

DMARC reject mode is not for all.

Losing a very small percentage of genuine emails is great, but what if those are the emails that happen to be extremely important? If you're going to move to DMARC, you need to carefully go through all of your third party providers and make sure to get them all on board.

For example, cloud service providers, ubiquitous in modern businesses, will need to conform to DMARC. Some of them employ deliverability gurus, but many do not, and you'll need to spend time explaining what you are trying to achieve. Some applications send emails regularly (email marketing, CMS) while others are much more infrequent (payslip, human resources notices, project management). The latter ones are particularly tricky as they may be hard to find in statistical reports.

From the DMARC FAQ:

There are several options to set up third party senders so the emails they send are not rejected by your DMARC policy. Which option you choose will depend on the capabilities of the third party sender and how much you want their emails to be part of your reputation.

1. Integrate externally: The third party sender uses its own mail servers to send your emails
   1. Delegate a sub domain so they can put their own DKIM record and SPF record in the DNS. The third party sender does not need to publish a DMARC record as your record under the organization name will cover it. Note: you need to make sure they do not add a DMARC record that goes against the policy of your organization domain.
   2. Give the third party a DKIM private key to sign the emails and publish the public key in your DNS and/or add their sending IP, maybe via a SPF include, to your SPF record. Note: ensure the DKIM key pair is specific to the third party so it can be revoked easily. Ensure that when you include their SPF in your SPF, you are not adding a large block of sending IPs, or other third party infrastructure.
2. Integrate internally: Get the third party sender to relay all your emails via your mail server. Note: Ensure the envelope from is correct, and ensure you are not creating an open relay on your side.
3. Do not integrate and tell them not to spoof: Ask the third party sender to use their own domain in the From: header and if replies are required, either have them to alias this email back to you, or have them set the reply-to: header to one of your email address. NOTE: In this case, the forwarding must not break DKIM or you risk rejecting the replies based on the replier's DMARC settings.

A quick fix is to add the SPF record of the third party to your own SPF. You are still missing DKIM, but this may save the day. However, you need to analyze what you are adding. It is not uncommon for a third party to have added some other third parties in their SPF. If you're not careful, you could end up listing half the Internet like this, opening up an attack vector for phishing and completely nullifying the protection offered by DMARC.

Don't forget about bounces!

When deploying DMARC, remember to focus not only on the emails you actively send, but also about the emails you reject. The best solution is to reject emails during the SMTP transaction. If you can’t do that, but you do need to generate a Non-Delivery-Report (NDR) or a Message Disposition Notification (MDN), ensure that these messages do not try to spoof the original sender, and that they are DKIM signed. SPF alignment will break, as there is no Mail From: envelope to go with, so only DKIM can pass the DMARC test.

As a side note, ensure you have a SPF record for the string you present in the HELO/EHLO. This is something everyone forgets to do when deploying SPF.

Enable DMARC as a receiver

I strongly recommend implementing DMARC as a receiver for incoming emails as soon as possible. Do it before moving away from monitoring mode (p=none) for your own domains and make sure that you send forensic reports back to yourself.

Finding what your users are doing in your own domains is easy: you have a complete email to look at instead of aggregate reports, so you know the nature and importance of the email. Moreover, your own users are likely to email each other first when testing new email streams and new email providers. This lets you quickly get your email infrastructure compliant with DMARC and, at the same time, identify and alert key people of the upcoming email policy.

After this phase, it is generally safe to publish a reject policy (p=reject). If your organization is evaluating a new third party provider, having an implementation of DMARC as a receiver makes the detection of rejected emails nearly immediate. Your implementation will immediately reject the emails your users send back to themselves while testing the new provider, instead of waiting a long time to notice that the email receivers that have implemented DMARC are in fact rejecting the emails.

Forensic reports

To request forensic reports from others, update your DMARC DNS record:

_dmarc.example.com IN TXT “v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com”

Use a different mailbox for aggregate(rua) and forensic(ruf) reports. Forensic reports can come in huge numbers: a botnet can send several million emails a day. If the receiver supports it, you'll get one forensic report for every rejected email and every email that did not pass one of the alignments.

You can get a good estimate of the volume of forensic emails from your aggregate reports. Build your infrastructure to receive that volume and way more. If you separate the mailboxes, you will always have room for aggregate reports; in an emergency, redirect all emails for the forensic mailbox to the bit bucket.

Note that not every DMARC enabled receiver will send you forensic reports. Also, some may not send one until you move the policy away from the monitoring mode (p=none).

There is a mode before monitor and reject which is called quarantine (p=quarantine). This is a nice step to do, as emails will still get delivered to the final recipients, but usually go into the junk folder. However, some people routinely check their junk folder and will still believe fraudulent emails are yours. Therefore, it's best to move away from quarantine to reject quickly.

Aggregate reports usually come within 24hours of setting up your DNS DMARC record. If you still have not received a report after 48 hours, check your logs: more often than not, a filter on your side may have discarded the report (they can be big and are a zip attachment).

DMARC, Phishing, and reputation

DMARC provides a nice tool to fight phishing. It gives a sense of what phishing campaigns are out there and what these campaigns are trying to do. DMARC will not solve everything, but it gives more chances for the receiver to keep only the genuine emails.

Email server administrators do not have to put complicated rules to filter emails based on content. The filtering rules used by your anti-spam solutions can then be based solely on your reputation from the genuine emails received. Administrators can also rely on the policy you project to ensure nothing is broken: if there is an issue, you'll see it in the reports and be able to react quickly.