How can I implement a DMARC reject policy for non-existent domains to prevent spam?
Matthew Whittaker
Co-founder & CTO, Suped
Published 15 May 2025
Updated 17 Aug 2025
7 min read
Email spoofing and phishing attacks continue to pose significant threats, often leveraging domains that appear legitimate but are, in fact, non-existent or inactive. These abandoned or typo-squatted domains become prime targets for bad actors looking to trick recipients. Implementing a DMARC reject policy for these domains is a powerful way to shut down such abuse and protect your brand’s reputation.
While securing active sending domains is crucial, it is equally important to address domains that do not send emails, including subdomains and those set up for purely organizational purposes. These non-sending domains are often overlooked, leaving them vulnerable to impersonation. A comprehensive DMARC strategy ensures that even if a domain isn't sending mail, it's still protected from unauthorized use.
DMARC, or Domain-based Message Authentication, Reporting, and Conformance, is an email authentication protocol built on top of SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). It provides instructions to receiving mail servers on how to handle emails that fail authentication and offers feedback to the domain owner through DMARC reports. This allows you to gain visibility into email streams using your domain, identify potential spoofing attempts, and progressively enforce policies to combat them.
For non-existent domains, the primary goal is to prevent any email purporting to be from them from ever reaching an inbox. Because these domains aren't meant to send legitimate email, setting a strict DMARC policy is typically safe and highly effective. Without DMARC, a typo-squatted domain (e.g., qouv.fr instead of gouv.fr) could be used by spammers, even if the domain itself is frozen or has no resolving DNS records, as some receivers might still accept the mail before further checks.
The enforcement of DMARC relies on the receiver's adherence to the policy set in your DMARC record. While most major mailbox providers follow DMARC policies, there can be variations in how they interpret or apply them. Therefore, a comprehensive strategy includes not only publishing the record but also monitoring how different receivers react to it.
The reject policy for non-existent domains
The core of preventing spam from non-existent domains lies in the p=reject policy. This policy tells receiving email servers to outright reject (discard) any emails that fail DMARC authentication for your domain. For a domain that should never send email, this is the strongest and most effective policy to implement. It ensures that any illegitimate email from your domain is not even delivered to the spam folder, but simply blocked.
Beyond the primary domain policy, the DMARC protocol also includes the sp (subdomain policy) tag and a less commonly adopted np (non-existent domain policy) tag. The sp tag allows you to specify a policy for all subdomains. If your root domain has p=reject, you would often mirror this with sp=reject to cover subdomains that might not have their own DMARC records. The np tag, though not universally supported by all Mailbox Providers (MBPs), allows the Top-Level Domain (TLD) operator to set policies for nonexistent domains under their TLD. For example, .gov TLD uses np=reject, which is a strong measure.
By setting p=reject (and sp=reject) for domains that should not send email, you are essentially creating a firewall against malicious spoofing attempts. This proactive approach significantly reduces the chances of your brand being exploited in phishing campaigns, thereby protecting your brand's reputation and your recipients.
Implementing the reject policy
DMARC policy types
p=none: This is a monitoring-only policy. Emails that fail DMARC authentication are still delivered, but you receive DMARC reports, giving you visibility into your email ecosystem. It is the safest starting point for any domain, especially active sending domains.
p=quarantine: Emails that fail DMARC authentication are sent to the recipient's spam or junk folder. This is a step up in enforcement, but still allows some visibility into potential issues if recipients check their spam folders.
p=reject: The strictest policy. Emails that fail DMARC authentication are rejected outright and not delivered to the recipient's inbox or spam folder. This is ideal for non-sending domains, or domains with 100% authenticated legitimate traffic.
The implementation process for a DMARC reject policy for non-existent domains is generally simpler than for active domains because there's no legitimate email traffic to accidentally block. However, it's still crucial to ensure proper configuration. The first step is to ensure that your domain has basic SPF and DKIM records, even if they are minimal.
For SPF, you'd typically have a record that explicitly states no hosts are authorized to send email. For DKIM, you might have a null DKIM record. These records help ensure that when a malicious actor attempts to spoof your non-existent domain, the SPF and DKIM checks will definitively fail, triggering the DMARC policy.
After setting up SPF and DKIM, you can publish your DMARC record. This is a TXT record added to your domain's DNS. The key components of the DMARC record for a non-existent domain would be the p=reject tag and ideally the sp=reject tag, which applies the policy to all subdomains as well. Including rua (aggregate reports) and ruf (forensic reports) email addresses is also vital, even for non-sending domains, as it provides valuable insight into whether your policy is being enforced and if any spoofing attempts are occurring.
The immediate transition to p=reject for non-existent domains is generally safe because no legitimate email should be sent from them. This allows you to aggressively protect these domains from day one. You can use a DMARC record generator to create the necessary TXT entry.
Monitoring and troubleshooting for non-existent domains
Even with a p=reject policy in place for non-existent domains, monitoring is still a crucial component. DMARC aggregate reports (rua) provide daily XML reports from participating email receivers, detailing all email traffic seen purporting to be from your domain, regardless of its authentication status. For non-existent domains, you would expect to see very little or no legitimate traffic, and any failed authentication attempts should be clear indications of spoofing attempts that were correctly rejected by receivers adhering to your policy.
One challenge to be aware of is that not all MBPs will necessarily honor the np tag, as it's a newer addition to the DMARC specification (RFC 9091). While it's gaining traction, some might still deliver such emails to spam or even the inbox if their SPF neutral or none policies are not strictly enforced. Regular monitoring of DMARC reports helps you identify any such gaps and take further action if necessary, such as contacting specific providers.
Views from the trenches
Best practices
Always include 'rua' and 'ruf' tags in your DMARC record to receive valuable reports on email traffic.
Regularly review DMARC reports to spot any unpredicted email sources or spoofing attempts on your non-existent domains.
Ensure your DNS records for non-existent domains are configured to explicitly state no valid senders via SPF.
Consider adding an 'np=reject' tag to your DMARC record if your TLD supports it and you wish to apply the policy to non-existent sub-domains.
Common pitfalls
Failing to set up DMARC for non-sending domains, leaving them vulnerable to impersonation.
Not monitoring DMARC reports, thus missing potential spoofing attempts or policy enforcement issues.
Assuming all Mailbox Providers (MBPs) will strictly adhere to the 'np' tag without verifying its effectiveness.
Overlooking the need for basic SPF and DKIM records on non-existent domains, even if minimal.
Expert tips
The absence of A or MX records for a domain might lead some receivers to reject emails by default, but DMARC provides explicit instruction.
Even if a domain is on ServerHold, some mail flow might still occur, making a DMARC 'p=reject' policy valuable.
Engage with TLD operators to encourage broader adoption of the 'np' tag for enhanced anti-spoofing protection.
Keep an eye on the DMARCbis (DMARC version 2) developments for future enhancements in domain protection.
Expert view
Expert from Email Geeks says even if a domain is on ServerHold, preventing DNS resolution, some email providers might still accept messages, especially if the SPF record evaluates to neutral. DMARC's `np` tag is designed to address this by explicitly specifying policies for non-existent domains.
2024-09-06 - Email Geeks
Marketer view
Marketer from Email Geeks says enforcing a DMARC reject policy on typo-squatted or unmanaged domains is challenging, especially when direct DNS control is absent, making it difficult to prevent their use in spam campaigns.
2024-09-06 - Email Geeks
Strengthening your domain's perimeter
Implementing a DMARC p=reject policy for non-existent domains is a critical, yet often overlooked, step in a comprehensive email security strategy. By explicitly telling receiving mail servers to discard any emails that fail authentication from these domains, you significantly reduce the risk of your brand being used in spoofing and phishing attacks.
While the process is straightforward, maintaining vigilance through DMARC reports ensures your policy is effectively protecting your domain. This proactive defense not only safeguards your brand reputation but also contributes to a cleaner, safer email ecosystem for everyone.
