Understanding all the elements of a valid DMARC record

 

DMARC prevents threat actors from impersonating you or someone from your organization and sending spoofed emails on your behalf. However, it’s not easy to set up, manage, and adjust DMARC to ensure this prevention. One of the challenging aspects of DMARC is understanding the syntax and its use case scenarios; otherwise, your DMARC record can run into errors. 

DMARC syntax basically refers to the format and structure of a DMARC record that you publish in DNS. It’s like grammar rules; if the syntax is not correct, your DMARC record won’t work properly.

In this blog, we will break down every element of DMARC syntax and help you with the know-how to craft a DMARC record that is effective in stopping phishing and spoofing attacks.

 

Understanding the basics of DMARC syntax

Your DMARC record is basically a set of instructions for email servers. It tells them what to do when they see an email that looks like it’s from your domain. This record lives inside your domain’s DNS, and it’s stored as a TXT record with a special name: _dmarc.yourdomain.com.

 

 

Whenever an email server gets a message that claims to be from your domain, it checks this record to decide how to treat that email.

Now, the record itself might look a little scary at first, but it always follows the same pattern. For example:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

• It always begins with v=DMARC1. That’s like the record introducing itself, saying, “Hey, I’m a DMARC record.”
• The rest of it is made up of little tag-and-value pairs, separated by semicolons. In this case, p=reject and rua=mailto:dmarc-reports@yourdomain.com are two separate instructions.
• Each tag is just a short code, followed by an equals sign, and then the value.

Think of it as a compact set of rules. Each tag tells the email server something specific, like how to treat suspicious emails or where to send reports about your domain.

 

 

Breaking down all the DMARC tags

Here’s a tag-by-tag breakdown of all the elements of a DMARC record. Please note that you don’t have to add all the tags to your DMARC record. While some of them are mandatory, others are optional. Use the optional ones only when you are confident about their use cases.

• v= Version. Always written as v=DMARC1. Nothing to change here.
• p= Policy. This tells servers what to do with suspicious emails:
• none= Just watch, don’t block.
• quarantine= Put them in spam.
• reject = Block them completely.
• sp= Subdomain policy. Same as above, but for subdomains. If you don’t set it, they just follow the main policy.
• pct=  Percentage. Decide how much of your email the policy applies to.
• pct=100- Apply to all emails.
• pct=50- Apply to half.
• rf=  Report format. Tells servers what style of report you want. Default is afrf (you usually don’t need to change this).
• ri= Report interval. How often you want reports. Written in seconds. Default is 86400 (which is once a day).
• fo= Failure options. Controls when failure reports are sent:
• 1 → If anything fails.
• d → If DKIM fails.
• s → If SPF fails.
• rua= Aggregate reports. Where big summary reports should be sent. It is written like: mailto:reports@domain.com.
• ruf=  Forensic reports. More detailed failure reports. Same format: mailto:forensic@domain.com.
• adkim= → DKIM alignment.
• r → relaxed (close enough match is fine).
• s → strict (exact match only).
• aspf= SPF alignment. Same rules as above:

 

 

 

Troubleshooting invalid DMARC syntax

At times, even the most carefully set up DMARC record can become invalidated or encounter errors. Here are the common DMARC syntax issues and ways to fix them-

 

Missing required tags

It’s common for domain owners to forget to add essential tags to their DMARC records. Every DMARC record must begin with ‘v=DMARC1’ (the version tag) and must also specify a DMARC policy (none, quarantine, or reject).

Ensure that these necessary tags are always present and are used in the correct format.

 

Wrong tag sequence

Except for the v=DMARC1 tag, all other tags can appear in any order. It’s just the version tag that strictly needs to be in the very beginning of a DMARC record. It indicates that this particular TXT record is for DMARC.

 

Invalid policy values

The policy tag (p) only accepts one of the three values- none, quarantine, or reject. Adding any other value will simply invalidate your DMARC record.

 

 

Malformed email addresses

