DMARC Record - Explained

September 11, 2021

SPF, DMARC and, DKIM are the email security protocols used by companies or businesses to prevent various phishing attacks. Phishing and email spam are the biggest opportunities for hackers to enter the network. If a user clicks on a malicious email attachment, it can compromise an entire enterprise with ransomware, crypto-jacking scripts, data leakages, or privilege escalation exploits.

Source - From the Internet

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:

  • Verifies that a sender’s email messages are protected by both SPF and DKIM,
  • Tells the receiving mail server what to do if neither of those authentication methods passes, and
  • Provides a way for the receiving server to report back to the sender about messages that pass and/or fail the DMARC evaluation (it is kinda a big fellow in the ground).

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., me@my-domain.com) that the user actually sees and the "from address" that is 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.”


CHECKING FOR DMARC RECORDS

DMARC Check Tool by MX Toolbox
  • Enter the domain name for which you want to check the DMARC record. For example, GitHub.com
  • If you get the results in the following way congrats you already have your DMARC configured and your webmail is safe from phishing.
DMARC Record Example
If the website does not have the Records, check the below section.

CREATE DMARC RECORDS

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 signing up), Dmarcian, and more. The Dmarc.org 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 percentage 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:address@company.com - 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.
  • 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:fbl@smartertools.com; fo=1


As you can see, we have both required tags: v and p, set, but a few optional tags as well. For the policy tag (p) it is 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 rollout 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 for DMARC implementation.


You might also be interested in,

We hope this helps. If any suggestions or doubts you can add a comment and we will reply as soon as possible.
, ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)