So you’re looking to implement a DMARC policy for your company and are now scratching your head thinking, “What did I get us into?”
We’ve helped a lot of reputable senders work through and implement DMARC policies, so we have experience in some of the hurdles setting it up. Here’s what we’d advise.
***Before you get started, ensure that your domain is fully authenticated with both SPF and DKIM. If not, you want to start there first.
First, what is DMARC?
DMARC is short for “Domain-based Message Authentication, Reporting & Conformance”
DMARC is a simple TXT record you insert into your domain’s DNS. The record states a policy that fights phishing and spoofing attempts on your brand, utilizing the widely adopted authentication measures DKIM and SPF.
Here’s an example and while you’ll most likely never be touching this, understanding its two core functions will help along the way:
“v=DMARC1; p=none; rua=mailto:email@example.com;”
That looks like gibberish. How does this fight phishing and spoofing attempts?
If a mailbox provider has adopted DMARC standards, the policy tells them what to do with the message if either authentication method (SPF/DKIM) fails.
In the case above we’re working towards p=none in order to simply gain reporting. Here are the three levels your DMARC policy can be in.
- None: This means nothing will happen to failing messages. Your policy will only be collecting data and receiving reports sent to the RUA address (explained below) from participating mailbox providers.
- Quarantine: This tells the provider that every message failing either authentication (SPF/DKIM) should be placed in the spam folder instead of the inbox.
- Reject: The is the strictest policy you can be in. When in effect, messages will no longer be sent to the spam folder but will be rejected by the mailbox provider. The failing message will never be delivered to the end user’s email inbox.
The other main piece of your DMARC record you should know about it is your “RUA” address. This is the address to which DMARC aggregate reports are sent to.
Wait, who actually sends these?
You will receive these reports from mailbox providers (Gmail, Microsoft, AOL, Yahoo, etc). With DMARC being a relatively new standard, there’s still some providers out there who do not support the functionality. That being said, most all of your largest mailbox providers support this.
I understand the DMARC TXT record and I’m ready to give this to my DNS admin. Let’s go!
Well, not yet. We need to figure out how you’ll be collecting this reporting. The RUA tag in your record needs to have an address that will be monitored and managed by your team. Surprisingly, this can be the trickiest part of this whole process.
You’ll want to be monitoring these reports daily and taking action against possible phishing/spoofing attempts. Through these reports, you can also help clean up other problems in your sending infrastructure.
However, how to handle this comes down to your answer for this question:
Are you going to be the person looking at these reports on a daily basis, or are you going to offload some of this work to make life a little easier?
If you’re planning on doing the analysis in-house, there’s some free scripts at places like github.com you can work with in order to parse these large aggregate reports and make life a whole lot easier. You’ll also need to set up a generic mailbox (“firstname.lastname@example.org”) to start receiving these reports as mentioned above. Once you’ve added this to your TXT record and enabled your p=none policy, the reports should start flooding in.
The other and much easier option would be to use a paid service such as dmarcian or 250ok. Through their services, they provide you with an RUA address where the reports are sent and parsed through their infrastructure. They also provide a clean and easy to read UI. With this detailed information you can make adjustments to your mailing infrastructure to comply with DMARC standard. You can also spend more efficient time regurgitating the information to help fight against phishing/spoofing attempts.
My admin has inputted this record into our domain’s DNS, we’ve started to use a paid for service, I’m totally DMARC compliant, and ready to start diving into these reports!
Actually, there’s one more key thing to do first. You’ll need to be in “alignment”, making sure your SPF, DKIM, and returnpath (aka “mail from”) are all using the same sending domain located on your DMARC record.
Since the the “mail from” or returnpath is an address that the general public never sees (it’s located in the header of every email), its main purpose is to be there in case of a delivery error at the particular mailbox provider as they need to be able to return the error message back to its origination. Unless you’re handling your own infrastructure, this is up to your Email Service Provider (ESP) to have this enabled and working correctly.
At Dyn, we utilize a subdomain approach for implementing what’s called a custom returnpath. Our clients create a subdomain such as bounce.example.com, and then, we enable it on their account so all messages thereafter will replace our default Dyn returnpath. This approach also doubles as a white labeling solution for your brand which can come in handy for many reasons.
Here is an example of a domain not in alignment:
Sending domain: email@example.com
SPF record active: example.com
As you can see, the sending domain, DKIM, SPF are all example.com. The only problem is the sending domain for the returnpath is dynect-mailer.net instead of example.com.
Let’s implement a custom returnpath and fix that issue. Here’s a sending infrastructure in full alignment.
Sending domain: firstname.lastname@example.org
SPF record active: example.com
All domains match up and are fully aligned for example.com
With all of this said, you have all the info ready for your own DMARC compliancy. To review what you need:
- Authentication correctly in place for both SPF/DKIM
- A shiny new custom returnpath
- A service or yourself that will parse reports and action accordingly
- A DMARC policy set to p=none in order to start viewing what is happening
Simple as that!
Well, maybe it’s not that simple as there’s a lot of working parts with DMARC. For the purpose of this blog, I only skimmed the surface of what this function can really do. There are many more tags which allow you to get more granular for your mailstream. There’s also a whole other reporting tag where you can actually see the errant message!
Starting up a DMARC policy to p=none isn’t that complicated and if you’re a Dyn client, our email deliverability team can help walk you through this process, headache free.