How Do I Create a DMARC Record?

DMARC

DMARC is an acronym for “Domain-based Message Authentication, Reporting and Conformance”. It’s an email authentication, policy and reporting protocol that’s actually built around both SPF and DKIM. It has three basic purposes:

It verifies that a sender’s email messages are protected by both SPF and DKIM,
it tells the receiving mail server what to do if neither of those authentication methods passes, and
it provides a way for the receiving server to report back to the sender about messages that pass and/or fail the DMARC evaluation.

Since DMARC uses both SPF and DKIM, you may wonder why it’s even necessary. Well, it’s simple: DMARC basically builds on SPF and DKIM to ensure that, when an email is received, the information contained in both records matches the “friendly from” domain (e.g., [email protected]) that the user actually sees and the from address that’s contained in the message’s header. This is what the folks at Dmarcian, a company founded by one of the primary authors of the DMARC specification, call “Identifier Alignment.”

Once you have both SPF and DKIM in place, then it’s time to create your DMARC record. The easiest way to do this is to use a DMARC wizard. There are many sites that offer such a tool: MXToolbox, DMARC Analyzer (requires sign up), Dmarcian and more. The Dmarc.org the site also provides a list of utilities for generating DMARC records, DMARC lookup and parsing, message validation and more. Most of these sites also have tools to validate your DMARC record once DNS propagation has taken place.

Regardless of the tool you use, a DMARC record utilizes a number of “tags”. There are really only 2 tags that are actually required: “v” and “p”. Other tags are purely optional, and DMARC experts kind of disagree on which optional tags are recommended and which are not. Let’s look at the required tags first:

v -- This is the version tag, just like with SPF. It MUST be “DMARC1” and be the first tag listed in the DMARC record.

p -- This is the policy tag. It tells the receiving server which policy to apply to a message that fails DMARC: “none” or do nothing to a message, “quarantine” a message or “reject” the message.

Optional tags include the following:

pct -- This is the percent of suspicious messages that the DMARC policy applies to. Of course, the default is 100, but it can be set to whatever you want it to be.
rua=mailto:[email protected] -- This tag tells receiving servers where to send aggregate reports. These reports provide visibility into the health of the sending server by helping to identify potential authentication issues or malicious activity. These reports are sent daily, so, ideally, if you want reports sent, they’re sent to a mail address set up specifically FOR these reports and not a domain admin account, a user account or any other account that normally receives an email for any end-user.
fo -- This tag lets receiving servers know that samples of messages that fail either SPF and/or DKIM should be returned to the sender. There are four value options for this tag:

0: Generate a DMARC failure report if both SPF and DKIM fail to produce a “Pass” result. This is the default option.
1: Generate a DMARC failure report if both SPF and DKIM produce something other than a “Pass” result. This is the recommended option.
d: Generate a DKIM failure report if the message had a DKIM signature that failed the evaluation, regardless of why.
s: Generate an SPF failure report if the message failed SPF evaluation, regardless of why.

So what does a DMARC record look like? Let's look at the record for SmarterTools:

v=DMARC1; p=none; rua=mailto:[email protected]; fo=1

As you can see, we have both required tags -- v and p -- set, but a few optional tags as well. For our policy tag (p) we have it set to “none”. So, we’re basically collecting feedback on messages but we’re not necessarily “interrupting the flow of messages”, even if they fail SPF and/or DKIM. From a DMARC roll out perspective, this is a prudent course of action. That’s because while DMARC is a serious way to catch potential phishing emails, it’s not a widely-adopted policy. Therefore, many domains don’t have SPF or DKIM set up, let alone both. So for the time being, simply watching messages and seeing their disposition, without quarantining or outright rejecting them, is the best way to go about our DMARC implementation.

More Information

DMARC: https://dmarc.org/

If you have questions, you can contact us at [email protected]