Have a question?
Message sent Close

DMARC Troubleshooting Guide

Common DMARC Mistakes and Fixes

Intro to the DMARC Troubleshooting Guide

What is DMARC

Domain-based Message Authentication, Reporting & Conformance (DMARC), is an email authentication, policy, and reporting protocol.

DMARC is a way to determine if a given message is legitimately coming from a sender and what to do if it isn’t.

It relies on the popular SPF and DKIM protocols

It tells the ISP what to do if none of these email authentication methods pass (e.g. «reject the message» or «send it to spam»)
It sends reports to the Sender, detailing how many messages passed or failed the DMARC check.

When an inbound mail server receives an incoming email, it uses DNS to look up the DMARC policy for the domain contained in the message’s “From” (RFC 5322) header.
The inbound server then checks three key factors:

  • Does the message’s DKIM signature validate?
  • Did the message come from IPs allowed by the sending domain’s SPF?
  • Do the headers in the message show proper “domain alignment”?

TopDeliverability DMARC Field Manual

This DMARC Troubleshooting Guide wants to provide an easy way to solve common issues and mistakes while dealing with DMARC records. It’s meant to be read and used by everyone, regardless their level of knowledge and understanding of Email Authentication.

In order to make this DMARC Guide a true “Field Manual”, the main focus is on Common Mistakes (and Solutions) with regards to DMARC Records.

DMARC Syntax For Dummies

A DMARC Record looks like this:
E.g.: v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@example.com

Now let’s see what each part means.

v=DMARC1 this element identifies the record as DMARC
p=reject specifies the preferred treatment
pct=100 is the percentage of mail to which the domain owner would like to have its policy applied
rua=mailto:postmaster@example.com the mailbox to which aggregate reports should be sent

DMARC Policies For Dummies

The DMARC specification provides three choices for domain owners to use to specify their preferred treatment of mail that fails DMARC validation checks.

These “p= policies” are:

  • none: treat the mail the same as it would be without any DMARC validation
  • quarantine: accept the mail but place it somewhere other than the recipient’s inbox (typically the spam folder)
  • reject: reject the message outright

NOTE: it’s up to the inbound mail server to decide whether to honor the requested policy

Table of Contents

  • INTRO TO DMARC TROUBLESHOOTING
    • What is DMARC
    • TopDeliverability DMARC Field Manual
    • DMARC Syntax for Dummies
    • DMARC Policies for Dummies
  • COMMON DMARC MISTAKES
    • Too strict, too soon
    • Rua/Ruf on a different domain but no report authentication record
    • Ignoring subdomains
    • Partial enforcement
    • Syntax error
    • Omitting a reporting address
    • Problem with SPF or DKIM
    • Wildcard Record
    • Wrong location
    • Multiple DMARC records
    • Requiring strict alignment when this can’t be achieved
    • Too relaxed, for too long
    • Ignoring DMARC reports
    • Forgetting/ignoring legitimate mail streams
    • Stopping at p=reject sp=none
    • Specifying implicit tags
    • Not implementing DMARC on inactive domains

Common DMARC Mistakes

Too strict, too soon

You want your DMARC in enforce mode, we get it, but please DON’T RUSH! There’s a reason DMARC has 3 progressive policies (in this order): none, quarantine and reject.

HOW TO FIX IT: Make sure to start with a p=none and move to the next stricter policy only when you collected enough data (and fixed the authentication of all your legitimate mailstreams) to do it confidently.

Rua/Ruf on a different domain but no report authentication record

DMARC records include reporting addresses. If those addresses are not on the same domain, an authentication record is required.

HOW TO FIX IT: make su your RUA/RUF addresses are either on the same domain or on a domain authorized to receive reports from your domain. If your sending domain @example.com has a DMARC record with @example.net email addresses, create a TXT record at example.com._report._dmarc.example.net (Report Authentication Record) with the value “v=DMARC1″. Alternatively, you can create a wildcard record *._report._dmarc.example.net to accept report for any domain name with the same value.

EXAMPLE: if your sending domain is @reallygoodsender.com has a DMARC record with @sendmedmarcreports.net email addresses, create a TXT record at goodsender.com._report._dmarc.sendmedmarcreports.net (Report Authentication Record). Alternatevily, you can create a wildcard record *._report._dmarc.sendmedmarcreports.net to accept report for any domain name.

Ignoring subdomains

Ignoring subdomains while implementing DMARC is a recipe for disaster. Unless a sp= tag is specified, subdomains will get the same policy of the parent domain.

HOW TO FIX IT: make sure to map all your subdomains and monitor them using DMARC report. You might want to start with a p=none sp=none, progressively move toward a p=reject sp=none and THEN moving your sp from none to reject. The pct= tag and the quarantine policy will help do it smoothly. Don’t skip any step!

Partial enforcement

By default, a DMARC policy applies to 100% of all mail unless a percentage is specified with a pct= tag. Unfortunately, if you are at p=quarantine and set a percentage less than 100, that means that some spoofed messages will still be delivered. There is no such thing as “partial” DMARC enforcement. While there are ways to use percentages usefully, don’t fall into the trap of thinking you’re fully protected if your pct= tag specifies anything less than 100%.

