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

Before we get into setting up DMARC for your domain, we want to make sure we’re speaking the same language. Let’s start by defining some terms we’ll use throughout the rest of this document.

RFC5322.From Domain

The RFC5322.FromDomain is the domain part of the email address that’s usually seen by a recipient of our email when it’s being read. In the following example, the RFC5322.From domain is “joesbaitshop.com”

From: Joe’s Bait and Tackle <sales@joesbaitshop.com>

DKIM d= Domain

DKIM is an authentication protocol that allows a domain to take responsibility for a message in a way that can be validated by the receiver of the message; this is done through the use of cryptographic signatures inserted into the message’s headers as it’s leaving its origination point. These signatures are effectively snapshots of what the message looked like at that point in time, and the receiver can use these snapshots to see if the message has arrived unchanged at its destination. The process of producing and inserting these snapshots is called DKIM signing, and the domain that takes responsibility for the message by signing it inserts its name into the header in a key-value tag as “d=signingDomain”, and so it’s referred to as the DKIM d= domain.

Return-Path Domain

The Return-Path domain, sometimes called the RFC5321. From Domain or the Mail From domain, is the domain to which bounces are routed; it is also the domain on which SPF checks are done during the email transaction. This domain is usually not seen by the recipient unless the recipient is savvy enough to look at all the headers in a given message.

By default, all mail sent through bird.com will have birdmail.com as its Return-Path domain, as in the following example:

Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>

However, in order to make DMARC work for your domain, you’ll want to take advantage of a custom bounce domain, one that will end in the same domain as your sending domain, e.g., bounces.yourdomain.com when using yourdomain.com as your sending domain.

Organizational Domain

The term “Organizational Domain” refers to the domain that was submitted to a registrar to create the domain’s presence on the internet. For Bird, our organizational domains are bird.com and birdmail.com.

Domain Alignment

The last term to understand regarding DMARC is “Domain Alignment,” and it comes in two variants: “relaxed” and “strict.”

Relaxed Domain Alignment

Any two domains are said to have relaxed domain alignment when their Organizational Domains are the same. For example, a.mail.bird.com and b.foo.bird.com have relaxed domain alignment because of their common Organizational Domain, bird.com.

Strict Domain Alignment

Two domains are said to be in strict domain alignment if and only if they are identical. So, foo.bird.com and foo.bird.com are in strict alignment, as the two domains are identical. On the other hand, foo.bird.com and bar.foo.bird.com are only in relaxed alignment.

DMARC Domain Alignment Requirements

In order for DMARC validation checks to pass, DMARC requires that there be domain alignment as follows:

• For SPF, the RFC5322.From domain and the Return-Path domain must be in alignment

• For DKIM, the RFC5322.From domain and the DKIM d= domain must be in alignment

The alignment can be relaxed or strict, based on the published policy of the sending domain.

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:

1. Figure out the message’s RFC5322.From domain

2. Look up that domain’s DMARC policy in DNS

3. Perform DKIM Signature validation

4. Perform SPF Validation

5. Check domain alignment

6. 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:

1. Making preparations to receive DMARC reports

2. Deciding on what DMARC policy to use for your domain

3. 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!