Getting Started With DMARC

DMARC

What is DMARC?

DMARC, which stands for “Domain-based Message Authentication, Reporting & Conformance”, is a way to determine whether an email message is actually from the sender or not. It builds on the widely deployed SPF and DKIM protocols, and adds domain alignment checking and reporting capabilities to designated recipients, to improve and monitor protection of the domain from nefarious spoofing attempts.

Here is an illustration from dmarc.org:

Why is DMARC important?

From dmarc.org:

With the rise of the social internet and the ubiquity of e-commerce, spammers and phishers have a tremendous financial incentive to compromise user accounts, enabling theft of passwords, bank accounts, credit cards, and more. Email is easy to spoof and criminals have found spoofing to be a proven way to exploit user trust of well-known brands. Simply inserting the logo of a well known brand into an email gives it instant legitimacy with many users.

Users can’t tell a real message from a fake one, and large mailbox providers have to make very difficult (and frequently incorrect) choices about which messages to deliver and which ones might harm users. Senders remain largely unaware of problems with their authentication practices because there’s no scalable way for them to indicate they want feedback and where it should be sent. Those attempting new SPF and DKIM deployment proceed very slowly and cautiously because the lack of feedback also means they have no good way to monitor progress and debug problems.

DMARC addresses these issues, helping email senders and receivers work together to better secure emails, protecting users and brands from painfully costly abuse.

What is a DMARC record?

DMARC records are published in the DNS as text (TXT) resource records (RR) and announce what an email receiver should do with non-aligned emails it receives.

Consider an example DMARC record for the domain “sender.exampledomain.com” that reads:

v=DMARC1;p=reject;pct=100;rua=mailto:[email protected]

In this example, the sender requests that the receiver outright reject all non-aligned messages and send a report, in a specified aggregate format, about the rejections to a specified address. If the sender was testing its configuration, it could replace “reject” with “quarantine” which would tell the receiver they shouldn’t necessarily reject the message, but consider quarantining it. DMARC records follow the extensible “tag-value” syntax for DNS-based key records defined in DKIM.

What are DMARC record tags?

A typical DMARC record looks like this:

v=DMARC1; p=none; ri=3600; rua=mailto:[email protected]; ruf=mailto:[email protected]; sp=none; adkim=s; aspf=s; fo=0:1:d:s;

It consists of multiple tags which define how the email service provider (ESP) should behave when it sends the DMARC reports. We will explain each of the tags below.

v is DMARC protocol version. It's DMARC1 by default.

p is the policy. Apply this policy to emails that fail the DMARC check. This policy can be set to 'none', 'quarantine', or 'reject'. 'none' is used to collect the DMARC report and gain insight into the current email flows and their status. 'quarantine' is used to quarantine failed emails in SPAM folder of the mailbox. 'reject' is used to reject the failed emails downright.

ri is the reporting interval in seconds. It defines how often you'd like to receive aggregate XML reports. This is a preference and ISPs could (and most likely will) send the report on different intervals (normally this will be daily).

rua is a list of URIs for ESPs to send aggregate reports to. NOTE: this is not a list of email addresses. DMARC requires a list of URIs of the form 'mailto:[email protected]'.

ruf is a list of URIs for ESPs to send forensic reports to. NOTE: this is not a list of email addresses. DMARC requires a list of URIs of the form 'mailto:[email protected]'.

sp is the subdomain policy. This policy should be applied to emails from a subdomain of this domain that fail the DMARC check. Domain owners can use this tag to publish a 'wildcard' policy for all subdomains.

adkim specifies the 'Alignment Mode' for DKIM signatures, this can be either 'r' (Relaxed) or 's' (Strict). In Relaxed mode, authenticated DKIM signing domains (d=) that share an Organizational Domain with an email's From domain will pass the DMARC check. In Strict mode an exact match is required.

aspf specifies the 'Alignment Mode' for SPF, this can be either 'r' (Relaxed) or 's' (Strict). In Relaxed mode, authenticated SPF domains that share an Organizational Domain with an email's From domain will pass the DMARC check. In Strict mode an exact match is required.

fo is forensic options. Allowed values: '0' to generate reports if both DKIM and SPF fail, '1' to generate reports if either DKIM or SPF fails to produce a DMARC pass result, 'd' to generate reports if DKIM has failed or 's' if SPF failed.

rf specifies the reporting format for forensic reports.

pct is the percentage tag which instructs ISPs to only apply the DMARC policy to a percentage of failing emails. 'pct = 50' will tell receivers to only apply the policy 50% of the time against emails that fail the DMARC check. NOTE: this will not work for the 'none' policy, but only for 'quarantine' or 'reject' policies.

What is a DMARC policy?

A DMARC policy is the p tag inside a DMARC record. It tells email service providers (ESP) like Gmail what to do if an email fails the DMARC check.

A DMARC policy can take one of three values: none (monitor), quarantine and reject.

– none: DMARC won't do anything with the unaligned emails. This is also called the monitoring mode. One can analyze the DMARC reports and understand who is sending emails on your behalf. Once you get a good grasp of the status of your email program, you can move on to the quarantine policy.

– quarantine: the ESP will put these unaligned emails in the spam folder for quarantine's sake. Like with the none policy, analyze the data and check who is sending emails from your domain.

– reject: the ESP will reject all emails that fail the DMARC check. None of the email messages will show up in the receiver's mailbox. While this policy blocks all emails sent from domain spoofers, it can also block completely legitimate emails from sources not yet on your whitelist. For example, if someone inside your organization uses 3rd-party email services to send emails, and these email services are not given permissions to send on your behalf, such email messages will be rejected!

Publishing a DMARC record

Before you can publish a DMARC record, you need to create it first. To create a DMARC record, log in to the DMARCLY dashboard.

Once logged in, click DNS Records/Publish DMARC Record on the sidebar, and the page now looks like:

The generated DMARC record appears in the highlighted area above.

Next, you need to publish it as a TXT record on your domain (e.g. yourdomain.com) in DNS. Follow the steps below:

  • Log in to your DNS management console;

  • Choose the domain you need to publish the DMARC record on;

  • Create a TXT entry with these settings:

    Type: TXT
Host: _dmarc
TXT Value: (DMARC record generated above)
TTL: 1 hour

For example, here is what it looks like in GoDaddy's DNS management console:

If you are using another domain hosting provider, the UI should be similar.

Save the changes. Now you have published a DMARC record on yourdomain.com.

DMARC Wiki

For more information on DMARC, here are a few DMARC Wiki links:

You can also check out the official DMARC RFC7489.

We have prepared the ultimate guide to implementing DMARC, DKIM, and SPF.

Предыдущая запись Следующая запись

 Protect Business Email & Improve Email Deliverability

Get a 14 day trial. No credit card required.

Create Account