The DMARC Record Explained

In this post we’ll explore in detail what a DMARC record is, why you should absolutely have one, and how to use it. If you want to understand DMARC, come along!

What Is a DMARC Record

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. Quite a mouthful.

It designates a system allowing domain owners to prevent abusers from using their domain in fraudulent emails, also known as spoofing, a practice often seen in phishing attacks.

Not only that, but DMARC also enables domain owners to closely monitor abuse attempts.

DMARC depends on SPF and DKIM, the two other major domain email spoofing protection mechanisms. In a sense DMARC is an extension of these, as it makes them stricter, and enforces a policy, like quarantine or rejection, whenever an email fails the SPF or DKIM tests.

For this reason, you will better understand DMARC if you are somewhat familiar with SPF and DKIM. No worries, we got you covered with two dedicated posts, The SPF Record Explained and The DKIM Record Explained.

Don’t want to read that? All right, here’s a condensed version:

• SPF defines a list of mail servers allowed to send emails using your domain email addresses.
• DKIM ensures emails sent from your domain email addresses haven’t been tempered with.

Okay, this is all very abstract, let’s be more concrete. The way to implement DMARC is to add a TXT record to your domain DNS. We’ll start there.

_dmarc.myfancydomain.com.	3600	IN	TXT	"v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@myfancydomain.com"

Not familiar with DNS records either? Take a quick detour to DNS Records explained.

The first part of any TXT record is the host, or name. While this is usually just the root domain name (myfancydomain.com here) or a subdomain, in this case we see it prefixed with _dmarc.

Similarly to DKIM records, this is just a way of identifying the TXT record as being a DMARC record.

The number 3600 is the TTL, a property common to all DNS records, while IN TXT is just part of the DNS syntax, indicating this is a TXT record. Skip.

Now the interesting part, in between double quotes. This is where you define how you want DMARC to behave, using tags.

• v is simply the version, always DMARC1 in practice.
• p is the policy to apply to emails failing the SPF or DKIM tests; In this case reject them.
• pct is the percentage of emails failing DMARC to subject to the policy; Here 100%, which is the same as not having the pct tag in the record.
• rua is the URI to send aggregated DMARC reports to; In this case it’s the email address dmarc-reports@myfancydomain.com.

Other DMARC tags

Those are the most commonly used tags, but a few other exist. The full list can be found on the DMARC website, here.

This particular DMARC record specifies that any email failing either the SPF or DKIM test (or both) should be rejected, instead of being delivered to the recipient. But how does that work exactly?

How DMARC Records Work

TL;DR

DMARC instructs mails servers to follow a policy based on the results of the SPF and DKIM tests, prevents spoofing of the From header by comparing its domain against the Return-Path and DKIM-Signature domains, and asks recipient mail servers aggregated reports of sending attempts and their outcome.

When you send an email with your mail app, the app transmits that email to your mail server. That’s the server ran by your mail service, which takes care of handling your domain emails.

Your mail server then sends your email to the recipient mail server (the one pointed to by the MX record of the recipient domain).

The recipient mail server performs SPF and DKIM checks on the email, and treats the email differently depending on whether these tests pass or fail.

The SPF test

The recipient mail server checks that the sending server IP address is listed in the allowed IP addresses given in the SPF record of the sender domain.

The DKIM test

The recipient mail server computes the email digital fingerprint and checks that it matches its original fingerprint (a.k.a DKIM signature) using the key in the DKIM record of the sender domain.

However, you have no say in what the server does with the email. SPF emits a mere recommendation (pass, soft fail, or fail), and DKIM informs whether the email has been altered since it was sent, but none really instructs the mail server what to do with an email failing the tests.

Don’t get me wrong, failed SPF and DKIM tests will have an impact. Usually that’s a bad spam score and therefore a higher probability that the email ends up in the recipient’s junk or spam folder. But it’s the recipient server’s call, based on its anti-spam configuration.

