Many people in the software industry are familiar with the joke that says that the definition of the word “recursion” is “see recursion,” and the title of this article echoes that joke, but its message is serious: DMARC really can be used to assist you in doing a DMARC implementation for your domain.
A successful DMARC implementation requires that a domain or brand authenticate all the mail streams and then publish a DMARC policy of “p=reject,” which we refer to here at Valimail as “being at DMARC enforcement.” When a domain is at enforcement, it has published a DMARC policy that requests that unauthenticated mail be rejected or quarantined by mail receivers that do DMARC validation checks. This ensures that the domain cannot be spoofed or otherwise impersonated by malicious actors using that domain in the “From” field of their messages.
Being at enforcement is a powerful weapon to use in defense of a domain, but it is one that can cause self-inflicted wounds. If a domain moves too quickly to enforcement before making sure it has got all of its mail streams authenticated, it can end up getting its own mail bounced, with all the problems that ensue from a failed send. The fear of such errors prevents many organizations from getting to enforcement, or perhaps even starting their journey to implement DMARC in the first place. We believe that fear is unfounded — if you know how to use DMARC effectively.
Most people understand DMARC’s policy feature, which provides a domain owner the ability to request treatment for mail that fails authentication, but that’s not all that DMARC is. The other key feature for DMARC is what’s called aggregate reporting, where entities that do DMARC validation and policy enforcement on inbound mail (usually large consumer mailbox providers) will also produce statistical reports showing the results of authentication checks. Per the DMARC specification, these reports should be sent to domain owners at least every 24 hours, and they’re sent to an email address that’s advertised in the domain owner’s DMARC DNS record.
The value of these reports for domain owners trying to understand their mail streams is enormous. In order to receive these reports, all one must do is publish a DMARC record with a policy of “p=none” and a rua tag pointing at a mailbox that can receive the reports. (It’s easier than you think: You really only need 3 basic DMARC tags to make a complete, correct DMARC record.)
The reports are XML documents, meant to be machine readable, and will contain counts of authentication result checks, grouped by sending IP address, authentication results, and the disposition of the messages (whether they were delivered, deleted, or sent to a spam folder). You can inspect these reports for IP addresses known to be in use by your organization, and if authentication failures are reported, you can then take steps needed to address those failures.
Regular consumption of these reports over time, along with efforts to fix any authentication problems, can move the organization forward in their journey to enforcement.
In a complex organization, it can be a real challenge to audit all mail streams for authentication, no matter how dedicated the IT staff is to the task. This is especially onerous in the cloud era, when most of the email sent by most organizations does not originate from internal mail servers with known IP addresses, but from a variety of cloud-hosted services that might use any number of IP addresses. Identifying which services are sending mail “from” the domain is a critical step, and that can be especially daunting if all you have are IP addresses.
However, without knowing where all the mail streams are, you can’t put authentication in place. Although it may sound counterintuitive, DMARC is the best tool available to help you implement DMARC and eventually get to enforcement.