Summary
Experts, marketers, and official documentation sources agree that setting DMARC to 'reject' on a domain that does not send email is a valid and recommended practice to enhance security and prevent domain spoofing, phishing attacks, and unauthorized use of the domain. The crucial prerequisite is verifying that absolutely no legitimate email originates from the domain, its subdomains, or superdomains. This includes checking for emails from contact forms, CRM integrations, system administration alerts, and other potential sources. For internal systems, it's wise to consult with sysadmins or the hosting company. Setting up reporting is also recommended to monitor for any unintended consequences after implementing the 'reject' policy. In some cases, especially where a full DMARC deployment is not cost-effective, obtaining written agreement from management regarding the deliberate blocking of mail is advised.
Key findings
- Improved Security: Implementing DMARC 'reject' on non-sending domains provides a significant boost to security by preventing spoofing, phishing, and unauthorized email use.
- Recommended Practice: Utilizing a 'reject' policy for domains not sending email is considered a standard and recommended security practice across the industry.
Key considerations
- Thorough Verification: It is crucial to rigorously verify that no legitimate email originates from the domain, its subdomains, or superdomains before implementing the 'reject' policy. Check all possible sources, including forms, CRM, and system alerts.
- Internal System Impact: For internal systems, consulting with sysadmins or the hosting company is advisable to ensure no critical email functionality is unintentionally disrupted.
- Management Approval: In situations where full DMARC deployment isn't feasible, obtaining written agreement from management acknowledging the intentional blocking of mail is recommended.
- Reporting Implementation: Implement DMARC reporting to monitor for any unforeseen issues that might arise after the 'reject' policy goes into effect.
What email marketers say
7 marketer opinions
The consensus is that setting DMARC to 'reject' on a domain that doesn't send email is a valid and recommended security practice to prevent domain spoofing and phishing attacks. However, a critical prerequisite is to thoroughly verify that absolutely no legitimate email originates from the domain, including emails from contact forms, CRM integrations, or server-generated reports. Setting up reporting is also suggested to monitor for any unintended consequences after the 'reject' policy is implemented.
Key opinions
- Security Benefit: Setting DMARC to 'reject' on non-sending domains significantly reduces the risk of domain spoofing and phishing.
- Valid Practice: Using a 'reject' policy on domains that do not send email is a standard and accepted security measure.
Key considerations
- Verification is Critical: Before implementing 'reject', meticulously verify that no legitimate email originates from the domain through any channel.
- Check Sending Methods: Check emails from contact forms, CRM integrations, system administration alerts, and all other potential sources.
- Reporting: Implement DMARC reporting to monitor for any unforeseen issues arising after implementing the 'reject' policy.
Marketer view
Email marketer from Stackoverflow explains that using a 'reject' policy is acceptable in some scenarios. They suggest setting up reporting to monitor for any potential issues after implementing the 'reject' policy in case services start sending emails.
7 Oct 2021 - Stackoverflow
Marketer view
Email marketer from LinkedIn shares that if your domain isn't used for sending emails, setting DMARC to 'reject' can provide an extra layer of security. This helps prevent spammers from using your domain in phishing campaigns.
9 Jun 2023 - LinkedIn
What the experts say
5 expert opinions
Experts agree that setting DMARC to 'reject' for domains not used for sending email is a viable and recommended security measure to prevent spoofing and phishing. The core requirement is ensuring absolutely no legitimate email originates from the domain or any sub/super domain. For internal systems, consulting with sysadmins or the hosting company is advised. It may not be worth investing heavily in DMARC deployment for such cases; gaining written agreement from management regarding the deliberate blocking of mail is suggested.
Key opinions
- Security Enhancement: Implementing DMARC 'reject' significantly strengthens domain security against spoofing and phishing attacks when the domain isn't used for sending.
- Valid Security Practice: Setting DMARC to 'reject' for non-sending domains is a legitimate and encouraged practice.
Key considerations
- Complete Verification: Thoroughly verify no legitimate email originates from the domain or any sub/super domains before implementing the 'reject' policy.
- Internal System Checks: Consult with sysadmins or the hosting company for internal systems to ensure no critical email functionality is disrupted.
- Management Agreement: Obtain written agreement from senior management acknowledging the intentional blocking of mail from the domain.
Expert view
Expert from Word to the Wise, Laura Atkins, explains that setting a DMARC record to 'reject' for a domain that doesn't send email is a perfectly reasonable approach. It prevents spoofing and unauthorized use of the domain in email From: addresses. It is essential to be absolutely sure no legitimate email originates from the domain.
21 Jan 2023 - Word to the Wise
Expert view
Expert from Email Geeks explains that as long as no mail is sent with that domain or any subdomain or superdomain of it in the From: address, setting DMARC to reject is acceptable.
26 Jun 2024 - Email Geeks
What the documentation says
4 technical articles
Official documentation from Google, DMARC.org, Microsoft, and Cloudflare uniformly states that setting DMARC to 'reject' on domains that do not send email is a valid, recommended, and safe practice. This policy instructs recipient mail servers to reject messages failing DMARC checks, effectively preventing unauthorized use of the domain, spoofing, and phishing attacks. It is especially useful for parked domains or those used solely for web hosting.
Key findings
- Recommended Security: Setting DMARC to 'reject' on non-sending domains is officially recommended for enhanced security.
- Prevents Spoofing: The 'reject' policy prevents malicious actors from spoofing the domain in email 'From' addresses.
- Unauthorized Use: The 'reject' policy prevents unauthorized use of the domain for sending emails.
Key considerations
Technical article
Documentation from Google explains that setting the DMARC policy to 'reject' instructs recipient mail servers to reject messages that fail DMARC checks. This is the strictest policy and prevents unauthorized use of your domain. If no email is supposed to originate from the domain this is safe to use.
9 May 2022 - Google
Technical article
Documentation from Cloudflare explains the reject policy to make it clear to receiving servers that if a message fails authentication checks, it should be rejected to improve security of your domain.
18 Aug 2024 - Cloudflare
What DMARC settings should I use and what are the implications of using p=reject?
How can I implement a DMARC reject policy for non-existent domains to prevent spam?
How can I ensure email compliance with Yahoo/Google rules including DMARC, SPF, and FcrDNS?
How do DMARC policies and RUA/RUF settings inherit or override each other between a domain and its subdomains?
How do I properly set up DMARC records and reporting for email authentication?
Are DMARC RUA and RUF tags mandatory for compliance and what are their benefits?
How should DMARC, SPF, and DKIM records be configured for domains that do not send email?
Should DMARC checks focus on SPF HELO or Return-Path and should you focus on DKIM or SPF?
Is DMARC essential for email deliverability and what to do when Return Path reports spam issues with good open rates?
