How should I configure DMARC for multiple domains and when should I implement a reject policy?
Matthew Whittaker
Co-founder & CTO, Suped
Published 20 Jul 2025
Updated 19 Aug 2025
8 min read
Managing email security for a single domain can be complex, and it becomes even more intricate when you operate multiple domains. Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a crucial email authentication protocol that helps protect your brand from spoofing and phishing attacks by giving mailbox providers instructions on how to handle unauthenticated emails purporting to be from your domain. For organizations with several domains, configuring DMARC correctly across all of them is essential for maintaining strong email deliverability and security.
The ultimate goal for many is to implement a DMARC p=reject policy, which provides the highest level of protection by instructing receiving servers to reject all emails that fail DMARC authentication. However, jumping straight to a reject policy without proper planning can lead to legitimate emails being blocked. Understanding how to configure DMARC for all your domains, including subdomains and those that don't send email, and determining the right time to transition to a reject policy, is key to a successful deployment.
DMARC works on a per-domain basis, meaning each domain you use for sending email (or want to protect from spoofing) needs its own DMARC record. This also applies to subdomains. If you send email from marketing.yourdomain.com and support.yourdomain.com, each might need its own specific DMARC configuration, although a policy set at the organizational domain can apply to subdomains by default unless explicitly overridden. It's not about your Email Service Provider's (ESP) DMARC policy, but rather the policy you publish for your own domain that matters.
Before you even think about implementing a DMARC policy, you must ensure that Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) are correctly configured for all your legitimate email sending sources across all relevant domains. DMARC relies on these underlying authentication mechanisms to verify email authenticity. If SPF or DKIM fail, DMARC will too, and your emails could be rejected, quarantined, or even sent to the spam folder, depending on your policy. This is especially critical when using multiple email senders or ESPs for the same domain, as each sender needs to be properly authorized.
A common configuration for DMARC involves adding a DNS TXT record to your domain. This record contains various tags, including the policy tag (p=) and reporting addresses (rua=/ruf=). These reports are vital for understanding your email ecosystem and identifying any unauthorized senders or misconfigurations. You'll need to create a DMARC record for each domain you wish to protect.
The recommended approach to DMARC implementation, especially for multiple domains, is a gradual rollout. This typically involves starting with a p=none policy, then moving to p=quarantine, and finally to p=reject. This phased approach, often recommended by industry leaders, allows you to monitor your email streams without disrupting legitimate mail flow. Microsoft, for example, recommends a gradual DMARC approach for their Microsoft 365 domains.
The p=none policy allows you to monitor DMARC reports without affecting email delivery. This is your discovery phase, where you identify all legitimate sending sources and ensure their SPF and DKIM configurations are correct. Moving to p=quarantine instructs receivers to place unauthenticated emails into the recipient's spam or junk folder, which serves as a testing ground before full rejection. You can find more information on when to use each DMARC policy.
Monitoring DMARC aggregate reports (rua) is critical throughout this process. These reports provide insights into who is sending email on behalf of your domain, including legitimate sources and potential unauthorized senders. Analyzing these reports helps you ensure all your legitimate email traffic is properly authenticated before moving to a stricter policy. This is vital for understanding and troubleshooting your DMARC reports.
Before reject
Monitoring phase: DMARC policy set to p=none, allowing you to collect aggregate reports without affecting deliverability.
Identify all senders: Discover all legitimate sources sending email on behalf of your domains and ensure their proper SPF and DKIM setup.
Address misconfigurations: Fix any authentication failures observed in your DMARC reports for legitimate traffic.
After reject
Enforcement phase: DMARC policy set to p=reject, instructing receivers to block unauthorized emails.
Continuous monitoring: Even at reject, keep an eye on DMARC reports for new sending sources or configuration issues.
Enhanced brand protection: Significantly reduces email spoofing and enhances trust in your brand's communications.
When to implement a reject policy
Implementing a p=reject policy should be the final step in your DMARC journey, not the first. You should only consider moving to p=reject when you have near-zero legitimate email traffic failing DMARC authentication. This means you've identified and properly configured all your sending sources, including any third-party providers like marketing platforms or transactional email services. A premature move to p=reject could cause legitimate emails to be blocked, leading to significant deliverability issues and lost communications.
The duration of monitoring at p=none and p=quarantine before transitioning to p=reject depends on the complexity of your email infrastructure and how diligently you're addressing authentication failures. Some organizations might take a few months, while others with more complex setups might need six months or even a year. The key is to achieve a consistent period (e.g., a month or two) where you see no significant legitimate mail failures in your DMARC reports. This systematic approach helps you to safely implement a DMARC p=reject policy.
A DMARC reject policy significantly reduces the risk of your domain being used for email spoofing, phishing, and other unauthorized activities. It directly instructs receiving mail servers (like Google and Yahoo) to outright reject emails that fail DMARC checks. This bolsters your brand's reputation and trust, making it harder for attackers to impersonate your organization. Keep in mind that DMARC primarily protects against direct domain spoofing, which means the visible 'From' address is your domain. While it helps mitigate some phishing attempts, it's more focused on brand protection than all forms of phishing.
Before implementing a reject policy, it's also important to understand the best practices for DMARC implementation, including organizational and subdomain policies and reporting. Always remember that even after achieving p=reject, continuous monitoring of your DMARC reports is essential to catch any new legitimate sending sources or changes in your email infrastructure.
Managing subdomains and non-sending domains
For organizations with numerous domains, managing DMARC can seem daunting. Each organizational domain should have its own DMARC record. For subdomains, DMARC offers the sp (subdomain policy) tag. If the parent domain's DMARC policy is set to p=reject, this policy typically applies to all subdomains unless a specific DMARC record is published for that subdomain. This simplifies management for subdomains that don't send email or for those that should inherit the primary domain's robust policy.
Consider domains that do not send email at all. For these domains, it is a best practice to publish a DMARC record with a p=reject policy right away. Since no legitimate email should originate from these domains, a reject policy ensures that any email claiming to be from them is blocked, effectively preventing spam and spoofing from non-existent domains. Remember that best practices for DMARC setup highlight the importance of careful consideration for all domains.
Conclusion
While achieving a DMARC p=reject policy across all your active domains is the gold standard for email security, it's a journey that requires patience, diligent monitoring, and careful configuration. Each domain and subdomain must be assessed individually, ensuring all legitimate email streams are properly authenticated with SPF and DKIM. Only then can you confidently transition through the none and quarantine phases to full enforcement. This meticulous approach ensures maximum protection against spoofing and phishing without disrupting your legitimate email communications.
The benefits of a fully implemented DMARC p=reject policy are substantial, offering robust brand protection and improved trust in your email sends. Remember to leverage DMARC reports for continuous insights and adjust your configurations as your email ecosystem evolves. This ongoing vigilance is what truly secures your domains against email abuse.
Views from the trenches
Best practices
Start with DMARC p=none for all domains and subdomains to gather data without impacting deliverability.
Ensure all legitimate email senders are properly authenticated with both SPF and DKIM for each domain.
Monitor DMARC aggregate reports daily to identify all sending sources and authentication failures.
Gradually transition policies: p=none to p=quarantine, then p=quarantine to p=reject, after thorough monitoring.
Implement p=reject immediately for domains that should never send email to prevent potential abuse.
Common pitfalls
Moving to p=reject too quickly without fully understanding your email ecosystem can cause legitimate emails to be blocked.
Failing to configure SPF and DKIM correctly for all third-party senders, leading to DMARC failures.
Not monitoring DMARC reports regularly, missing critical authentication issues.
Assuming DMARC prevents all forms of phishing; it primarily protects against direct domain spoofing.
Ignoring subdomains, as they can inherit the organizational domain's policy unless specifically configured.
Expert tips
Actively track the rate of legitimate authentication failures; when it's near zero, you're ready to advance your policy.
Consider a monthly review period where no serious issues arise before moving from quarantine to reject.
If your mail system is complex or has a long history, plan for a longer DMARC rollout period, possibly six months or more.
Using DMARC reporting services simplifies the process of interpreting authentication failure feedback and identifying mail streams.
BIMI often requires a p=quarantine or p=reject policy for your organizational domain.
Expert view
Expert from Email Geeks says DMARC's primary focus is the domain in the From: field, so each mail stream using a different domain should be treated separately.
2020-02-05 - Email Geeks
Expert view
Expert from Email Geeks says an ESP's DMARC policy is not relevant when you are sending with your domain in the From: field; only your published DMARC policy for your domain applies.
