What are the best practices for DMARC setup, including organizational and subdomain policies and reporting?
Michael Ko
Co-founder & CEO, Suped
Published 24 May 2025
Updated 19 Aug 2025
8 min read
DMARC, or Domain-based Message Authentication, Reporting, and Conformance, is an essential email authentication protocol. It builds upon Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) to provide a robust defense against email spoofing, phishing, and other forms of unauthorized email use. For any organization, implementing DMARC is critical for protecting brand reputation and ensuring legitimate emails reach their intended recipients.
While the concept is straightforward, setting up DMARC correctly can be complex, especially when considering policies for organizational domains, their subdomains, and the critical role of reporting. A misconfigured DMARC record can lead to legitimate emails being quarantined or rejected, impacting communication and business operations. This is why a systematic approach, guided by best practices, is crucial.
My goal is to walk you through the best practices for DMARC setup, covering everything from initial policy choices to managing subdomain policies and leveraging reporting data for continuous improvement. By following these guidelines, you can establish a strong and effective email authentication posture.
The foundation of any DMARC implementation lies in its policy. DMARC policies are defined using the p tag within your DMARC record, specifying how email receivers should handle messages that fail DMARC authentication checks. The three primary policies are p=none, p=quarantine, and p=reject. It is widely recommended to adopt a phased approach, starting with a lenient policy and gradually escalating to stronger enforcement.
Before you even set up DMARC, ensure that your Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) records are fully configured and properly aligned for all legitimate sending sources. DMARC relies on these underlying authentication mechanisms. Without them, DMARC will not function effectively, and legitimate emails may fail authentication. You can read more about best practices for setting up SPF, DKIM, and DMARC in our other guides.
Always begin your DMARC journey with p=none. This policy instructs receiving mail servers to take no action on emails that fail DMARC authentication, but it still generates DMARC reports. These reports are invaluable for understanding your email ecosystem, identifying all legitimate sending services, and discovering any unauthorized senders spoofing your domain. Monitoring these reports is a crucial step before moving to more restrictive policies.
The phased DMARC approach
Implementing DMARC is a journey, not a one-time setup. Start with p=none, carefully analyze reports, fix any authentication issues, and then gradually escalate to p=quarantine, and finally to p=reject. This phased deployment minimizes the risk of legitimate emails being blocked and ensures a smooth transition to full DMARC enforcement.
Organizational and subdomain policies
By default, a DMARC policy set for an organizational domain (e.g., example.com) will automatically apply to all its subdomains (e.g., mail.example.com or marketing.example.com). This default inheritance simplifies DMARC management for domains with many subdomains, as a single record can cover a broad spectrum of email traffic. However, it also means that if your organizational domain's DMARC record is not adequately configured, it could leave your subdomains vulnerable.
For situations where you need to apply a different DMARC policy to subdomains than to the organizational domain, you can use the sp (subdomain policy) tag in your main DMARC record. For instance, you might set your organizational domain to p=reject but use sp=none for subdomains while you gather more data or have third-party senders using specific subdomains. This granular control is vital for complex email environments. You can learn more about DMARC policies for organizational domains and subdomains.
It is a best practice to protect all your subdomains, even those that you don't actively use for sending email. Cybercriminals often target unused or neglected subdomains for spoofing attacks, as they may lack proper authentication. Implementing a DMARC record with a policy of p=reject (or sp=reject) for all subdomains, where appropriate, significantly reduces your attack surface. You can define a wildcard DMARC record to cover all present and future subdomains automatically, simplifying management.
Example DMARC record for organizational domain with subdomain policyDNS
If no specific DMARC record is published for a subdomain, it inherits the policy set for its organizational (parent) domain. This simplifies setup but requires the parent domain's policy to be robust.
Simplicity: One record covers many subdomains.
Risk: A weak parent policy means subdomains are also weak.
Explicit subdomain policy (sp tag)
The sp tag allows you to specify a different DMARC policy for all subdomains. This is useful for granular control and phased rollouts.
Flexibility: Different policies for main domain and subdomains.
Control: Ideal for managing third-party senders or legacy systems on subdomains.
DMARC reporting and monitoring
DMARC reports are the eyes and ears of your email security. They provide invaluable data on who is sending email on behalf of your domain, whether those emails are passing or failing SPF and DKIM, and what action (if any) receiving mail servers are taking based on your DMARC policy. There are two types of reports: aggregate reports (rua) and forensic reports (ruf). Aggregate reports are XML files that offer a high-level overview of email traffic, while forensic reports (often redacted for privacy) provide more detail on individual failures. You can learn how to set up DMARC reports here.
The consistent analysis of these reports is critical. They enable you to identify legitimate email streams that might be failing authentication and need adjustments to their SPF or DKIM records. They also expose unauthorized sources attempting to spoof your domain, allowing you to take action against malicious activity. Without actively monitoring and understanding these reports, you are essentially flying blind, risking deliverability issues and undetected impersonation. For example, Microsoft Defender uses DMARC to validate incoming mail.
While aggregate reports provide immense value, their raw XML format can be challenging to interpret. This is where DMARC reporting tools become essential. They parse the raw data, present it in an easily understandable format, and often provide actionable insights. These tools help you visualize trends, pinpoint authentication failures, and quickly identify problematic sending sources, streamlining the process of reaching a p=reject policy. You can also refer to the DMARC.org overview for more technical details.
Setting up your DMARC reporting addresses
When setting up your DMARC record, clearly define the email addresses for receiving aggregate (rua) and forensic (ruf) reports. It is best to use dedicated mailboxes or alias addresses for these, as the volume of reports can be high. Ensure these addresses are monitored and the reports are regularly processed to glean actionable insights and identify potential issues like a domain blacklist entry.
DMARC tag
Description
Example
rua
Email address for aggregate reports. Provides summary data on email authentication results.
rua=mailto:reports@example.com
ruf
Email address for forensic reports. Provides detailed information on individual authentication failures.
ruf=mailto:forensics@example.com
fo
Failure reporting options. Specifies when forensic reports should be generated.
fo=1 (report all failures)
Advanced considerations and ongoing maintenance
Beyond the basic setup, several advanced considerations can further strengthen your DMARC implementation. Understanding DMARC alignment, for instance, is crucial. Alignment refers to the matching of the From header domain with the domain used for SPF (Return-Path) and DKIM (d= tag). DMARC can be configured for strict or relaxed alignment, with strict alignment requiring an exact match and relaxed allowing subdomain matches. Most organizations start with relaxed and then move to strict alignment after all legitimate sending sources are properly configured.
DMARC is not a set it and forget it solution. Your email sending infrastructure changes over time, with new marketing platforms, transactional email services, or even legacy systems being introduced or decommissioned. Each change can impact your DMARC compliance. Therefore, continuous monitoring of DMARC reports and periodic reviews of your SPF and DKIM records are essential to maintain an effective DMARC policy. This includes regular blocklist monitoring to ensure your sending IPs and domains remain healthy.
A robust DMARC implementation not only protects your domain from abuse but also significantly contributes to your overall email deliverability. Mailbox providers increasingly rely on DMARC to filter out malicious emails. By having a strong DMARC policy, especially p=reject, you signal to receiving servers that you are a legitimate sender, which can lead to better inbox placement and improved email reputation. This proactive stance is vital for maintaining trust with your recipients and protecting your brand's integrity.
Views from the trenches
Best practices
Always start with p=none and monitor reports before enforcing stronger policies.
Ensure SPF and DKIM are fully configured and aligned before implementing DMARC.
Set up DMARC reporting (rua) for both organizational and subdomain policies.
Regularly analyze DMARC reports to identify legitimate senders and unauthorized activity.
Protect all subdomains, even inactive ones, to prevent email spoofing.
Common pitfalls
Skipping the p=none monitoring phase and immediately enforcing p=reject.
Not configuring rua for aggregate reports, leading to lack of visibility.
Neglecting subdomain policies, leaving them vulnerable to spoofing.
Assuming DMARC fixes all email deliverability issues without proper SPF/DKIM.
Failing to continuously monitor DMARC reports and adjust policies as needed.
Expert tips
Prioritize establishing reporting at the organizational level to gain complete visibility.
Consider using the sp tag if specific subdomains require different policies.
Regularly review your DMARC records to ensure they accurately reflect your sending infrastructure.
Be aware of the impact of third-party senders on your DMARC compliance.
Collaborate with internal teams to ensure all email sending sources are accounted for.
Expert view
Expert from Email Geeks says: The organizational domain should have reporting enabled, and the subdomain policy does not necessarily require an explicit sp= tag if it inherits the main policy.
September 12, 2019 - Email Geeks
Marketer view
Marketer from Email Geeks says: Having a clean and orderly DMARC setup, with records consolidated at the organizational domain where appropriate, seems like a best practice.
September 12, 2019 - Email Geeks
Ensuring secure email delivery
Setting up DMARC effectively is a cornerstone of modern email security and deliverability. It requires a strategic approach, starting with a monitoring policy, meticulously configuring SPF and DKIM, and then gradually moving towards stronger enforcement policies like quarantine and reject.
Crucially, DMARC's power lies in its reporting capabilities, which provide the intelligence needed to refine your email authentication setup and protect your brand from imposters. By following these best practices for organizational and subdomain policies, and diligently analyzing your DMARC reports, you can achieve a robust email security posture and ensure your emails consistently reach the inbox.
