Imagine that someone decides to “steal” your company domain and send phishing emails pretending to be you. Your customers lost money and gave out personal data thinking it was your business, the scandal got on the news, and your company’s reputation is ruined. Is there a way to protect your customers and your brand from such situations?
DMARC is one of the best practices that solve problems like this one. The acronym stands for Domain-based Message Authentication Reporting and Conformance. It’s a protocol that tells the server what to do with emails that don’t seem like they were written by you.
A DMARC record is plain text — like this one:
DMARC is a DNS TXT record. It means that it’s written in your website’s Domain Name System. Both people and machines understand it, that’s why it looks a little bit like code. Basically, it’s a list of variables. Each variable defines certain aspects of your DMARC policy — we’ll explain it in detail later.
We already mentioned that DMARC is an instruction on what to do with emails that failed authentication — let’s get into more detail.
Email authentication is the automated process which proves that an email came from the declared sender. There are a bunch of technical standards that make verification possible. We’ll stick to the two most common solutions — SPF and DKIM.
Sender Policy Framework, or SPF, is an IP-based email authentication protocol. An IP address is a unique series of numbers that identifies a device or a network. In this case, SPF scans the IP address of the sender’s server and checks if it’s allowed to send emails from it.
For example, if you use a SaaS platform like Selzy for email campaigns and your company’s address is [email protected], you give its servers the right to send emails from your mysite.com domain. And if SPF sees its IPs, they will be marked as trusted senders.
It’s not that hard to forge a domain name and send phishing emails using your company’s address. And SPF isn’t safe enough — spammers can trick this technology using a fake Return Path address and a legitimate “From:” email address. That’s why DKIM exists.
Long story short, DKIM, or DomainKeys Identified Mail is a digital domain name signature. When you send an email from your @mysite.com domain, your email provider receives a string of symbols that contain information about the email’s sender, date, and time. Then, the provider deciphers this string using the key that is linked to your @mysite.com domain. If the decoded data is correct, it means that the email is legit.
DMARC records complement DKIM and SPF for extra security. They’re not mandatory — but they give a good security boost. They protect your customers from spoofing and phishing by:
However, SPF and DKIM don’t deal with the “From:” email address. What DMARC brings to these protocols is the alignment — it means that the domain in the sending IP and the domain that is identifiable via DKIM must be identical to the declared sender domain. SPF or DKIM are good but they don’t provide that alignment. That’s why these protocols alone won’t help you find out if the email was forged — unlike DMARC.
DMARC is a good practice even for businesses that don’t use marketing emails. All companies can benefit from implementing DMARC records for three reasons.
People tend to believe that the declared “From:” email sender is the one who actually sent the email. But if criminals use your domain and company name for malicious emails, one phishing scandal is enough for your customers to lose trust. And in this situation, even the best email marketing strategy won’t save your business. People will keep assuming that your emails might be dangerous — and in the future, it will decrease your email campaign metrics and your brand will be considered untrustworthy.
A DMARC record protects subscribers from attacks performed under your company name and brand identity theft as well. It means that customers won’t be scared of clicking CTA buttons.
There are different opinions on how DMARC records affect email deliverability. Poor policy records can lead authentic emails to the spam folder. But without DMARC, such false positives occur more often.
With DMARC records, not only do customers trust you more — email providers trust you more as well. And if ISPs see you as trustworthy, they’re more eager to put your marketing emails in customers’ main inboxes. That’s why implementing DMARC records for any business improves email campaign visibility — more customers will see your emails, and they’re more likely to read them.
In 2021, the Internet Crime Complaint Center received almost 850 thousand cybercrime reports — and the total financial losses from cyberattacks reached $6.9 billion. And, as you can see, the frequency of email attacks has been growing over the last 5 years.
The trend has been stable — and there will be more complaints this year. That’s why it’s important to implement extra cybersecurity measures. And although DMARC is mostly for your customers, it protects your internal emails too.
In 2020, roughly 500 GoDaddy employees received the email with the “GoDaddy Holiday Party” subject line. In this email, employees were promised a one-time $650 bonus and asked to claim it.
But two days later those SaaS hosting platform employees who “claimed” the bonus received a follow-up where they were told they failed a phishing test and now they have to retake the Security Awareness Social Engineering training program. This scam was a test — but it doesn’t mean the real one isn’t possible. And DMARC records protect customers’ and employees’ privacy — suspicious emails won’t make it to the inbox.
All of this means that even if your business doesn’t work with email marketing, implementing a DMARC record will improve both external and internal security and increase customer trust in your brand.
We’ve discussed what DMARC is, how it works, and why your business needs it. Now let’s take a closer look at how to set up a DMARC record for your company’s emails.
Regardless of the email provider you use, DMARC won’t work without SPF and DKIM. That’s why during the preparation stage you need to set those up.
Setting up SPF. It takes four steps to set up SPF:
Setting up DKIM. This will require extra software. To implement DKIM, you need to install a DKIM package to your email server — for example, try OpenDKIM. You also need a DKIM key generator and a DKIM record checker — a lot of these are available online for free. Basically, you need to generate two keys, publish the private key, hide the private key, and configure the server.
If you’ve never done this before, take a look at our tutorial — we’ve covered both protocols there. But if you already have SPF and DKIM, you can set up your DMARC record. Keep in mind that both protocols must be implemented at least 48 hours before setting up the DMARC record.
As we’ve mentioned earlier, a DMARC record looks like a bunch of variables with values — some of them are mandatory, others are not. Take a look at this spreadsheet to learn more:
Variable | Is it mandatory? | Meaning | Possible values |
v | Yes | The version of your DMARC record | DMARC1 |
p | Yes | What to do with emails that failed authentication |
|
rua | Not mandatory but wouldn’t hurt | The email for DMARC reports |
mailto:[email protected] If you add this tag to your record, your email provider will aggregate daily XML reports and send them to the email address of your choice. |
pct | No | Sets the percentage of invalid emails that fall under the DMARC policy | 1 to 100 |
sp | No | Sets a different policy for subdomains | The same as for p — none, quarantine or reject |
adkim | No | Sets the strictness level of DKIM matches |
|
aspf | No | Sets the strictness level of SPF checks |
|
Let’s decode this example of a DMARC policy record.
v=DMARC1; p=quarantine; pct=45%; rua=mailto:[email protected] |
It means that 45% of emails that failed authentication will be sent to spam folders — and reports about these cases will be sent to [email protected]. Using the pct tag is useful if you’re only starting to implement DMARC — you can slowly increase the percentage to reach 100%.
Let’s take a look at another example.
v=DMARC1; p=reject; rua=mailto:[email protected] |
It means that none of the emails that failed authentication will be delivered — and reports will be sent to [email protected].
The rejection policy seems the safest option but it leads to a lot of false positives. For example, if you didn’t double-check your white list of email domains, emails from the SaaS payment system you use might fail to reach recipients. That’s why we suggest using this policy only if you know that someone is already sending spoofed emails pretending to be your company. We suggest using the quarantine policy — in this case, it’s up to recipients to decide whether your email is trustworthy. And, since you receive reports, you can use this information to improve both your mass mailing process and email content.
As we mentioned earlier, DMARC is a DNS TXT record. To publish such records, visit your hosting provider and choose “Create record”. Then, choose the TEXT type in this drop-down list.
But don’t be scared if your menu doesn’t look the same — different hosting platforms have different UI, so if in doubt, talk to tech support. However, no matter which platform you use, the DNS TXT record dialog box always has four input fields:
After filling in the form, click “Save” — and your record is published.
If you added the “rua” tag to your record, you can receive aggregated DMARC reports in the XML format and read them in the inbox of the email address you set. These reports are usually sent once a day and they look like this example from GlockApps:
There are two types of DMARC reports:
Both types of reports give you insight on who uses your company domain and how. And failure reports allow you to identify and combat attacks or troubleshoot your marketing emails.
Because of DMARC records, your legitimate emails might be marked as spam or rejected by a receiving server. Here’s what to do to resolve the issue:
DMARC is an extra security support. It will protect your customers and employees from phishing and spoofing. It’s a customizable DNS TXT record which instructs your email provider on what to do with emails that failed authentication. DMARC is a good practice, here’s why:
And if you’re convinced, here’s how to implement DMARC to your business: