Let’s say, hypothetically, someone attempts to use your brand to commit fraud. Well, the best way for them to do so would be to send email on your behalf. While we hope this situation doesn’t actually transpire, all it takes is for one hacker to spoof a domain and they are free to abuse your customers, leads, and anyone else that possesses an email address. This may jeopardize your brands’ reputation,  cause your legit emails to be flagged as spam, and may even expose your organization to lawsuits. To ensure that your email recipients can distinguish your email from fraudulent ones, you’ll need to use adequate email authentication methods.

In previous posts, we covered the basics of email authentication methods working as a set of security systems to validate an email’s authenticity. The security systems referred to are the three well known email authentication protocols: DKIM, SPF, and this posts’ main focus: DMARC.

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication standard designed to protect both email senders and recipients from attackers who send spam and phishing email by spoofing a domain. Spoofing means changing the “From” field of an email to appear as though it were sent from an impersonated organization or domain. It works alongside and builds upon the other two email authentication methods: SPF (sender policy framework) and DKIM (domain keys identified mail). DMARC augments the other authentication methods with a protocol that allows senders to publish policies that remove guesswork from the receiving end’s processing of email and also provides the receiver a means to send reports back to the sender regarding messages that pass or fail DMARC evaluation.

How does DMARC work?

As mentioned above, DMARC requires the use of DKIM or SPF (Sender Policy Framework) first and much like them, DMARC also makes use of a DNS record to publish what to undertake in the case of failed authentication of messages and how to report it properly.
DMARC also adds a concept called “domain alignment” to the process. One of SPF’s shortcomings is that it only verifies the envelope-from field and not the From field that is viewed by email recipients. DMARC requires the From field’s domain to align with the envelope-from field. With DKIM, DMARC requires theFrom field’s domain to align with the domain in the DKIM-signature field’s d= and s= tags.
To use DMARC, the domain owner must publish a TXT domain record with the subdomain label _dmarc (e.g. _dmarc.yourdomain.com). The value of this TXT record consists of semicolon delimited name=value tags, similarly to the SPF and DKIM records. For instance:

v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:dmarcreports@yourdomain.com

The v tag stands for version, the p tag stands for policy, the sp tag defines the subdomain policy, pct is the percent of unauthenticated emails to apply the policy to, and rua is the URI to send aggregate DMARC reports to. In this example, emails from the domain yourdomain.com are only monitored for SPF or DKIM failures, and emails from subdomains of yourdomain.com are not expected to be sent. Aggregate reports containing statistical data about received messages are to be sent to dmarcreports@yourdomain.com. You may also add forensic reports or real time reports on emails which failed authentication by adding the ruf tag.

The recommended method of adopting DMARC is to gradually move from a relaxed policy to a strict policy by monitoring the reports and changing the policy over time. The allowed policy values are:

  • none: entry level policy - do nothing if messages fail authentication (but specify that they did in the feedback report).
  • quarantine: quarantine messages that fail authentication. This usually means that the recipient will receive the emails in the spam folder.
  • reject: reject messages that fail authentication and don’t even bother delivering them to the recipient.

In addition, the pct tag specifies the percentage of emails that should be treated by the defined policy. The remaining messages would undergo the less strict policy (none if p=quarantine is specified or quarantine if p=reject is specified).

By starting with the none policy and tracking the DMARC reports, you can gradually fix authentication issues and move to stricter policies over time. Last but not least, you can control whether or not email can be sent from subdomains.

Why is DMARC important?

DMARC adds two seemingly small, yet crucial elements to the email authentication process:

  1. Domain alignment
  2. Clear reporting

Note that even DMARC doesn’t protect recipients from fraudulent email sent from other domains that look like your domain (e.g. d0ma1n.com vs domain.com), but if you add DMARC to your domain, it should at least help your legit emails find their way to your recipients’ inbox.

Does Mailer To Go support DMARC?

Absolutely yes!
DMARC is not set per email service but rather for your entire domain. We recommend starting by adding a _dmarc TXT record to your domain, with a value that tells email servers to only send you aggregated reports so you can learn how well you’ve set the authentication methods for all of your email sending mechanisms. The following value instructs servers to just send a an aggregate report to dmarc@yourdomain.com:
"v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com;"

Follow these links to find more information about email authentication methods:

Post photo by Max Bender on Unsplash