DMARC will instead instruct the recipient mail server what to do. If you have a reject DMARC policy for instance, the recipient server must reject emails failing at SPF or DKIM. With DMARC, you, the domain owner, have a say.

Some servers still don’t support DMARC, and some purposefully choose not to follow it, but the vast majority do abide by its rule.

That’s the first point. DMARC instructs mail servers to follow a policy based on the results of the SPF and DKIM tests.

But that’s not all. If you read our posts about SPF and DKIM, you know that SPF and DKIM are based on the envelope sender address, also called Return-Path address (or “Mail From” address), which can be considered as the “true” sender address (the one the sender is authenticated with to his/her mail server). That address is found in the email headers (what you see at the top of emails when you open their “source”).

You also know that the envelope address is usually not the email address mail apps show as the sender address of an email. That would be the From address, also present in the email headers.

This is a major flaw of SPF and DKIM, as we discussed in their respective posts.

Well, DMARC fixes that flaw! It does so by making sure the domain in the From header matches the one used for SPF (domain of the Return-Path address) and the one used for DKIM (domain in the DKIM-Signature header).

This is called alignment. If SPF or DKIM is not aligned, it’s considered a failure.

That’s the second point. DMARC prevents spoofing of the From header field.

And DMARC is still not done! If you set the rua tag in your DMARC record, recipient mail servers will provide you with daily reports of sending attempts made with your domain email addresses, with the outcome of each attempt.

That’s the third point. DMARC provides to domain owners aggregated reports of sending attempts and their outcome.

In those reports, for each attempt you’ll see informations like how many emails came from which IP, the results of SPF and DKIM tests, and so on. We’ll explore that in details in the DMARC Reports segment below.

DMARC reports are a fantastic tool to better understand how and where your domain addresses are being used, and monitor spoofing attempts.

They also enable you to fix your setup (for instance add a missing server in your SPF record) and tune your DMARC policy over time (make it progressively harsher). More on that in the What DMARC Record You Should Use section.

DMARC Policies

We stated multiple times that DMARC defines a policy. The available policies are: none, quarantine, and reject, accompanied by a few settings.

The “none” Policy

The p=none policy instructs the recipient mail server to continue processing the email as usual.

It does not mean to deliver the email successfully no matter the results of SPF and DKIM checks. It simply means to not apply any DMARC policy. The server will still apply its usual anti-spam mechanisms and will likely classify an email failing SPF/DKIM as junk.

At first glance that policy may seem useless, but it actually serves a very important purpose. It allows domain owners to do monitoring only, via DMARC reports, without risking blocking any email until they get a better picture of their domain email activity.

The none policy is actually what the creators of DMARC recommend at first, as it is the safest one for beginners. You wouldn’t want to have say your email marketing campaign fail because you forgot to add the email marketing service into your SPF record and applied a reject DMARC policy.

The “quarantine” Policy

As it name suggests, the p=quarantine policy instructs recipient mail servers to quarantine emails failing at SPF or DKIM.

To quarantine an email means that the recipient mail server doesn’t deliver it to the recipient’s mailbox, but keeps it in some separate space.

If you suspect some emails weren’t delivered, or see legitimate emails failed to deliver in your DMARC reports, you can contact recipient mail servers to unblock quarantined emails (i.e. proceed to deliver them to their recipients mailboxes).

The quarantine policy is a middle ground between none and reject, for when you’d like to reject but you’re not yet entirely sure your setup is 100% correct.

The “reject” Policy

A p=reject policy instructs recipient mail servers to reject emails failing at SPF or DKIM, plain and simple.

Use that policy when you are certain that your SPF record lists all mail servers susceptible to send on behalf of your domain name, and that your DKIM record works.

It is recommended to look up DMARC reports for a while before using that policy, just in case you forgot something.

The “sp” Tag For Subdomains Policy (optional)

There’s also an optional sp tag to apply a different policy to subdomains (xxx.yourdomain.com).

