How to deploy DMARC for inbound processing
As DMARC adoption increases, more people are looking at using DMARC to filter their own email. We’ve put together this article to outline how to do “DMARC inbound.”
Email is vast and DMARC is still being adopted. When you start filtering inbound email using DMARC, you’ll discover two important insights:
- Email comes in from all sorts of different places.
- Legitimate email using your domain can come from the outside world.
Applying DMARC policies (including your own domain’s policy!) to your inbound email without considering the above insights will lead to the blocking of legitimate email. This is guaranteed to make real people unhappy.
Email from Different Places
When email flows from “A” to “B,” filtering is easy and everything just sort of works.
When email flows from “A” to “F” on its way to “B,” this is when inbound processing gets tricky.
When processing inbound email, you’ll get email purporting to be from “A”, and “A” will have a DMARC reject policy in place. Unfortunately, this email will arrive from “F” before finding its way to you (“B”). The rub is, “F” might break your ability to use DMARC to determine the legitimacy of the email.
SPF will not work
When email flows through an intermediate step, the list of authorized servers that SPF checks will not include the intermediate step. Dang.
DKIM will break
If “F” ends up modifying the content of the email, DKIM will break. This happens when mailing lists add footers, or when a machine adds something like “Scanned by Blahsoft for Viruses!” Dang x2.
“F” happens on the Internet. Forwarding, email lists (aka listservs), group-email aliases, scanning services… these things are likely to be happening today to the email flowing into your infrastructure.
To deal with “F”
- Identify which “F”s are affecting your ability to check DMARC.
- Create exceptions to your processing so that DMARC will not be applied to legitimate email streams that are otherwise being mangled by an “F.”
- If you can, let “F” know that there’s a better way to forward email.
Legitimate Outside Email on your Domain
When you have the ability to create exceptions, dealing with the second insight is similar to the first. Identify legitimate but non-compliant sources of email that are using your domain and create exceptions for these sources of email.
If the source of email is is using your domain and communicating to just your own users, you can whitelist them within your own inbound processing and be done. If the source is sending to other organizations, you’ll need to get this source into compliance with DMARC. Even if you add this to your own whitelist, relying on other people to identify this source as an exception within their own inbound processing is not wise.
Inbound Implementation Plan
With the above said, here is an inbound implementation plan.
First, configure inbound processing to check DMARC results. Do not do anything with these results, simply enable checking so that you’ll have useful data to get started with.
Next, configure inbound processing to generate both XML-based aggregate reports and individual failure/forensic reports. However, do not send these out to domain owners. At this point, you’re still collecting your own data.
Analyze the reports you’ve generated. Reports will cover all domains found in the inbound email you’ve processed, including your own domains. For your domains, identify services and partners that are using your domain to send email to your own users. For other domains, identify legitimate sources of email that are breaking DKIM signing.
Based on the above analysis, create exceptions when necessary, and bring your own sources of email into compliance with DMARC. If at all possible, include in XML-based aggregate reports if exceptions are applied. This helps other domain owners understand how you’re treating their email, including email that is going through an “F”.
When confident that all necessary exceptions are in place and that all of your domain’s sources of email are sending DMARC-compliant email:
- Configure inbound processing to act on DMARC results, and
- configure inbound processing to send XML-based aggregate reports to domain owners. Whether or not individual failure/forensic reports are sent to domain owners is a policy decision to be made by your own organization.
Support for features that allow one to follow the above implementation plan varies widely among email vendors.
The above information and article was inspired by Franck Martin and his work at LinkedIn to get inbound DMARC processing into place. Thanks Franck!
