A Guide to Increasing Your Email Security and Deliverability: DMARC
Category
Guides
Risk Level
This is part three of a three part series on securing your email. You can read part one here and part two here.
Also be sure to check out our Round Table discussion of this topic on Hive Live.
Have you ever found out that your email was being used to send spam - and when you check your “sent” folder, you don’t see any suspicious emails? Or have you ever had your legitimate emails end up in someone’s spam folder; including your marketing emails sent through third parties like Constant Contact, Mailchimp, Amazon SES, Salesforce, or SendGrid? This could be due to a simple misconfiguration that could cost you millions in lost revenue or impact your reputation. To boost your email security, we’re continuing a three part series to help you address these problems through the proper setup of your SPF, DKIM, and DMARC records.
Part 3: Creating a DMARC Record
DMARC (dee-mark) stands for “Domain-based Message Authentication, Reporting and Conformance” and is the final step to securing your email. It puts together a policy to officially follow what’s in your SPF and DKIM records. While many email providers will enforce your SPF and DKIM records, they are not required to do so. Enter DMARC - which lays down the law on what should be done when emails don’t meet the criteria outlined in your SPF and DKIM records. This is similar to the physical world, using our postal mail analogy, that while a letter may not have the right return address or proper notarization, a recipient still may open the letter and read it. DMARC sets the rules on what should be done with the letter (e.g. put the letter in the trash). In the digital world, the recipient is the receiving email server, who examines the email for both SPF and DKIM and then follows the rules outlined in the DMARC record - and either delivering the email, sending it to spam, or outright rejecting it.
There are three major benefits to implementing DMARC:
DMARC verifies that a sender’s email messages are protected by both SPF and DKIM;
DMARC tells the receiving email server what to do if neither of those authentication methods passes; and
DMARC provides a way for the receiving email server to report back to the sender about messages that pass and/or fail the DMARC evaluation.
Remember, you’ll need to have ideally set up both SPF and DKIM first (click those links to check out our posts about each), however it is possible to set up DMARC with only one or the other.
To start, collect a list of all your domains where you have created SPF and/or DKIM records. You should create a DMARC record for every domain you own. So once we’re done here, your DNS records will show the following:
One SPF record - containing all your SPF sender information in it
One or more DKIM records - one entry for each email company that supports DKIM
One DMARC record - containing your “policy” for what to do with the results from the two previous check.
For the domains that you use to send emails (i.e. email sent from yourname@yourorganization.com), follow the steps in Step 1. And for the domains that you own, but do not use to send emails (i.e. inactive or parked domains), see Step 2.
STEP 1: FOR DOMAINS THAT SEND EMAIL
Gather your list of domains where you have created SPF and/or DKIM records and head to your DNS provider. Remember, every DNS provider is different in their specific approach, but we’ll cover the general idea. For each DMARC record, you’ll create a new entry with the following values:
For the Name, set it to:
_dmarcFor the Type, set it to “TXT”
For the TTL, you can leave it as the default value or set it to “1h”
For the Data, this is where you’ll put your DMARC record. We recommend you use a DMARC record generator, like this one, to make this process easier. Once completed, your record will look something like this:
v=DMARC1; p=quarantine; pct=0; rua=mailto:yourname@yourorganization.com; ruf=mailto:yourname@yourorganization.com
So what do all of these parts mean?
v=DMARC1 - This indicates that it is a DMARC record. You will always start your DMARC record with this value.
p=reject - This is the where you set the “policy” for your DMARC record (i.e. what to do when SPF and/or DKIM fail). This can be set to “none" or “quarantine” or “reject” - see below for the implementation strategy on this part.
pct=100 - This is the “percentage” of how strict to apply the chosen option for the above “p=” value - see Step 3 below for the implementation strategy on this part.
rua=mailto:… - This is the email address where you would like your DMARC reports sent - see Step 3 below for the implementation strategy on this part.
ruf=mailto:… - This is the email address where you would like your DMARC forensic reports sent - see Step 3 below for the implementation strategy on this part.
STEP 2: FOR DOMAINS THAT DON’T SEND EMAIL
If you have any domains that do not send email (i.e. inactive or parked), it is recommended to publish a locked down DMARC record to prevent it from being abused. So create a DNS entry on those domains and create a DMARC record with the same information as above except set the Data as:
v=DMARC1; p=reject; pct=100STEP 3: IMPLEMENTATION STRATEGY
Unlike setting the SPF and DKIM records, configuring your DMARC record is more of an art than a science. If you set your DMARC record too strict too early, you can risk having your emails sent to your recipient’s spam folder, or worse, blocked and never delivered. We recommend the following approach - moving between each step as you feel comfortable. Generally, we recommend longer periods of time, like 3-5 weeks on the first few steps, and then moving to quicker intervals, like 1 week, for the later ones (you want to make sure you don’t miss anything, especially if you work for a larger organization):
v=DMARC1; p=none; pct=100; rua=mailto:yourname@yourorganization.comThis allows your DMARC policy to be created, and for you to receive your DMARC reports to the email address of your choosing. These reports are usually sent daily, and will come from every mail server who received one of your emails. As a result, you may receive a large number every day. In addition, the reports are in a format called XML - so you may want to use an online tool, like this one, to help make sense of the information.
This report is crucial to be able to show you any emails that either were sent directly from your domain, or on your domain’s behalf. The report also shows which emails did not meet the SPF or DKIM criteria, so that you can go back and add their information to your SPF and DKIM records if they are legitimate. For example, if someone at your organization sets up a new service, but forgets to tell you, those emails will be blocked until the SPF and DKIM records are updated. You would be able to see this information in the DMARC report and work with them to update the records accordingly.
v=DMARC1; p=quarantine; pct=5; rua=mailto:yourname@yourorganization.comOnce you think that you’ve tracked down everything and included the information in your SPF and DKIM records, it’s time to start enforcing it. By moving to “quarantine,” you’ll be telling email servers who receive an email from you to send it to spam if it doesn’t meet your SPF or DKIM records. Monitor the results closely to make sure that no emails are getting quarantined that shouldn’t be. Again, this report will provide you with this information
v=spf1 ip4:123.456.789.012 include:yourmarketingcompany.com -allIt’s time to go back and change your SPF record from a soft fail (i.e. “~all”) to a hard fail (i.e. “-all”). Monitor the results of this change in your DMARC reports.
v=DMARC1; p=quarantine; pct=50; rua=mailto:yourname@yourorganization.com; ruf=mailto:yourname@yourorganization.comContinue to turn up your DMARC record to be more strict, but also add in the “ruf” option, which will send you an email when an email explicitly fails your DMARC policy. This can let you catch problems with emails that are getting sent to spam, and help correct the issue sooner (e.g. tell a customer to go and check their spam folder).
v=DMARC1; p=quarantine; pct=100; rua=mailto:yourname@yourorganization.com; ruf=mailto:yourname@yourorganization.comYou are now at full quarantine. This means that any email that does not meet the SPF or DKIM records will be guaranteed to be sent to spam. You’ve now stopped hackers from impersonating your email address.
v=DMARC1; p=reject; pct=5; rua=mailto:yourname@yourorganization.com; ruf=mailto:yourname@yourorganization.comYou are now starting to reject emails. This means that any email that does not meet the SPF or DKIM records will begin to not be delivered. Continue to monitor the results closely in your DMARC reports to make sure that no emails are getting blocked that shouldn’t be.
v=DMARC1; p=reject; pct=50; rua=mailto:yourname@yourorganization.com; ruf=mailto:yourname@yourorganization.comYou are now blocking more emails that do not meet the SPF or DKIM records. Continue to monitor the results closely in your DMARC reports to make sure that no emails are getting blocked that shouldn’t be.
v=DMARC1; p=reject; pct=100; rua=mailto:yourname@yourorganization.com; ruf=mailto:yourname@yourorganization.comCongratulations, you made it! You are now blocking any email that does not meet your SPF or DKIM records.
STEP 4: VALIDATE AND MONITOR
After you make the changes to your DNS, you’ll generally have to wait about 48 hours for the changes to propagate across the internet. After that time, you can check to see if your new DMARC record is valid using an online tool, like this one. Remember to add any new email companies that you use in the future to your SPF and DKIM records, otherwise the emails won’t be delivered! Also continue to monitor your DMARC reports as they come in to validate everything is still working appropriately, or if there are any changes.
“Is that it?”
That’s it for SPF, DKIM, and DMARC records! But the process of securing your email is always growing and changing. For example, many email providers will soon begin to support something called BIMI, or “Brand Indicators for Message Identification,” which will set a trusted image for email senders (i.e. your organization’s logo will appear anytime an email is sent either from, or on behalf of, your organization"). But in order to implement this standard, you have to have DMARC fully set up.
We’ve covered a lot of information in this series. So if you’re unsure about how to tackle SPF, DKIM, or DMARC records, CONTACT US TODAY and we’ll help you secure your email and your marketability. Just ask Hitting Cancer Below the Belt:
Learn about how Hive Helps can provide pro bono cybersecurity consulting for your nonprofit at https://t.co/PfzTXTutom pic.twitter.com/6JbJbAuHa4
— Hive Systems (@hivesystems) September 29, 2020
Follow us - stay ahead.
Read more of the ACT
It's the 2024 update to our Hive Systems Password Table - including using a new “most-hacked” password hash. See why our Password Table has been shown and written about on the news, published by universities, and shared by companies across the globe. How did we make this table? Want to download a copy? Read on!