DMARC (or ‘Domain-based Message Authentication, Reporting and Conformance’) is a system designed to strengthen your email security by making it significantly harder for spammers to hijack your domain and send email that appears to be coming from you and your domain without your knowledge or permission.
DMARC has been in use now for a while and most larger mail providers including Microsoft, Google, and Yahoo all now require it in order to accept mail from a domain.
It has two primary jobs. First, it works with your domain’s existing SPF and DKIM records and instructs the world at large exactly what they should do when they detect a message that fails one or more of these other systems. Second, it provides those remote servers a channel to communicate back with you about what they’ve detected and how they’ve dealt with it — the ‘R’ in DMARC.
Unlike SPF and DKIM, DMARC requires a bit of maintenance to use correctly. If installed incorrectly it can cause severe impacts to your email causing legitimate mail from your domain to be treated as spam and deleted, without your recipient ever knowing. This article is here to guide you on what we’ve found to be the best way to set up DMARC so that you get all the security you’d expect without harming your normal mail activities.
Step 1) Get your SPF and DKIM Working
DMARC is an extension to SPF and DKIM, so if you don’t have a working SPF and DKIM record yet, you’ll need to get that working first.
We have a quick how-to guide on our Knowledge base for how to set up SPF and DKIM using the ’email deliverability’ icon in cPanel.
SPF
SPF (Sender Policy Framework) is a system that uses DNS to tell the world which machines are allowed to send email from your domain. Each domain gets its own SPF, and if you have multiple services that send email from your domain, they’re all rolled-up into one SPF record.
The default SPF record you get on one of our servers doesn’t allow third-party mail services to send email from your domain. Any third-party service you use should be able to tell you what to add to your SPF record so that they can be authenticated. This is usually done by adding an “+include:” to your record.
The last thing to mention about SPF is that it has a ‘softfail’ mode. This makes it less-strict than a normal SPF record. We’ll come back to this.
DKIM
DKIM (DomainKeys Identified Mail) is a second authentication system that is a bit more granular. It works in conjunction with SPF, but one key difference is that each email service provider has their own DKIM key, sometimes more than one.
When you set up DKIM on a HostUpon server (or any other cPanel service) it will install a DKIM record for you but this key only authenticates messages that come from that cPanel server. If you use third-party mail services, they should also be able to provide you with their DKIM record so that messages they send can be signed using that separate key.
This means a domain can have one SPF, but multiple DKIM keys. A message sent from your domain only has to be linked to one of these keys in order to be considered authentic.
Step 2) Your first DMARC record
You read that right. Your DMARC record shouldn’t be set to the ‘final’ version immediately. If you do that you run some pretty high risk that you’ll break your email in ways that could be hard to diagnose. Your first record will actually be a neutered record that only reports back to you without telling remote servers to do anything to emails that fails SPF or DKIM.
Why Even Have a DMARC Though?
Without even taking into consideration that some mail services online are now requiring one, there are a couple reasons. DMARC fills a couple security holes in your email security that DKIM and SPF alone don’t cover.
SPF is great for telling a remote server that a message didn’t come from an authenticated source, but it doesn’t protect you from email that is sent from a subdomain of your domain. I’ve personally encountered a couple examples of spear-phishing that used this exact hole to skip right past SPF and unless you were extremely observant messages like this looked fairly legitimate.
Likewise DKIM is optional. Messages that are sent from a server without DKIM support aren’t flagged as a false message automatically. DKIM only provides reinforcement to a message’s reputation when it passes. A lack of a DKIM signature in a message doesn’t automatically fail that message.
DMARC covers both of these holes. When used properly it will tell remote servers to require at least one of these (SPF and DKIM) to pass before a message is considered authentic, and it will also fail any message that doesn’t line up exactly with the domain.
So what should your first DMARC look like?
There are a lot of elements involved in a full DMARC record. For details on exactly how to install a DMARC record on a cPanel server, and what each little option does, check our our knowledge base article all about DMARC. That KB article has some tips on what your DMARC should have but this article will go into more detail.
Above all else, your first record should have your Policy set to ‘none’ and your subdomain policy should match. With P=none, DMARC is in safe-mode. It will still be used to check all your email’s authentication, but no action will be taken beyond what SPF does on its own without the support of DMARC.
The Alignment settings should be set to ‘strict’ as well. Since we’re in testing mode, we want to know if messages that should pass are failing SPF or DMARC checks.
You can install DMARC on a cPanel server using the ‘zone editor’ icon in the ‘Domains’ section. If you have one already, you can edit the one you have, or you can add a new one using the “+Add” button in the top right
If you send email from subdomains, you should install a set of SPF, DKIM, and DMARC records for each subdomain. The root DMARC record will apply to any subdomain that doesn’t already have its own DMARC record.
You should then specify an email address for both Aggregate reports, as well as Forensic Reports. You may need to set a custom email address up for this.
Unless you’re using a mail service provider that explicitly does not use both SPF and DKIM (Mailchimp is a notable example — they only support DKIM) Then the recommended setting for Forensic reports is if ‘Any Check Fails’ (fo=1). This will mean that any message that fails either SPF or DKIM will be reported back to you, even if the other check passed. This is useful for detecting when your SPF or DKIM is malfunctioning.
Step 3) Tightening the Rules
There’s three main phases to fully securing your messages with DMARC. As we mentioned earlier, your first rule should be…
p=none; aspf=s; adkim=s
With your policy set to ‘none’ your mail will be handled as if your DMARC record doesn’t exist. Messages will be handled according to your existing SPF and DKIM settings, which means messages that fail *both* of these will likely not be delivered, but edge-cases will probably be delivered.
You should also set the SPF and DKIM alignments to ‘strict’ to make sure that DMARC knows it should be strict with both these systems.
There’s one important exception though. While mail delivery patterns won’t change, with a DMARC record mail servers will start watching and will take note of when a message *would* have been denied by DMARC. These will show up in the failure and aggregate reports that these external providers will send you.
This means your DMARC record should contain at *least* an aggregate reporting address, and it probably should have a forensic reporting address as well.
In this mode, you’re looking for messages that you know you sent properly, but were flagged by DMARC. If you find any in your reports, you may need to adjust your SPF and DKIM rules to make sure those messages are authenticated properly.
If you don’t spot any issues with mail delivery but your SPF is still set to ‘softfail’ this is a good time to upgrade it to full fail, by changing the “~all” bit at the end of the rule to “-all”.
After a little while (I’d recommend at least a week, maybe a month) it’s time to step it up to…
p=quarantine; sp=quarantine
In this mode, message that fail DMARC security will still be delivered however they won’t be sent to the inbox, but will be flagged as spam. All the same aggregate and failure reports will be sent to you but now messages that should have been delivered will show up in spam folders instead of inboxes.
It’s a lot like ‘P=none’ but now it’ll be more obvious since now your recipient will be able to tell mail delivery issues are happening. We’re also starting to take control over subdomains, including potential subdomains that don’t exist. This is important for detecting when bad actors try to ‘make up’ an email address on a subdomain of your domain to try and slip past standard SPF.
Once you’re sure all your normal mail activities are being sent correctly, it’s time to push it up to…
p=reject; sp=reject
This will put DMARC into full active mode. Messages that fail DMARC will be actively rejected by mail server worldwide and you’ll get reports of this in your aggregate and failure report addresses.
It’s only in this mode that certain types of phishing messages from malicious actors will actually be denied delivery!
Some Final Notes…
Tuning DMARC to Handle Partial Failures
It’s important to note that the default DMARC threshold is to only flag a message as a problem when ‘all checks fail’, that is when a message fails SPF and when there’s a broken or missing DKIM signature in the message. Not all mail senders use both mechanisms though. If any of the services you use for your outbound mail do not use both SPF and DKIM, you’ll need to make sure your DMARC record is configured to only generate failures when “all checks fail” (or ‘FO=0’ in the raw DMARC record).
If all of your mail vendors authenticate all messages with both DKIM and SPF, then switching your setting to ‘FO=1’ (“Any Checks Fail”) will tighten your security just a bit more.
Not all Mail Providers Send Forensic Reports
Even if you specify a forensic reporting address many of the larger mail providers will ignore this setting and only send aggregate reports. Take advantage of the forensic reports when you get them, but don’t assume you’ll always get a forensic report of a failure.
Too Many Delivery Issues enabling P=quarantine?
If you find that too much of your email is being quarantined when you first switch from a ‘none’ policy to ‘quarantine’ you can set the ‘percent’ setting to a value lower than 100, perhaps 10, or 25. This will limit the impact of your DMARC rule until you can iron out why your messages are being blocked. As you fix your SPF and DKIM rules to properly cover your messages you can ramp up the percentage. Keep watching your reporting addresses and react as needed if things change, but eventually you’ll be able to get it back to 100%.
And That’s It!
DMARC is a system designed to tell the world who is allowed to send email, and who isn’t. Once you’ve got your policy ramped all the way up to ‘reject’ it’ll be very difficult for a spammer or scammer to send email that appears to come from any part of your domain.
Add comment