Recently, two of the "Big 3" email providers, Google and Yahoo, have stated they will be implementing more strict policies around unauthenticated email messages. Specifically, they will begin rejecting messages which are unauthenticated and do not pass DMARC compliance.
As a result, the rush is on for small businesses to ensure their email passes DMARC compliance to avoid having messages rejected. DMARC has been a protocol that has flown under the radar however, so it's not widely known about for many SMBs. Today, we'll be telling you everything you need to know about DMARC, what it is, how it works and some guidelines on how it's implemented.
What is DMARC (and why do I need it)?
We'll start with the basics: DMARC, which stands for Domain-based Message Authentication, Reporting and Conformance (quite the mouthful!), is a business email protocol which ties two other technologies, SPF and DKIM, together to tell receiving email systems how to verify your email messages and what to do with them should they fail verification.
To visualize this a bit better, imagine the classic "snail mail" system. If you send a letter to a friend, you write out the letter, put it in an envelope and write the address of your friend, as well as your return address so the post office knows who to return it to in the event of an issue (and also so your friend knows who sent them the letter). Now lets say I'm a bad guy who wants to send a dangerous package to your friend. I put a label on the package and write your friend's address, and then I put your return address and dump it in at the post office. Your friend thinks you've sent them a package, only to realize too late they've been duped.
Email works much the same way. Cyber criminals often use this tactic called spoofing to send ransomware and other malicious emails to people who may think it's from you (when, in reality, you had nothing to do with it). DMARC (when combined with SPF and DKIM) works to verify any email received by someone with your return address on it, was actually sent by you and, as a bonus, also gives instructions on what to do with messages which aren't actually from you.
How does DMARC work?
As mentioned earlier, DMARC works with two other email protocols called SPF - Sender Policy Framework and DKIM - DomainKeys Identified Mail. Both of these protocols are used to authenticate email messages, to verify they're actually sent by who they say they're being sent by. While both of these protocols can be used to tell whether an email is real or fake, neither one does anything more than that, meaning the fake emails will still end up in mailboxes.
DMARC is used to cover this gap and instruct mail servers what to do with they receive those fake messages. You can specify for those fake messages to be left alone (useful for review purposes), quarantined (what this means can vary between email systems) or outright rejected.
It's important to note, DMARC itself doesn't block anything or do any sort of verification on it's own. It merely provides instructions to receiving email servers on what to do with emails with your company domain name of them. It is ultimately up to the receiving email system to honor those instructions and follow them.
So how do I implement DMARC?
Implementing DMARC boils down to a 2-step process: Implement SPF and DKIM DNS records, then implement a DMARC DNS record.
Implement SPF and DKIM
The first step is to get the two actual authentication protocols set up and going for your organization. Both of these deal primarily with DNS records created on the primary domain you send email from.
SPF: This deals with sender authentication, ensuring the received message comes from an authorized IP address (or, in some instances like O365, mail domain). To implement this, you will need to account for all of the sources your organization sends email from. For really small customers, this is usually just one or two places. For example, if your organization uses Office 365 for email, and you don't send email from anything else, your SPF record will look similar to the following:
v=spf1 include:spf.protection.outlook.com -all
In larger organizations, there may be additional addresses you'll need to include. This is especially true if you use services like MailChimp or similar email marketing platforms. You may also need to add a static IP for your office and include it in the record if you send from an on-site server or device (common with copy machines which scan to email).
DKIM is a little more complex. You will need to verify if each of the sources you listed out while creating the SPF record supports DKIM. Most modern services do, however there are still some which don't (the aforementioned copiers for example). For each of these sources, you will need to add their DKIM domain key as a CNAME record to your primary domain's DNS. An example key for O365 would look similar to the following:
selector1-companydomain-com01c._domainkey.companytenant.onmicrosoft.com
Where "companydomain" is the part of your email address after the @ (but before the .com) and the "companytenant" is the tenant of your O365 subscription. Other email providers will differ slightly but the general idea is still the same. Unfortunately, it's hard to go into exact detail of what will need to be entered as it's going to be specific to your company. Each service however will have at least one domain key you'll need to add a record for. It's important to track these keys, especially as you migrate to and away from various sending services (you don't want to leave a service you're no longer using authenticated for someone else!).
Implement DMARC
Once you have your SPF and DKIM records in-place. We'll need to add one more TXT record to get DMARC up and running.
The DMARC record can be a bit more complex depending on your company and email needs. The most basic record will look something like the following:
v=DMARC1; p=quarantine; rua=mailto:administrator@companydomain.com; pct=100;
We'll break this down into it's individual parts:
v=DMARC1; is the version of DMARC that is being used. Currently, there is only one version so this tag will always look just like this. In the future, further revisions of DMARC may add other versions.
p=quarantine; tells the receiving email server what to do with messages which do not pass authentication. There are three options: none, quarantine, and reject. "None" leaves the messages alone and won't block or drop them, "Quarantine" will vary depending on the receiving mail system; in some cases, it will put the message into the recipients junk folder, in other cases, it will put it in a separate quarantine which requires an IT admin to review and decide what to do with it. Finally, "Reject" tells the receiving mail system to just delete the message outright.
We recommend using Quarantine in most cases as this provides a good balance of ensuring non-authentic messages don't make it to people's inboxes but also gives some leeway in case you don't have things set up quite right in the SPF/DKIM departments. If you find your domain name is getting abused heavily, you may opt to switch this to "reject" for a time until the abuse subsides. "None" is typically only used for testing purposes.
rua=mailto:administrator@companydomain.com; is the email address of a company IT admin or other person where DMARC reports will be sent. These reports will come from each individual email system which receives email from your company domain within a 24 hour period. The report will list out how many messages from your domain were received and how many passed/didn't pass authentication, as well as the standards applied (and which authentication failed in the case of failures). If your company sends a lot of emails on a daily basis, we recommend using either a stand-alone mailbox to receive these reports to avoid inbox clutter for you or your admins. You can add more than one email address if needed, just separate them with commas.
pct=100; is a tag which affects the percentage of messages to be subjected to the DMARC policy. The default is 100 or 100%, which means all messages. A lower number will mean some messages will not have a policy applied. Generally, you want to leave this at 100 unless you have very specific reasons not to.
There are additional, optional tags which can be implemented dictating the strictness of alignment and reporting granularity. We won't cover these tags in this post as it's beyond the scope.
Common Questions
What will happen if I don't implement this?
Right now, not a whole lot. However, with Google and Yahoo now implementing stricter controls, you can bet the tide will be rolling for smaller systems as well which means, long-term, you will likely run into issues with email deliverability (ie: messages not making it to your intended recipients).
My email and domain is run by the company that hosts my website, what do I do?
There's a couple options you have. The first thing to do however is to see if they've already implemented DMARC on your domain for you. You can use websites like MX Toolbox to type in your company domain name and check if DMARC is detected. If it is, great! You're done! If not, you can try reaching out to your hosting company and see if they will implement it for you. If not, it may be time to look at potentially migrating to another solution which will enable you to implement it.
I run all my business email through @gmail.com or @outlook.com addresses, is there anything I need to do?
Personal email accounts already employ DMARC so you don't need to do anything. That said, it's usually not advisable these days to run business email from personal accounts. We recommend checking out the Benefits of Business-Class Email.
Authenticated Email
DMARC is quickly going from "good idea we should implement" to "critical component we need to have". As a result, it's important to take the time to determine and implement the correct settings to ensure all of your company messages get through, while messages from those who aren't you, do not.
We hope this guide is helpful, but DMARC can be a complex subject. If you find yourself overwhelmed at the thought of implementing or maintaining DMARC for your email systems, there's no harm in calling in some assistance and we're here to help. Feel free to reach out and we'd be happy to talk with you and assist.