Learn how to create a DMARC policy for your domain and resolve DMARC-related risks in the UpGuard platform.
What is Domain-based Message Authentication, Reporting and Conformance (DMARC)?
DMARC is an email authentication protocol designed to give email domain owners the ability to protect their domain from unauthorized use, e.g. email spoofing.
The purpose and primary outcome of implementing DMARC is to protect a domain from being used in business email compromise (BEC) attacks, phishing emails, email scams and other email threats.
DMARC provides a mechanism to:
Authenticate the domain in the From header of an email, based on the results of SPF and DKIM
Allow domain owners to set a policy for handling email based on the result of that authentication
Allow domain owners to get feedback reports from mail receivers on the results of DMARC checks
How DMARC works
Before we dive into how to create a DMARC policy, it's important to understand how DMARC works as your implementation of DMARC will change depending on your desired configuration.
Like SPF and DKIM, implementing DMARC requires you to add a DNS TXT record. Once the DMARC DNS entry is published, any receiving email server will authenticate the incoming email based on the instructions published in the domain's DNS. If the email passes the authentication, it is delivered and can be trusted.
If the email check fails, the receiving email server will check the p element of the DMARC record and then follow its instructions:
None: The domain owner requests no specific action be taken regarding delivery of the messages. This is effectively the same as having no DMARC record at all. Any existing mail filtering policies should not be impacted, e.g. SPF. This is generally used by domain owners who want to start collecting feedback reports to determine what impact DMARC will have once a stricter policy is enforced.
Quarantine: The domain owner wishes for email receivers to have emails that fail the DMARC check to be treated as suspicious. This typically means the email will end up in spam.
Reject: The domain owner wishes for email receivers that fail the DMARC check to reject the email.
We recommend starting with p=none to monitor for any issues before moving to p=quartantine and then p=reject over time.
Example DMARC policy
To get a better understanding of DMARC, it's helpful to walk through an example. Let's use UpGuard's:
v=DMARC1;p=none;fo=1:d:s;rua=mailto:[email protected];ruf=mailto:[email protected];adkim=s;aspf=r
The first part v=DMARC1 is the identifier the receiving email server looks for when scanning the DNS record for the domain name it received the email from. If the domain does not have a txt record that begins with V=DMARC1, it will not run a DMARC check.
p=none tells the receiving server what to do with messages that fail DMARC. In UpGuard's case, the policy is set to none. This tells the receiving server to take no action if a message fails DMARC but it can still be valuable for the sender because DMARC sends reports to alter the domain owner of any DMARC failures.
It is generally recommended to deploy DMARC in "monitor mode" to collect data from participating receivers. Once the data shows legitimate emails are passing authentication checks, you can change the DMARC policy to request that failing messages are quarantined (p=quarantine) or even rejected (p=reject).
The next part fo is forensic reporting options. "1" generates a report if any mechanism fails, "d" generates a report if DKIM signature fails to verify and "s" generates reports if SPF fails. The other option is "0" which only generates reports if all underlying authentication fails.
rua=mailto:[email protected] tells the receiving server where to send aggregate reports of DMARC failures. These reports are sent on a daily basis and include high level information about DMARC failures rather than specific details about each incident. This can be any email address you choose.
ruf=mailto:[email protected] tells the receiving server where to send forensic reports of DMARC failures. Forensic reports are sent in real-time and contain details about each individual failure. Unlike rua, ruf relies on the email address provided being the part of the same domain as the DMARC record is published for.
adkim=s sets strict DKIM alignment meaning that the DKIM portion of DMARC authentication only passes if the d= field in the DKIM-Signature exactly matches the from domain. It can also be set to relaxed "r" that passes the DKIM authentication portion of DMARC authentication if the DKIM d= field matches the root domain of the from address.
aspf=r sets relaxed SPF alignment meaning the SPF portion of DMARC will pass if the from header shares a common organizational domain. It can also be set to strict "s" which requires exact matching between the SPF record domain and an email's from header.
Other mechanisms can be included in the DMARC record including:
rf: tells the receiving server what kind of reporting the policyholder wants
pct: tells the receiving server how much of their mail should be subjected to DMARC policy's specifications
sp: Tells the receiving server whether or not to apply the DMARC policy to subdomains.
How to implement a DMARC policy
Now that we've walked through our DMARC policy, it's time to implement your own:
Log in to your domain registrar and select the option to manage or configure your DNS settings.
Add a new TXT DNS record and copy across the content generated in step 1
Store the new TXT record under the _dmarc subdomain of the From domain; e.g. _dmarc.upguard.com
Publish the record
☝️ In the example above, the policy would be applied any time an email is received with upguard.com as the From domain. The policy will also apply to email received from a subdomain of upguard.com, unless the subdomain defines its own DMARC policy.
Please note that a DMARC policy alone is not enough to ensure adequate email security as it depends on the use of both SPF and DKIM results. If you would like to learn about how to create robust SPF and DKIM records, please see our email security guide.
In the guide, you'll learn about our SPF, DKIM, and DMARC recommendations.