How do I properly set up DMARC records and reporting for email authentication?
Michael Ko
Co-founder & CEO, Suped
Published 11 Jun 2025
Updated 17 Aug 2025
6 min read
Email authentication is crucial for ensuring your messages reach the inbox and protecting your domain from fraudulent use. Among the key protocols, Domain-based Message Authentication, Reporting, and Conformance (DMARC) stands out for its ability to guide recipient email servers on how to handle emails that fail authentication checks. Setting up DMARC correctly involves careful configuration and ongoing monitoring to maximize its benefits.
It builds upon existing authentication standards like Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM), providing a framework for policy enforcement and robust reporting. This guide will walk you through the essential steps to properly set up your DMARC records and understand the reporting mechanisms, helping you secure your email communications and improve deliverability.
DMARC allows domain owners to specify what actions recipient mail servers should take when an email claiming to be from their domain fails SPF or DKIM authentication, and to receive reports on these authentication failures. This helps prevent email spoofing, phishing, and other unauthorized uses of your domain. Before diving into DMARC, ensure your SPF and DKIM records are properly configured and aligned with your sending sources.
DMARC works by checking if the domain in the From: header (the one users see) aligns with the domains used in SPF and DKIM checks. If there's a mismatch, or if SPF/DKIM fail, DMARC applies a policy defined by the domain owner. This alignment check is critical for effective email authentication. You can read more about how DMARC works in detail.
Implementing DMARC provides several benefits, including enhanced security against spoofing and improved deliverability due to increased trust from recipient mail servers. It's an essential step towards robust email hygiene, especially with evolving sender requirements from major mailbox providers.
Preparing for DMARC implementation
Before you publish your DMARC record, it's essential to have a clear understanding of your email sending environment. Start by identifying all legitimate sources that send email on behalf of your domain. This includes your own mail servers, marketing platforms, transactional email services, and any third-party senders. Ensure SPF and DKIM are properly configured for all these sources, as DMARC relies on their authentication results.
It's also crucial to consider your subdomains. A DMARC record published at the root domain (`example.com`) generally applies to all subdomains unless a specific DMARC record is published for a subdomain (e.g., `_dmarc.sub.example.com`). This hierarchical nature allows for flexibility, letting you apply different policies to different parts of your email ecosystem.
Having robust SPF and DKIM in place before DMARC is vital. You can verify your existing authentication setup to ensure everything is working as expected. This preparatory phase helps minimize potential deliverability issues once DMARC policies are enforced.
Creating your DMARC record
A DMARC record is a TXT record added to your domain's DNS. It begins with `v=DMARC1` and includes various tags that define its behavior. The most critical tag is `p=` which specifies the policy for emails that fail DMARC authentication.
p=none: This monitoring-only policy means emails failing DMARC will still be delivered, but you'll receive reports. This is the safest starting point, allowing you to gather data without impacting legitimate email flow. Refer to simple DMARC examples for more.
p=quarantine: Emails failing DMARC are sent to the recipient's spam or junk folder. This is a progressive step after monitoring, once you're confident in your legitimate sending sources.
p=reject: Emails failing DMARC are not delivered at all. This is the strongest policy, offering maximum protection against spoofing, but should only be implemented after thorough testing with `p=none` and `p=quarantine`.
Other important tags include `rua=` (reporting URI for aggregate reports) and `ruf=` (reporting URI for forensic reports). Aggregate reports (RUA) provide daily XML summaries of DMARC authentication results. Forensic reports (RUF) offer more detailed, anonymized information about individual failed messages, which can be invaluable for troubleshooting.
This record instructs recipient servers to take no action on failed emails, but to send aggregate and forensic reports to the specified email addresses. The `fo=1` tag requests forensic reports for all failures, regardless of SPF or DKIM passing.
Once your DMARC record is published with `p=none`, the real work begins: monitoring the aggregate reports. These reports, typically sent daily to the email address specified in your `rua` tag, contain XML data that can be difficult to read manually. Many organizations opt for DMARC monitoring services (or vendors) that process these reports into human-readable dashboards, helping you identify legitimate email sources and potential threats.
Analyzing DMARC reports is crucial for understanding your email ecosystem. They show which legitimate senders are failing authentication or alignment, allowing you to fix issues before moving to stricter policies. Reports also reveal unauthorized senders attempting to spoof your domain, giving you insight into potential abuse.
Transitioning DMARC policies
After a period of monitoring with `p=none` and resolving any legitimate sending issues, you can gradually move to a more restrictive policy. This is often done by incrementally increasing the percentage of emails to which the policy applies using the `pct=` tag (e.g., `p=quarantine; pct=10`). For a detailed guide on this process, see Microsoft's DMARC configuration guidance.
Once you're confident that all legitimate emails are passing DMARC, you can transition to `p=quarantine` and eventually to `p=reject` to gain full protection. The DMARC.org site is a valuable resource for best practices.
Views from the trenches
Best practices
Always start with a 'p=none' DMARC policy to collect data without impacting email delivery.
Ensure your SPF and DKIM records are correctly configured and aligned for all legitimate sending sources.
Use the 'rua' tag to receive aggregate DMARC reports for continuous monitoring.
Analyze DMARC reports regularly to identify legitimate email flows and detect spoofing attempts.
Common pitfalls
Skipping the 'p=none' monitoring phase and immediately setting a strict DMARC policy, leading to legitimate emails being blocked.
Failing to include the 'rua' tag, resulting in no DMARC reports and inability to monitor performance.
Not having SPF and DKIM properly set up or aligned before implementing DMARC, causing false positives.
Ignoring DMARC reports or finding them too complex to analyze, missing critical insights into email authentication.
Expert tips
Consider using a DMARC monitoring service to simplify report analysis and gain actionable insights.
Pay close attention to DMARC alignment, as it's key to successful DMARC implementation.
If using subdomains, decide whether to apply the root domain policy or define specific policies for subdomains.
Be aware that new sender requirements from major mailbox providers often mandate DMARC reporting.
Marketer view
Marketer from Email Geeks says DMARC should be set at the root domain.
Dec 20, 2023 - Email Geeks
Marketer view
Marketer from Email Geeks says to also include an RUA tag for aggregate reports.
Dec 20, 2023 - Email Geeks
Final thoughts on DMARC setup
Properly setting up DMARC records and actively monitoring their reports is fundamental for modern email security and deliverability. It empowers you to protect your brand from impersonation and ensures your legitimate emails reach their intended recipients without being caught in spam filters or blocklists (or blacklists). By following a methodical approach—starting with monitoring and gradually enforcing stricter policies—you can build a resilient email sending infrastructure.
