You are the owner of your own domain. It represents your brand in the best way possible: it is already known by your customers and they are expecting your emails.
But what if one day someone sends an email from your domain offering the same content that you offer to your customers and just pocket the money? Doesn’t sound good. To top it all off, it’s hard to convince people that it wasn’t you…
So keep reading about the amazing powers of DMARC and find out how to avoid such uncomfortable situations.
What is DMARC?
Domain-based Message Authentication Reporting and Conformance (DMARC) is an email validation system created to protect your domain from being used for email spoofing, phishing scams and other cybercrimes.
Think of it like your own personal security guard for your domain. DMARC was created by PayPal with help from Google, Microsoft and Yahoo! as an email security protocol. These industry leaders came together to develop an operational specification, with the desire that it would be able to achieve formal standards status. At this point DMARC is a necessity for the online security of one domain.
When you as a domain owner set up a DMARC record into your DNS record, you will gain insight into who is sending emails on behalf of your domain. DMARC uses the email authentication techniques SPF (Sender Policy Framework) and DKIM (Domain Keys Identified Mail) and adds an important function – reporting.
This means no one will be able to borrow your domain to send an email asking for a $100 donation for the Amazon rainforest and then use the money to buy a new yacht… to go see the Amazon rainforest.
How does DMARC work?
As we mentioned, DMARC relies on the established SPF and DKIM records for email authentication. But unlike SPF and DKIM, a DMARC record could tell the server if he should or shouldn’t accept a message. With DMARC, it becomes possible to gain insight into phishing attacks. This way, customers can be informed in advance and will be aware of attacks.
Every major ISP server performs a DMARC check nowadays and the implementation of DMARC happens more and more frequently. Now let’s take a look at how the record works and understand why we need it.
The process of DMARC validation works as follows:
- The domain owner sets the policy, choosing its email authentication practices and how the recipient servers should handle mail that violates this policy. This DMARC policy become part of the DNS records of this domain.
- In case that the inbound mail server receives an incoming email, it uses DNS to check the DMARC policy for the sender domain in the “From” (RFC 5322) header. The inbound server then evaluates the message based on three key factors:
- Is the DKIM signature correct?
- Is the sender IP included in the SPF record?
- Do the headers in the message show proper “domain alignment”?
- When the information is collected, the server can decide what to do with the message according to the DMARC policy.
- The server will inform the domain owner for the outcome and what has happened with the message.
To put it another way, DMARC allows you to secure your domains and decide what should happen when recipient servers receive unauthenticated mail coming from your domain. DMARC is a very powerful solution to fully secure your email domain when configured correctly.
DMARC explained
To understand DMARC even better, we will explain what each part of it means. It might look like strange symbols that don’t have any meaning and the only thing you will understand is your domain, but that’s why we are here to help you.
Once you are done reading this article you will “speak” fluent DMARC language. Let’s start with how a DMARC looks, and then go through it piece by piece:
“v=DMARC1;p=none;pct=100;rua=mailto:[email protected];ruf=mailto:[email protected];rf=afrf”
“v=DMARC1”
v=DMARC1 is the identifier that the receiving server looks for when it is scanning the DNS record for the domain it received the message from. If the domain does not have a txt record that begins with v=DMARC1, the receiving server will not run a DMARC check.
Policies:
“p=none” tells the receiving server what to do with messages that fail DMARC. There are three policy options – none, quarantine and reject. What policy is best for you depends on your needs.
Let’s dig a bit deeper into them, because we dare to say that this is the most important part of the record.
Monitor policy: p=none
The DMARC policy “none” tells the email receivers to send DMARC reports to the address published in the “rua” or “ruf” tags of the record. It is known only as a monitoring policy because with it you gain insight in your email channel. But, it does not instruct email receivers how to handle emails that fail the DMARC checks. You can use the “none” policy to start with DMARC and gather all DMARC reports and start analyzing this data.
Quarantine policy: p=quarantine
Another type of policy is the “quarantine” one. This DMARC policy instructs email receivers to put emails that fail the DMARC checks in the spam folder and also sends the DMARC report. The quarantine policy already controls the impact of spoofing, but spoof emails will still be delivered to the receiver (but in the spam folder… and who is checking that, right?).
Reject policy: p=reject
The third policy is the “reject” one. Besides sending DMARC reports, the DMARC policy completely rejects the emails that fail the DMARC checks. All other emails that pass the DMARC checks will be delivered in the primary inbox of the receiver. This policy best mitigates the impact of spoofing.
“rua=mailto:[email protected]”
This tells the server where to send aggregate reports of DMARC failures. We’ll see more about the reports in the next section of the article. You can add any email address you choose or even add multiple ones.
“ruf=mailto:[email protected]”
This is for the forensic reports of DMARC failures. With this, there is one requirement for the email address – it must be from the domain that the DMARC record is published for.
“rf=afrf”
Once we chose the email address where we want the reports sent, we should choose what kind of reporting we want. In this case rf=afrf means aggregate failure reporting format. This would be perfect for you, if you have a system already set in place that monitors those reports.
“pct=100”
This part of the record tells the server how much of their mail should be subjected to the DMARC policy’s specifications. In this case, if the p= (remember the three policies up above?) was set to reject, 100% of the mail that fails DMARC would be rejected.
Other key mechanisms:
There are a number of other mechanisms that can be included in a DMARC record. A few important ones are:
“sp”
This part would tell the receiving server whether or not to apply the DMARC policy to sub domains. The values are the same as “p=”.
“adkim”
This sets the DKIM alignment. It can either be set to “s” for strict or “r” for relaxed. Strict means the DKIM portion of DMARC authentication will only pass if the d= field in the DKIM signature exactly matches the from domain. If it is set to relaxed, messages will pass the DKIM portion of the DMARC authentication if the DKIM d= field matches the root domain of the from address.
“aspf”
Indicates strict or relaxed SPF identifier alignment. The default is relaxed.
“ri”
This sets the interval for how often you want to receive aggregate reports about DMARC failures. The default value is 86400 seconds which is equivalent to one day.
Let’s stop here before it gets too overwhelming and see know what a DMARC report shows and how it helps your brand to avoid any spoofing.
DMARC reports
As we saw in the previous section, the reports can be two different types: aggregated and forensics. Those reports help you ensure you that you are properly authenticating your outbound emails. You can check out the difference between both of them below.
Aggregate reports
They are XML documents showing data about the messages received that claimed to be from a particular domain. Those reports are meant to be machine-readable. Here’s one example:
Forensic reports
These are individual copies of messages which failed authentication, each enclosed in a full email message using a special format called AFRF. Those reports are easily read by a person, too. The information that those reports could contain is:
- Subject line
- Time when the message was received
- IP information
- Authentication results
- SPF result
- DKIM result
- DMARC result
- From domain information
- From address
- Mail from address
- DKIM from address
- Message ID
- URLs
- Delivery result
- What was the applied policy, the message could be rejected if there’s a reject policy in place, or quarantined, or delivered because of a none policy
- ISP information
Now we know how a DMARC works, how it looks, and what information it provides. We’re pretty certain you already know how useful this could be for you. But let’s see all advantages in the next section.
Do I need DMARC?
If you are a business sending any emails that include personal information (invoices, order confirmations, even account activation ones), or any emails with marketing purposes (commercial), you definitely need to implement one or more forms of email authentication to verify that an email is actually from you and your domain.
DMARC helps receiving servers determine how to evaluate messages that claim to be from your domain, and it is one of the most important steps you can take to improve your deliverability. Even if DMARC is not obligatory for sending with Mailjet, we recommend you set it up so you can avoid any spoofing alongside with the SPF and DKIM. Check the links to learn how to set up SPF and DKIM.
We know that this article is enough to understand how to set up DKIM, but you can always check the guide of our colleagues/partners from Google by clicking here. For any general questions about DMARC you can always contact our support.
Let’s wrap it up
With DMARC, an organization can block malware, phishing attacks, and improve its deliverability all at the same time. Once enabled, a DMARC record ensures that only authorized senders are able to use your domain to send messages. That means recipients can tell at a glance who the email really comes from, and they can be certain that it’s not coming from a spoofed domain.
DMARC will make sure that emails that use your domain but fail authentication won’t even appear in recipients’ inboxes. So no one will be able to collect money to go to the Amazon rainforest by using you brand.
Don’t wait! Set up your DMARC and be sure that no one is using your domain without you knowing.
For more useful tips don’t forget to follow us on Twitter and Facebook.
This is an updated version of the blog post “Some words about DMARC” published on the Mailjet blog on April 25, 2014.