The following DMARC record for instance defines a reject policy for subdomains and a quarantine policy for the root domain:

_dmarc.myfancydomain.com.	3600	IN	TXT	"v=DMARC1; p=quarantine; sp=reject; rua=mailto:dmarc-reports@myfancydomain.com"

Effect of the “pct” Tag (optional)

Keep in mind that policies other than none are applied with respect to the percentage given in the pct tag.

For instance, with a DMARC record having p=reject and pct=60, only 60% percent of emails failing SPF or DKIM will be rejected.

Since a 2013 update of the DMARC standard, the pct tag exhibits a fallback mechanism, meaning emails escaping the policy are subject to the lower policy. In our example, the remaining 40% of emails would be quarantined.

In previous DMARC versions the 40% would not have been quarantined. The recipient mail server may or may not have implemented the latest version of DMARC.

Note

The pct tag is not mandatory. Not including it in your DMARC record is equivalent to having pct=100.

The “akim” Tag to Adjust DKIM Alignment (optional)

The optional adkim tag is not often used. It allows you to set the level of alignment you want for DKIM, either relaxed (akim=r), or strict (akim=s). The default is relaxed.

Recall that alignment refers to the fact that the domains in the From header and in the DKIM-Signature header (in the case of DKIM alignment) are the same.

Well, a relaxed alignment accepts both a root domain and a subdomain as aligned, whereas a strict alignment only accepts an exact match.

From domain	DKIM-Signature domain	adkim=r	adkim=s
example.com	otherdomain.com	fail	fail
example.com	sub.example.com	pass	fail
sub.example.com	example.com	pass	fail
example.com	example.com	pass	pass

The “aspf” Tag to Adjust SPF Alignment (optional)

Similar to the akim tag, the optional aspf tag specifies whether the SPF alignment is relaxed (aspf=r) or strict (aspf=s). The default is relaxed.

With a relaxed alignment, the domains in the From header and the Return-Path header (i.e. envelope sender) are considered aligned whether they are root domains or subdomains.

A strict alignment on the other hand accepts only an exact match.

From domain	Return-Path domain	aspf=r	aspf=s
example.com	otherdomain.com	fail	fail
example.com	sub.example.com	pass	fail
sub.example.com	example.com	pass	fail
example.com	example.com	pass	pass

DMARC Reports

DMARC reports are a powerful tool for domain owners. They are usually delivered daily to the URI given in the rua tag of your DMARC record, if you set one.

A common practice is to use an email address:

rua=mailto:dmarc-reports@myfancydomain.com"

The reports come in XML format. They include some metadata and one or more records.

The metadata contains:

• The reporting organization identity (name, email address sending the report, and contact information).
• The report unique ID number.
• The date range the report covers.
• The domain name of interest.
• The policy settings.

Each record contains:

• The number of emails sent from a single mail server IP address.
• The SPF and DKIM tests results for these emails.
• Whereas the emails passed or failed DMARC.

Let’s see that in a practical example.

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <extra_contact_info>https://support.google.com/a/answer/2466580</extra_contact_info>
    <report_id>4457355241967157254</report_id>
    <date_range>
      <begin>1650326400</begin>
      <end>1650412799</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>myfancydomain.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>3.139.204.210</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>myfancydomain.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>myfancydomain.com</domain>
        <result>pass</result>
        <selector>s20200929392</selector>
      </dkim>
      <spf>
        <domain>myfancydomain.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
  <record>
    <row>
      <source_ip>149.72.146.168</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>myfancydomain.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>myfancydomain.com</domain>
        <result>pass</result>
        <selector>gxk</selector>
      </dkim>
      <dkim>
        <domain>sendgrid.info</domain>
        <result>pass</result>
        <selector>smtpapi</selector>
      </dkim>
      <spf>
        <domain>some.other.domain.com</domain>
        <scope>mfrom</scope>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Without detailing every single line, we can see that the report covers the domain myfancydomain.com having a none policy on the 2022-04-19, with two emails sent.