For the ‘rua’ and ‘ruf’ tags, make sure the email addresses are written correctly and always start with mailto:. Example: mailto:dmarc-reports@yourdomain.com

 

Invalid percentage value

The ‘pct’ tag only works with whole numbers between 0 and 100. If you’ve entered a decimal or value outside this range, simply correct it.

Ensuring the correctness of the syntax is not a one-time thing. There can be situations where the DNS entry is corrupted or the email sending practices have changed. That’s why you need to regularly monitor and check your DMARC records to ensure they are performing as intended. We suggest setting reminders to go through your DMARC record once every 3 months. Checking them monthly is even better.

Think of it as a small-time investment that can prevent bigger mishaps and troubles down the road. 

 

Best practices for DMARC syntax

DMARC might look scary at first, but it’s really not rocket science. It’s just some rules you put in your DNS to control how email servers treat your mail. If you follow the right way to write it (syntax), things go smoothly. If you don’t, you end up with errors and confusion. Here are some best practices that will make your DMARC setup strong and easy to manage.

 

 

Start simple

When you first get into DMARC, it’s tempting to try all the tags and make it look professional. But honestly, that just makes it harder for no reason. The smart way is to start small.

Your very first record can be something like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

This basic setup doesn’t block or reject any mail. It only monitors and provides reports. Think of it like putting a CCTV camera outside your shop; you’re just observing who’s coming and going. Once you’ve watched for a while and understood what’s happening, then you can start adding more rules.

Over time, you’ll learn which email sources are real and which ones are suspicious. After that, you can move from p=none to stricter options like quarantine or reject.

 

 

Keep checking your DMARC record

DMARC is not something you set once and forget about. Businesses change, email setups change, and attackers also change their tricks. So your record should also keep up.

• Every month: Check your DMARC reports. Are all your business emails passing? If something legit is failing, fix the issue before moving ahead.
• Every 3 months: Do a health check. Make sure all services that send email for you (like CRM tools, newsletters, and billing systems) are properly authenticated. Sometimes a new tool gets added, and people forget to set up SPF or DKIM.
• Annually: Look at your policy. If you’ve been running on p=none for too long, it’s time to consider stepping up to quarantine or even reject. The stronger the policy, the less chance of fraud.

Think of it like maintaining a car. If you don’t service it regularly, it won’t perform well. Same with DMARC.

 

Use a tool if things get complex

If you only manage one domain, you can probably do DMARC on your own. However, if you have multiple domains or a large company setup, it can become messy quickly. Reports are hard to read, and updates can be confusing.

This is where a DMARC platform like DuoCircle helps. With us, you don’t have to open raw XML reports and scratch your head. We:

• Collect reports and make them readable.
  
• Show clear charts, so you see what’s happening at a glance.
  
• Guide you step by step through the process of fixing problems.
  
• Help you update records across domains without mistakes.

 

 

Match DMARC with your business

Reaching to p=reject is a progressive, step-by-step process; you can’t do it in one day (not if done right). Your DMARC setup should ideally match how your business works. 

Ask yourself-

• How much do we use email? If most of our work or sales happen on email, then we need stronger safety.
• Can we take some risk? Some companies are okay with a little spam, but others can’t even allow one fake email
• Do we have people to answer if real emails get blocked by mistake?

The way you answer these questions shows if you should go slow or move fast to strict rules. The pct tag also helps. It lets you test stricter rules on just some of your emails before using them on all.

 

 

How DuoCircle helps

You don’t need to know everything about DMARC. That’s why DuoCircle is here. We’ve been doing email safety for a long time, and we already know the mistakes people usually make.

This is what we do for you:

• Expertise: We know DMARC really well and show you the right way.
• Automation: We take care of the boring stuff like collecting and reading reports.
• Clarity: Instead of confusing files, you get easy-to-read charts.
• Scalability: Doesn’t matter if you have one domain or a hundred, we keep them safe.

In email security, even a single weak point can cause significant problems. Don’t let DMARC be that weak point. With DuoCircle, it’s always done the right way.