DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a steadily emerging, mature technology that allows domain owners to assert their preferences for mail disposition based on authentication results (SPF and/or DKIM). Through the publication of a record in DNS, a domain can request that any unauthenticated mail be rejected, treated as suspicious (a.k.a., quarantined), or have no specific action taken by the receiving domain. DMARC is a powerful tool that can help a domain owner protect its customers and its brand from the effects of fraudulent activity, but there are barriers to adoption, namely:
In this post, I’ll talk about how using DMARC itself might be the fastest and most efficient way to overcome the first two hurdles, and I’ll talk about some options available to you right now for the last of them
When a domain publishes a DMARC policy that requests either rejection or quarantine of unauthenticated mail, that domain is implicitly stating that all mail that it sends is properly authenticated. Before publishing such a policy, a domain must first have a clear understanding of its outbound mail flow and confirm that all mail is being properly authenticated. Any domain that requests that unauthenticated mail be rejected or quarantined without first confirming its authentication practices runs a very real risk of wanted mail not reaching its intended recipients.
It may seem like putting the cart before the horse, but DMARC itself can be used to help you get the clear understanding you’ll need to effectively deploy DMARC. In organizations where many groups may be responsible for different outbound mail streams, doing an inventory of all mail flows can be a chore. The mere idea of having to contact all groups in a company to determine who’s sending mail for them and from where is enough to make the task seem not worth the effort, and even if you do it, there’s no guarantee that you’ll hear about every “server under someone’s desk” that’s sending critical mail, so the inventory may never be complete. Beyond that, even if you do know every server that’s sending mail, you still may not have visibility into all authentication practices, and so you may never be sure that you can really protect your brand. There is a way, however, to publish a DMARC policy that will allow you to be confident that you fully understand all of your mailing practices.
In addition to its facility for publishing a mail disposition preference, DMARC also provides for the reporting of authentication results to the domain owner, and it’s through a combination of the two that you can use DMARC to figure out where all your outbound mail is coming from and whether it’s authenticated. Additionally, these reports will give you some idea of just how vulnerable you currently are to having your brand spoofed.
A domain announces its DMARC policy by publishing a DNS TXT record at a specific point in its name hierarchy; for any domain, this record is always published at the name
Within the DMARC record are many key-value pairs, but there are only three that are necessary to get started:
v=, to specify the DMARC version
p=, to specify the policy (possible values are none, quarantine, or reject)
rua=, to specify an email address to receive authentication result reports from domains doing DMARC checking
The bare-bones DMARC record that you would have to publish in order to start auditing your outbound mail flows would be:
_dmarc.domain.tld. IN TXT “v=DMARC1; p=none; rua=mailto:[email protected]”
This record asserts that you want no special disposition applied to messages that fail authentication (p=none) and that you want reports sent to the address [email protected]
Publishing a DMARC record like the one above is enough for you to have access to the information you’ll need to get a handle on your mail flows and current authentication policies; any domain honoring DMARC records will send you valuable data based on the record you’ve published. You must understand, however, that there’s other work you’ll have to do before publishing the record to take advantage of that data once it starts rolling in. Return Path can help you in this regard.
The reports you’ll receive as the result of publishing this record are known as aggregate reports, and they will come to you in a specific format, basically an email message that includes an XML file, one that could be quite large depending on the volume of mail seen by the reporter. This XML file is intended to be easily parsed, preferably by automated means, with the information in it collected somewhere in a manner that supports easy retrieval and analysis. Return Path has a full suite of tools that can help you interpret this valuable data, or you can put together your own to handle the task. Your choice will depend on the resources at your disposal. Some may see the work required to parse DMARC reports as its own barrier to adopting DMARC, but if you care enough about your brand to protect it from fraud, then it’s work that’s well worth doing.
At Return Path, we understand that brand and domain owners need help in protecting both their reputations and their customers from the effects of fraud, and we’re engaged in that effort every day. We see the benefits of DMARC, we know it is an effective tool to use in this struggle, and we’re here to help you if you need it. We believe that any brand worth having is a brand worth protecting, so whether you call on us or not, we encourage you to use the ideas put forth in this post to get you closer to deploying a DMARC policy for your mail that will ensure trust for your brand.