Domain-based Message Authentication, Reporting & Conformance, or DMARC, is a protocol that uses Sender Policy Framework, (SPF) and DomainKeys identified mail (DKIM) to determine the authenticity of an email message.
DMARC makes it easier for Internet Service Providers (ISPs) to prevent malicious email practices, such as domain spoofing in order to phish for recipients’ personal information.
Essentially, it allows email senders to specify how to handle emails that were not authenticated using SPF or DKIM. Senders can opt to send those emails to the junk folder or have them blocked them all together. By doing so, ISPs can better identify spammers and prevent malicious email from invading consumer inboxes while minimizing false positives and providing better authentication reporting for greater transparency in the marketplace.
Your DMARC record is published alongside your DNS records and includes including:
- SPF
- A-record
- CNAME
- (DKIM)
It is important to note that not all receiving servers will perform a DMARC check before accepting a message, but all the major ISPs do and implementation is growing.
What are the benefits of DMARC?
There are a few key reasons that you would want to implement DMARC:
- Reputation
Publishing a DMARC record protects your brand by preventing unauthenticated parties from sending mail from your domain. In some cases, simply publishing a DMARC record can result in a positive reputation bump.
- Visibility
DMARC reports increase visibility into your email program by letting you know who is sending email from your domain.
- Security
DMARC helps the email community establish a consistent policy for dealing with messages that fail to authenticate. This helps the email ecosystem as a whole become more secure and more trustworthy.
What does a DMARC record look like?
You can see what a DMARC record looks like by typing < dig txt _dmarc.sendgrid.net > in your terminal. You can also go to https://dmarcian.com/dmarc-inspector/ to view the DMARC record for any domain if they have 1 published.
Here is an example of DMARC record–this is SendGrid’s DMARC record:
v=DMARC1;p=none;rua=mailto:[email protected];ruf=mailto:[email protected];rf=afrf;pct=100
Let’s break it down
“v=DMARC1”
Version – This 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.
“p=none”
Policy – The policy you select in your DMARC record will tell the participating recipient email server what to do with mail that doesn’t pass SPF and DKIM, but claims to be from your domain. In this case, the policy is set to “none.” There are 3 types of policies you can set:
- p=none – Tell the receiver to perform no actions against unqualified mail, but still send email reports to the mailto: in the DMARC record for any infractions.
- p=quarantine – Tell the receiver to quarantine unqualified mail, which generally means “send this directly to the spam folder.”
- p=reject – Tell the receiver to completely deny any unqualified mail for the domain. With this enabled, only mail that is verified as 100% being signed by your domain will even have a chance at the inbox. Any mail that does not pass is blackholed— not bounced—so there’s no way to catch false positives.
“rua=mailto:[email protected]“
This part tells the receiving server where to send aggregate reports of DMARC failures. Aggregate reports are sent daily to the administrator of the domain that the DMARC record belongs to. They include high-level information about DMARC failures but do not provide granular detail about each incident. This can be any email address you choose.
“ruf=mailto:[email protected]”
This part tells the receiving server where to send forensic reports of DMARC failures. These forensic reports are sent in real-time to the administrator of the domain that the DMARC record belongs to and contain details about each individual failure. This email address must be from the domain that the DMARC record is published for.
“rf=afrf”
Reporting format. This part tells the receiving server what kind of reporting the policyholder wants. In this case rf=afrf means aggregate failure reporting format.
“pct=100”
Percent – This part tells the receiving server how much of their mail should be subjected to the DMARC policy’s specifications. You can choose any number from 1-100. In this case, if the p= was set to reject, 100% of the mail that fails DMARC would be rejected.
There are a number of other mechanisms that can be included in a DMARC record. A few notable ones include:
“sp=” This part would tell the receiving server whether or not to apply the DMARC policy to sub domains.
“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.
“ri=” This sets the interval for how often you want to receive aggregate reports about DMARC failures.
How do I implement DMARC with Twilio SendGrid?
Before you go through the work of implementing DMARC, note that it isn’t for everyone. If you own a small domain, you’re probably ok without it. However, it’s a smart move if you have ever had problems with phishing in the past or have a financially oriented business that processes sensitive information.
Another thing to keep in mind is that the DMARC aggregate and forensic reports are designed to be machine-readable. It can be difficult for humans to make sense of them so you will also need to use a DMARC report monitoring service to collect the reports and access the information. Return Path’s Brand Monitor and Agari are both good options.
Once you’ve decided the implement and have selected the right services, the process to get DMARC set up involves 5 phases:
1. Deploy DKIM & SPF by whitelabeling your Sendgrid IP
Complete the whitelabel process for your account. This ensures that emails sent through your Twilio SendGrid account will be properly signed using DKIM and SPF for your unique domain.
If you’re not sure how to complete this first step, visit our documentation here for help.
2. Verify proper DKIM and SPF signing for your whitelabel domain
Send yourself some test emails to help confirm that everything is working correctly. You’re looking to verify that the DKIM and SPF signatures in your email headers align with the domain you’ve used to whitelabel your SendGrid account. As long as both are passing, you’re in business!
3. Publish a DMARC record with your DNS registrar and then monitor the results
Within your DNS registrar, you need to create a TXT resource record that receivers can use to determine your DMARC preferences. This is done within the DNS registrar of the domain host, which is likely the same place you created the DNS records for the whitelabel. This record is made at the root level for the domain—not the subdomain.
A simple DMARC record might look like this:
“v=DMARC1; p=quarantine; pct=100;rua=mailto:[email protected]”
“v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected]”*
- v=DMARC1;
It is set to use DMARC version 1, there are no other versions at present. So always set 1. - p=quarantine;*
This policy tells the receiver to QUARANTINE unqualified mail, which generally means “send this directly to the spam folder.” - pct=100;
This instructs the receiver to assess 100% of messages claiming to be from the domain, this can be any number between 1 and 100. - rua=mailto:[email protected]
This tells the recipients to send aggregate reports to [email protected]. Set this to an email address you control that is closely monitored.
*This example uses the p=quarantine policy, but we recommend always starting out using the p=none policy at first.
4. Analyze the feedback you receive and adjust your mail streams as needed
If unqualified email is sent to, and received by, recipients participating in DMARC, the recipient will generate reports for these messages and send them back to the mailto: address specified in your DMARC record.
In these reports, you’ll have information to help you evaluate exactly what services might be sending mail on behalf of your domain.
Here is a sample report with only 1 record, showing the results for 2 pieces of mail. (Please note that the listed SPF and DKIM auth_results are raw results, regardless of the s= alignment. The filename is formatted as: filename = receiver “!” policy-domain “!” begin-timestamp “!” end-timestamp “.” extension (Example: receiver.org!sender.com!1335571200!1335657599.zip))
<report_metadata>
<org_name>receiver.com
<extra_contact_info>http://receiver.com/dmarc/support
<report_id>9391651994964116463
<date_range>
1335571200
1335657599
<policy_published> sender.com
r
r
none
none
100
<source_ip>72.150.241.94
2 <policy_evaluated> none
fail
pass
<header_from>sender.com
<auth_results>
sender.com
fail
<human_result>
sender.net
pass
<human_result>
sender.com
pass
*Note: Aggregate reports are sent as a .zip attachment, so be sure the address you’re defining can accept attachments in this file type.
5. Escalate your DMARC policy tags as you learn
Now that you’ve tested and tweaked your mail streams to determine exactly who is sending email for your domain, it’s time to turn it up a notch.
Up until now, you should have only been using the p=none policy to get reports of any errant behavior, and you should have a good idea of where email is coming from. The next step is to adjust the policy on your DMARC record to start controlling how receivers handle mail claiming to be from your domain. Remember:
- p=none – You get reports of infractions, but recipients take no action as far as processing the messages themselves.
- p=quarantine – Unqualified mail goes directly to spam, but can be recovered. This is useful when you’re fairly certain you know all the locations where mail is coming from, but want to ‘softfail’ any messages that are unqualified until you’re 100% sure.
- p=reject – Use this when you’re absolutely sure you know every server and service that is sending email for your domain, and that signing is in place for each of these services and you want anything with the audacity to claim otherwise completely denied. Unqualified mail is completely deleted by the recipient mail server, never to be seen again.
Why DMARC is so important
DMARC is an important evolution of email authentication. This is just another great example of email senders and ISPs working together to protect the email channel. To learn more about DMARC, visit the organization’s website at www.dmarc.org. To learn more about authentication, read this blog post.