Hi again. We’re back with more DMARC info to prepare you for Google and Yahoo’s requirement to have a DMARC record published for your sending domain.
Does this sound new to you? Don’t worry, we have more information about the new standards for those two mailbox providers here. If the concept of DMARC is new or unfamiliar, you can start here with our DMARC explainer before diving into the info we’ve got for you below.
We’ve got an understanding of DMARC, but now we need to actually do something about it.
It’s time to activate! And by that we mean learn how to generate a DMARC record and publish it in your DNS. The right way, too, not the bare minimum way Google and Yahoo require you to implement it. No cutting corners here.
What A DMARC Record Looks Like
It looks like code! Although it is really just a handful of what are called tag-value pairs. Unsurprisingly, it’s a little complicated. Here is what a complex DMARC record might look like:
v=DMARC1; p=quarantine; rua=mailto:[email protected],mailto:[email protected]; ruf=mailto:[email protected],mailto:[email protected]; fo=1; adkim=s; aspf=s; pct=50; sp=reject;
The good news is that most records won’t be that complex. Let’s walk through a more likely scenario where you just bought a domain called “example.com.”
Woah, congrats! You need to implement a DMARC policy on that baby. Let’s create our first policy. To start creating a policy we will need to answer these 6 questions:
- What type of DMARC policy do you want?
- What email address will you use to receive Aggregate Reports?
- What email address will you use to receive individual failure reports and in what cases do you want these to be sent?
- Should you use Relaxed or Strict alignment mechanisms?
- Do you want the policy to apply to all subdomains as well?
- What percentage of email do you want to apply this to?
Here’s what a DMARC record may look like for example.com:
v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1;
Short and sweet compared to the first example, right? You’ll see it is still made of several different chunks (tag-value pairs) of information telling mailbox providers what to do if things don’t go according to plan.
Let’s break down what everything is, chunk by chunk in this basic example:
- v=DMARC1: This indicates the DNS record is a DMARC record.
- p=none: This is the policy. Since this one is p=none, it tells receiving email servers that no actions like junking or blocking the message should be made if the message does not proper passing and aligned authentication.
- rua=mailto:[email protected]: This specifies the email address where aggregate DMARC reports should be sent. Aggregate reports provide summarized information about email authentication results. In this case, reports are sent to “[email protected].”
Remember, even though you do not NEED to have an email address here, you will not receive reports unless you do. Without reports, you won’t have the chance to discover and resolve issues, and your DMARC policy is a checked box rather than a functional tool for you. - ruf=mailto:[email protected]: This specifies the email address where forensic DMARC reports should be sent. Forensic reports provide detailed information about individual email authentication failures, which can be helpful for investigating and remediating issues. Our advice remains the same here. While any kind of report can be overwhelming, they exist for a reason!
- fo=1: This sets the reporting options. You can choose from four options:
- Fo=0 to get a failure report if both SPF and DKIM fail alignment
- Fo=1 for a report when any authentication method fails. So, if SPF fails but DKIM doesn’t, when you have fo=1 in your record, you’ll still get a report.
- Fo=d generates a report when DKIM fails any checks, not only alignment
- Fo=s generates a report when SPF fails any checks, not just alignment.
Now you’ll notice the policy we have we didn’t really answer all the original questions. That’s because DMARC policies have a default value or fallback for tags that are not present in a record. For the last question of “What percentage of email do you want to apply this to?”, the default is 100% if the tag for this is not present, so if we want to policy to apply to all mail then we don’t need to specify a “pct” tag-value pair. The same goes for applying the policy to subdomains, and for Relaxed vs. Strict Alignment. Use of strict alignment over the default relaxed is so rare we are going to skip it entirely for this blog.
With this info, if you know the kind of reports you want, the email address where you want them to go, and the policy you want to implement (start at p=none), you can put one together yourself. You can also just try out the handy-dandy SocketLabs DMARC policy generation tool here.
Before you do that, though…you might want to check to see if your domain already has a DMARC policy published. Since you know what it looks like, you can look at your domain’s DNS to verify you actually need one.
Publishing the DMARC record
Depending on what your expertise is, this could be super simple or…well, still pretty simple.
If you’re not someone with access to managed DNS records for your organization, you need to make friends with someone who does have access. They’ll be responsible for logging into it and putting things where they need to be. To make their lives easier, though, you can give them the following information.
If you are the lucky person who manages the DNS, here’s what you need to do:
- Access your DNS management tool
- Find the appropriate domain
- Insert the following information where indicated:
- Hostname should be _dmarc
- Resource type is TXT, since that’s what all DMARC records are
- Value is the DMARC record you created, which should follow the format we described earlier
Here is the SocketLabs.com DMARC policy for example: https://tools.socketlabs.com/dns/lookup/txt/_dmarc.socketlabs.com
Pretty painless!
I Did It. Now What?
Congratulations. You are the proud owner of a brand new DMARC policy! Take that bad boy out for a spin by sending your mail as usual. If you put in an email address to receive reports, you’ll be getting those for review once there is data to send back to you. From there, like we described in an earlier blog, you can make a whole bunch of discoveries and decisions to improve your performance and better protect your organization.
That being said, this can be confusing. Being a DMARC whiz doesn’t come overnight. If you need some extra help, you can book a consultation with us to get you what you need to be DMARC-ready, or if you want to outsource the process (no judgment here!), here’s a list of vendors who offer DMARC services. Good luck!