Syntax error

Any typo or syntax mistake in your DMARC record can easily invalidate the whole record making it useless.

HOW TO FIX IT: make sure to validate your DMARC record with online tools.

Omitting a reporting address

The very nature of DMARC is generating a report. Omitting a reporting address is a big mistake will give you 0 visibility on your unauthenticated traffic and abuses of your branded domain.

HOW TO FIX IT: In your DMARC, always include the rua tag with at least 1 valid (and manned) email address.

Problem with SPF or DKIM

DMARC relies on SPF and DKIM. Ignoring problems with your SPF or DKIM will consequently cause your DMARC to fail on your legitimate traffic.

HOW TO FIX IT: review your mailstreams and, before anything else, make sure to authenticate them with DKIM. Align your SPF whenever is possible (depending the mailstream, it won’t be possible OR it will require a special configuration – DKIM alignment is usually easier to achieve). Please check our dedicated guides: SPF Troubleshooting and DKIM troubleshooting.

Wildcard Record

When speaking of DNS, a wildcard record is one that will be returned for any matching query. For example, a wildcard record can be defined or published as *.example.com, and any request that matches will receive that value. So cat.example.com or zebra.example.com will match this wildcard, and so will _dmarc.example.com. This will interfere with DMARC and will potentially cause a number of other issues.

HOW TO FIX IT: avoid wildcard records for 3rd level domains and make sure to explicitly implement DMARC on the _dmarc subdomain.

Wrong location

DMARC record should be published on the _dmarc. subdomain. If your domain is “example.com”, DMARC should be published on “_dmarc.example.com“. It’s that simple. Unfortunately it’s not rare to see a DMARC record on the root domain or on a different location.

Some DNS providers auto-append your domain name so you don’t have to type it – others will require you to type the full location. If you do the latter with a provider that auto-appends your domain, you will end publishing the key on a wrong location. Something like _dmarc<.mydomain.com><.repeateddomain.com> instead of _dmarc<.mydomain.com>.

HOW TO FIX IT: make sure to publish your DMARC record on the _dmarc subdomain. If you can’t find your DMARC record after publishing, make sure to double check if you published it on the wrong location by mistake.

Multiple DMARC records

A domain can have only 1 DMARC record. Having more than 1 DMARC record will inevitably cause issues and authentication errors.

HOW TO FIX IT: make sure to have only one TXT record on _dmarc.example.com

Requiring strict alignment when this can’t be achieved

A key DMARC concept is “Alignment”; this could be either “relaxed” (domains should share the same root domain) or “strict” (domains should match exactly). Strict alignment might seems a great idea but it’s not for everyone. Literally. Depending the mailstreams, you can only achieve a relaxed alignment.

HOW TO FIX IT: avoid strict alignment (don’t use any of the following: aspf=strict or aspf=s, adkim=strict or adkim=s)  unless you are 100% you can achieve it. Don’t use the aspf and adkim tags at all or explicitely require a relaxed alignment (so aspf=r or aspf=r and adkim=r or adkim=r are much safer options) to avoid unwanted issues.

Too relaxed, for too long

A relaxed policy (like a p=none or any other policy with a low pct value) fulfills a very specific need at a very specific stage of the DMARC implementation process.

HOW TO FIX IT: Keeping a relaxed policy for too long defeats the purpose of DMARC. While each case is very different (so we can’t provide a recommended time for each phase) make sure to enforce a stricter policy as soon as you investigated and authentication all the failing traffic.

Ignoring DMARC reports

What is the point of setting up DMARC if you are literally ignoring the reports it generates? DMARC reports contain key information and insights on who might be abusing your brand or what part of your legitimate traffic is not properly authenticated.

Forgetting/ignoring legitimate mail streams

Similarly to the previous mistake, you should read your DMARC reports and make sure that even the smaller mail stream is authenticated. Everything is significant and should be DMARC compliant if you want to take full advantage of DMARC.

Stopping at p=reject sp=none

If you enforced a stricter policy on the parent domain, you might have specified a “none” subdomain policy. This is perfectly fine, but just like with the p=none, this is meant to be temporary until you authenticate your legitimate traffic.

HOW TO FIX IT: Don’t forget the sp tag! Analyze your data and move forward with a stricter policy as soon as you can.

Specifying implicit tags

There are a number of implicit tags: if not specified they are assumed to be present with default values. While this is not necessarily a big problem, it can be considered a mistake. Let’s take pct=100 for example. Is that really needed? Definitely not.

Not implementing DMARC on inactive domains

Do you own a bunch of inactive or parked domains? Are they protected by DMARC? well, they should be!

HOW TO FIX IT: Make sure to implement a DMARC with a strict policy (v=DMARC1; p=reject;) on each domain you own that is not being used for sending mail. And please, do it NOW.

If you liked this DMARC Troubleshooting Guide,
you will love the SPF Troubleshooting Guide
and the DKIM Troubleshooting Guide!

This website uses cookies and asks your personal data to enhance your browsing experience.