DMARC records are TXT records in a domain's DNS that help protect email senders and recipients from spam, phishing, and email spoofing.
A DMARC record allows a sender to indicate that their emails are protected by SPF and/or DKIM, and tells a receiving mail system what to do if neither of those authentication methods passes:
- Nothing
- Quarantine the message
- Reject it.
Below are 5 examples of DMARC records, with an explanation of what each configuration means. At the end of the article, I also provide a quick guide on how to create and install a DMARC record yourself.
DMARC Record Example 1: For Monitoring Only
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;
- v=DMARC1: This indicates the version of DMARC used. This part is mandatory and specifies that this is a DMARC record.
- p=none: The policy applied to email that fails the DMARC check. In this case, “none” means the domain is not enforcing DMARC but monitoring it. So, failing emails will not be treated differently from passing emails.
- rua=mailto:dmarc-reports@example.com: This specifies the email address where aggregate reports of DMARC failures should be sent. These reports provide insights into emails that are failing DMARC checks.
Example 2: For Quarantine
v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-reports@example.com;
- p=quarantine: Emails that fail DMARC checks will be moved to the spam folder or otherwise quarantined.
- pct=50: This indicates that the policy should be applied to only 50% of the emails that fail the DMARC check. This allows for a phased approach to enforcement, where only a small percentage of messages are initially quarantined to test it’s working properly, without erroneously quarantining large numbers of emails that are in fact legitimate.
Example 3: For Full Rejection
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensics@example.com;
- p=reject: This policy tells receiving mail servers to reject emails that fail the DMARC checks, preventing them from being delivered at all.
- ruf=mailto:dmarc-forensics@example.com: This specifies an email address to send forensic reports to. Forensic reports provide more detailed information about individual failings, which can be useful for troubleshooting.
Example 4: With Forensic Options
v=DMARC1; p=quarantine; fo=1; rua=mailto:aggregate@example.com; ruf=mailto:forensic@example.com;
- fo=1: The fo tag specifies the conditions under which forensic reports are generated. The value 1 means that a report should be sent if either SPF or DKIM fails to authenticate. This is a useful setting for getting detailed reports on messages that fail one of the checks but might still pass overall DMARC (since DMARC requires only one of SPF or DKIM to pass, provided alignment is correct).
Example 5: With Subdomain Policy
v=DMARC1; p=quarantine; sp=reject; rua=mailto:dmarc-reports@example.com;
- sp=reject: This specifies the policy for subdomains. In this case, while the primary domain's policy is to quarantine failing emails, emails from any subdomain that fail DMARC checks will be rejected.
Example 6: With Reporting Interval
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ri=3600;
- ri=3600: This sets the reporting interval for aggregate reports in seconds. In this case, the domain owner wants to receive reports every hour. This can be useful for domains under attack or for those troubleshooting delivery issues.
Example 7: With DKIM Alignment Mode
v=DMARC1; p=reject; adkim=r; rua=mailto:aggregate@example.com;
- adkim=r: The adkim tag specifies the alignment mode for DKIM, where r stands for relaxed. In relaxed mode, the domain found in the DKIM signature can be a subdomain of the domain found in the “From” header of the email. This allows, for example, emails signed by sub.example.com to align with emails from example.com. The relaxed mode is more forgiving and is useful when you have legitimate email sending services operating from subdomains.
Example 8: With SPF Alignment Mode
v=DMARC1; p=reject; aspf=s; rua=mailto:aggregate@example.com;
- aspf=s: The aspf tag specifies the alignment mode for SPF, where s stands for strict. In strict mode, the domain found in the Return-Path header (which specifies where bounced emails should be processed) must exactly match the domain found in the “From” header of the email. This means that emails sent from sub.example.com would not align with example.com under strict alignment, potentially leading to DMARC failures if other conditions are not met. Strict alignment is more secure but can be less forgiving for legitimate email configurations involving subdomains.
How to install a DMARC record
1. Assess Your Email Sending Sources
Identify all the services and servers that send email on behalf of your domain. This includes your own mail servers, third-party email service providers, and any other systems that send emails, like marketing tools or customer support platforms.
2. Ensure SPF and DKIM are Set Up
Before setting up DMARC, make sure that you have SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) records in place for your domain. These are prerequisites for DMARC to function correctly.
- SPF helps to verify that emails sent from your domain are coming from allowed servers.
- DKIM provides a way to validate that the content of the emails has not been tampered with.
3. Create Your DMARC Record
A DMARC record is a TXT record that needs to be published in your DNS. The basic format of a DMARC record starts with v=DMARC1; p=, followed by your policy.
Here’s a simple example: v=DMARC1; p=none; rua=mailto:your_email@example.com;.
- Choose a policy:
- none: Monitor mode, no action taken on failed messages.
- quarantine: Treat failed messages with suspicion and potentially place them in the spam/junk folder.
- reject: Block delivery of failed messages.
- Decide on reporting preferences, like aggregate reports (rua) and forensic reports (ruf).
4. Publish the DMARC Record in Your DNS
- Access your domain’s DNS management interface. This is usually provided by your domain registrar (e.g., GoDaddy, Namecheap) or your hosting provider.
- Navigate to the section where you can add a new TXT record.
- The Host field should be set to _dmarc. This is where you specify that this TXT record is a DMARC record.
- In the Value field, paste your DMARC policy that you've created.
- Save your changes.
5. Verify Your DMARC Record
After publishing, it’s important to verify that the DMARC record is correctly set up. You can use online tools like DMARC Analyzer, MXToolbox, or Google Admin Toolbox to check your DMARC record.
6. Monitor and Adjust Your DMARC Policy
- Initially set your policy to p=none to monitor how your emails are being handled without affecting delivery. This allows you to identify legitimate email sources that might not be aligned with SPF and DKIM settings.
- Gradually move to a stricter policy (quarantine then reject) as you gain confidence in your email sending practices and ensure that legitimate emails are properly authenticated.
- Regularly review the reports sent to the email addresses specified in rua and ruf to adjust your email sending practices and DMARC policy as needed.
Creating and implementing a DMARC record is a critical step in protecting your domain against email fraud, phishing, and spoofing. By carefully monitoring the reports and adjusting your policies and email authentication practices, you can significantly improve your email security.
I hope the 8 DMARC record examples above give you a clear idea of how to configure your TXT records, and the guide shows you how you can easily install your own DMARC record in your DNS.
If you have any questions or doubts about the process, let me know in the comments.
For further reading on the subject of email authentication, check out our DMARC vs DKIM vs SPF article for the differences between the protocols, our tips on how to check authentication is working and our general email authentication guide.
The author
Learn more about us
Our Methodology
This article has been written and researched following our EmailTooltester methodology.
Our Methodology
