In this post, we'll tell you all you need to know about leveraging DMARC to protect your email reputation, and give you pointers on how to set it up for your domains.
Business in a box.
Discover our solutions.
Talk to our sales team
An Effective Tool to Fight Fraudulent Mail
Often mentioned in the same breath as the email authentication protocols SPF and DKIM, DMARC, or Domain-based Message Authentication, Reporting, and Conformance, is not in itself an authentication protocol. Instead, the purpose of DMARC is to allow us, the domain owners, to protect our email reputation by:
Announcing email authentication practices,
Requesting treatment for mail that fails authentication checks, and
Soliciting reports about mail claiming to be from its domain.
DMARC can be an effective tool for us to use in our fight against fraudulent mail that targets our domain name (e.g., phishing and spoofing), and that can promote higher trust among our recipients for our mail. This higher trust should, in turn, lead to higher engagement with our mail, and mail that’s opened and generating clicks drives sales and higher ROI for our email campaigns.
In addition to protecting our domain, we predict that implementing DMARC now will be an excellent way to “future-proof” our domain. Here at Bird, we believe that as the industry moves to IPv6, it is almost certain to move from an IP-based reputation model to a domain-based reputation model. Domain-based reputation will require domain-based authentication, and DMARC, in concert with DKIM and SPF, will help domains establish a domain-based reputation long before one might be absolutely necessary.
In this post, we’ll tell you all you need to know about leveraging DMARC to protect your email reputation and give you pointers on how to set it up for your domains.
Terms to Know
How DMARC Works to Protect Your Email Reputation
When we speak of a mailbox provider or other domain “checking DMARC”, or “validating DMARC”, or “applying DMARC policy”, what we mean is that the domain receiving a message is performing the following steps:
Figure out the message’s RFC5322.From domain
Look up that domain’s DMARC policy in DNS
Perform DKIM Signature validation
Perform SPF Validation
Check domain alignment
Apply DMARC policy
In order for a message to pass DMARC validation, the message must pass only one of the two authentication and alignment checks. So, a message will pass DMARC validation if any of the following are true:
The message passes SPF checks and the RFC5322.From domain and Return-Path domain are in alignment, or
The message passes DKIM validation and the RFC5322.From domain and DKIM d= domain are in alignment, or
Both of the above are true
Making DMARC Work for Your Domain
Now that we’ve explained the mechanics of DMARC, let’s talk about how to make DMARC work for us, which involves the following three steps:
Making preparations to receive DMARC reports
Deciding on what DMARC policy to use for your domain
Publishing your DMARC record
We’ll cover each of these in detail below, but we’ll tell you straight out that step 1 above will consume about 95% of your preparation time.
Preparing to Receive DMARC Reports
Any domain that publishes a DMARC policy should first prepare to receive reports regarding its domain. These reports will be generated by any domain that does DMARC validation and sees mail claiming to be from our domain, and will be sent to us on at least a daily basis. The reports will come in two formats:
Aggregate reports, which are XML documents showing statistical data of how much mail was seen by the reporter from each source, what the authentication results were, and how the messages were treated by the reporter. Aggregate reports are designed to be machine-parsed, with their data stored somewhere to allow for overall traffic analysis, auditing of our domain’s message streams, and perhaps identification of trends in sources of unauthenticated, potentially fraudulent, email.
Forensic reports, which are individual copies of messages that failed authentication, each enclosed in a full email message using a format called AFRF. The forensic reports are supposed to contain full headers and message bodies, but many reporters strip or redact some information due to privacy concerns. Nonetheless, the forensic report can still be useful both for troubleshooting our domain’s own authentication issues and for identifying, from URIs in the message bodies, malicious domains and websites used to defraud our domain owner’s customers.
The preparation to receive these reports involves first creating two mailboxes in our domain to handle these reports, such as agg_reports@ourdomain.com and afrf_reports@ourdomain.com. Note that those mailbox names are completely arbitrary, and there are no requirements for the naming of the local part of the mailbox; we are free to choose any names we wish, but keep the two separate for easier processing.
Once the mailbox names are selected and created in our domain, the next thing to do here is to put tools in place to read these mailboxes and make use of the data, especially the aggregate data reports, which again are designed to be machine-parsed, rather than read by a human. The forensic reports, on the other hand, might be manageable simply by reading them ourselves, but our ability to do so will depend both on our mail client’s understanding of how to display messages in the AFRF format and on the volume of reports we receive.
While it’s possible for us to write our own tools to process DMARC reports, until such time as Bird provides such services for bird.com customers (something we’re considering, but not promising yet), we recommend that we make use of tools that are already available for the task.
Which DMARC Policy to Use
The DMARC specification provides three choices for domain owners to use to specify their preferred treatment of mail that fails DMARC validation checks. They are:
none, meaning treat the mail the same as it would be treated independent of DMARC validation checks
quarantine, meaning accept the mail but place it somewhere other than the recipient’s Inbox (typically the spam folder)
reject, meaning reject the message outright
It is important to keep in mind that the domain owner can only request such treatment in its DMARC record; it’s up to the recipient of the message to decide whether or not to honor the requested policy. Some will do so, while others may be a bit more lenient in applying policy, such as only spam-foldering mail when the domain’s policy is reject.
We recommend to all of our customers that they launch with a policy of none, simply to be safe. While we are confident in our ability to properly authenticate your mail through DKIM signing, it’s still best to take some time to examine reports about your domain before getting more aggressive with your DMARC policy.
Publishing Your DMARC Policy
A domain’s DMARC policy is announced by publishing a DNS TXT record at a specific place in the DNS namespace, namely “_dmarc.domainname.tld” (note the leading underscore). A basic DMARC policy record for our example domain from earlier, joesbaitshop.com, might look something like this:
_dmarc.joesbaitship.com. IN TXT "v=DMARC1\; p=none\; rua=mailto:agg_reports@joesbait.com\; ruf=mailto:afrf_reports@joesbait.com\; pct=100"
Breaking down this record, we have:
v=DMARC1 specifies the DMARC version (1 is the only choice right now)
p=none specifies the preferred treatment, or DMARC policy
rua=mailto:agg_reports@joesbait.com is the mailbox to which aggregate reports should be sent
ruf=mailto:afrf_reports@joesbait.com is the mailbox to which forensic reports should be sent
pct=100 is the percentage of mail to which the domain owner would like to have its policy applied. Domains just getting started with DMARC, especially those likely to generate a high volume of reports, may want to start with a much lower number here to see how their report-handling processes stand up to the load.
There are other configuration options available for a domain owner to use in its DMARC policy record as well, but the tips we’ve provided should be a good start.
Summary
There’s a lot to unpack in the information above! We hope you find the how-to for creating a DMARC policy record helpful. We also hope that our explanation of why DMARC matters helps make clear why you should start using this important tool for protecting your email reputation.
Of course, this isn’t a complete or authoritative document on the subject. If you want to dig in deeper or want more help, a great place to start is the official DMARC FAQ. And, it goes without saying that the Bird support team is ready to help you configure your Bird account for DMARC as well.
Thanks for reading—and start protecting your domains with DMARC today!