The first email was sent from IP 3.139.204.210 (a postale.io mail server) and successfully passed DMARC, with SPF and DKIM both passing and aligned.

The second message was sent from IP 149.72.146.168 and failed DMARC, due to SPF not being aligned despite passing for its domain (some.other.domain.com in the envelope address, whereas the From header uses myfancydomain.com).

The XML format is admittedly not very convenient to read DMARC reports. Fortunately, there are many free tools out there to convert them into more friendly documents.

A few of these are: easydmarc.com, dmarcadvisor.com, and the good old mxtoolbox.com.

The “ruf” tag

The ruf tag is similar to the rua tag and can be used to receive forensic reports. These are detailed failure reports with samples of emails having failed DMARC tests. It’s not often used and not widely supported by mail servers.

Why Having a DMARC Record Is Important

Having a DMARC record, along with SPF and DKIM records, is critical in protecting your domain from impersonators.

Without spoofing, your brand is better protected against scams which could harm its reputation.

With DMARC you’re also improving security, both for your recipients and for your organization, by preventing phishing attacks which could compromise your systems.

In addition, the protection provided by DMARC to your domain improves its reputation to mail services and other Internet services everywhere. As a consequence, both your domain and emails originating from it will be more trusted, enhancing your deliverability.

Finally, DMARC gives you visibility over your domain email activity, via its reports. You can check whether your SPF and DKIM setups work as intended, and take corrective actions if needed.

What DMARC Record You Should Use

The creators of DMARC recommend to use a none policy at first.

The idea is to start with monitoring only, fix your SPF and DKIM records if needed based on the reports, and progress to quarantine and then reject over time.

1. Deploy DKIM & SPF. You have to cover the basics, first.
2. Ensure that your mailers are correctly aligning the appropriate identifiers.
3. Publish a DMARC record with the “none” flag set for the policies, which requests data reports.
4. Analyze the data and modify your mail streams as appropriate.
5. Modify your DMARC policy flags from “none” to “quarantine” to “reject” as you gain experience.

Source: https://dmarc.org/overview/

Therefore, your DMARC record should initially look like this:

_dmarc.myfancydomain.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@myfancydomain.com"

Another reason to be extra safe at first is email forwarding/redirection. Some email addresses are configured to automatically forward emails to another address, without changing the sender address.

In such cases it can happen that the mail server doing the redirection is not allowed in the SPF record of the initial sender domain. In that case a none policy ensures the email is successfully redirected regardless.

While the none policy is the safest way to start using DMARC for most people, if you’re confident with your setup, you can of course start with a quarantine or even a reject policy right away. Nothing wrong with that.

How to Set Your DMARC Record

If you read our posts about SPF and DKIM, this part should be pretty familiar.

Enabling DMARC means adding a DNS record to your domain. You can do that by logging in to your domain provider website, and accessing its DNS editor.

If you’re not sure where that is for your provider, have a look at this list of DNS guides for common providers.

Here’s an example with a domain myshinynewdomain.com on Namecheap:

If you’re using postale.io as your domain email service, you can copy/paste the recommended DMARC record from the DNS configuration guide, or from the DNS diagnostics tool in your domain page on the admin interface.

How to Check Your DMARC Record

There are many online services to check the DMARC record of a domain, or its DNS records in general.

As usual mxtoolbox.com has a neat free tool dedicated to DMARC. And if postale.io is your domain email provider, the all-in-one DNS diagnostic page is hard to beat.

Over To You

I hope this article helped you in better understanding DMARC, and convinced you of its interest for your domain emails. It’s now up to you to add it to your domain, along with good SPF and DKIM records.

If you’re part of our community of users at postale.io and you have questions or experiencing difficulties with the subject, feel free to reach out to us! We’re always happy to help. 🙂

Related Posts