Summary
Implementing a DMARC reject policy for non-existent domains is a critical step in preventing email spam and spoofing that leverages look-alike domains. While standard DMARC policies (p=none, p=quarantine, p=reject) apply to active domains, the challenge with non-existent domains lies in their lack of DNS records. This often means they cannot host a DMARC record, allowing spammers to exploit them for malicious activities. This page explores how the `np` tag within DMARC can address this issue and the current state of its adoption.
Key findings
- ServerHold status: Domains under a ServerHold status typically cannot resolve, which should theoretically prevent email providers from accepting messages originating from them due to the absence of valid MX or A records. However, some mail providers might still accept and classify these emails as spam rather than rejecting them outright, indicating a gap in enforcement.
- DMARC np tag: The `np` tag within DMARC allows TLD (Top-Level Domain) operators to specify a policy for non-existent subdomains, offering a potential solution to prevent spam from such domains. This policy, when set to reject (np=reject), could instruct receiving mail servers to discard messages from these domains.
- SPF neutral for non-existent domains: When an email originates from a non-existent domain, its SPF check often results in a 'neutral' verdict because there is no record to permit or deny. This can allow such emails to bypass initial rejection, even if later flagged as spam. Improving how SPF handles these scenarios is important.
- DMARCbis development: The ongoing development of DMARCbis aims to refine the DMARC protocol, potentially strengthening the enforcement of policies like `np=reject` and improving overall email authentication for non-existent domains.
Key considerations
- TLD operator responsibility: The implementation of the `np` tag primarily rests with TLD operators, such as AFNIC for .fr domains. Without their proactive adoption, individual domain owners cannot enforce this policy for non-existent domains under that TLD.
- Receiver enforcement: Even if the `np` tag is implemented at the TLD level, its effectiveness depends on email providers consistently respecting and enforcing these policies. Variances in how providers handle non-resolving domains or `np=reject` policies can lead to inconsistent spam prevention.
- Current DMARC limitations: For domains that do not send email, a DMARC record with p=reject is recommended to explicitly signal that any email purporting to be from that domain should be rejected. This is different from the `np` tag, which targets domains that literally don't exist.
- Monitoring and reporting: While `np=reject` is ideal, understanding the impact of any DMARC policy requires careful DMARC monitoring to track how various receivers enforce policies for both existing and non-existent domains.
What email marketers say
Email marketers often face the challenge of brand impersonation and spam originating from domains that closely mimic their legitimate ones, even if these mimic domains are non-existent. While they may not directly implement policies for these domains, their experiences highlight the inconsistencies in how mail providers handle emails from non-resolving or non-existent senders. They seek more robust and consistent enforcement mechanisms across the email ecosystem to protect their brand and their recipients.
Key opinions
- Brand protection focus: Marketers are primarily concerned with preventing their brand from being used in phishing or spam campaigns, especially when look-alike domains are involved. They advocate for stronger preventative measures at the infrastructure level.
- Inconsistent enforcement: There's a recognized frustration that email providers' handling of non-existent or server-held domains varies. Some might flag as spam, while others might still allow delivery, albeit to the spam folder, undermining efforts to fully block malicious traffic.
- Desire for automated solutions: Marketers express a desire for automated mechanisms, such as blanket DMARC `p=reject` or `np=reject` policies, that could be applied across all non-existent domains to shut down potential spam sources at a broader scale.
- Impact on deliverability: While not directly about their sending, the prevalence of spoofing from non-existent domains can indirectly affect overall sender reputation and email deliverability by eroding trust in the email channel.
Key considerations
- Understanding DNS status: It is important for marketers to grasp the technical nuances of DNS records and domain status (like ServerHold) to understand why certain emails might still pass through despite originating from seemingly invalid domains, as explained by Mailgun's DMARC explanation.
- Monitoring DMARC reports: While `np` policies are at the TLD level, marketers can use DMARC reports to identify if their brand is being spoofed from non-existent domains, informing them of the ongoing threat even if direct action isn't possible.
- Advocacy for policy changes: Marketers can support efforts by industry bodies and TLD operators to implement stricter policies like the `np` tag, contributing to a more secure email ecosystem for everyone.
- Internal domain security: Ensuring their own domains have strong DMARC p=reject policies is the primary way marketers can prevent spoofing directly affecting their legitimate sending.
Marketer view
Email marketer from Email Geeks notes that emails from domains with a ServerHold status can still sometimes pass through to inboxes. This indicates that even when a domain is technically frozen and its DNS records are not resolving, some email providers may not enforce a hard rejection.
Marketer view
Email marketer from Spiceworks Community states that they've seen emails go through even from domains that shouldn't resolve, sometimes ending up in the spam folder. This highlights the inconsistent application of DNS checks by different email providers.
What the experts say
Email deliverability experts highlight that while a ServerHold status on a domain should theoretically prevent it from sending emails, the reality is more nuanced. They emphasize the critical role of the `np` tag within DMARC to define policies for non-existent subdomains, underscoring that universal adoption by TLD operators and consistent enforcement by mail receivers are necessary for this mechanism to be fully effective in combating spam and spoofing.
Key opinions
- DNS resolution is key: Experts agree that if a domain's DNS records (like MX or A records) do not resolve, email providers should ideally not accept messages from it. This is a fundamental layer of defense against non-existent domain abuse.
- Limitations of 'best guess' SPF: The concept of 'best guess' SPF, where a neutral verdict is given for non-existent domains, is seen as a legacy issue that needs to be phased out to improve email security.
- The `np` tag's potential: The DMARC `np` tag (no policy) is recognized as the correct technical solution for TLDs to specify DMARC policies for non-existent domains, allowing for a universal `np=reject` at that level.
- DMARCbis advancements: The DMARCbis update is seen as a crucial step towards standardizing and improving the enforcement of DMARC, including policies for non-existent domains, currently being reviewed for finalization.
Key considerations
- TLD operator adoption: The primary barrier to widespread `np=reject` enforcement for non-existent domains is the adoption by TLD operators. Without this, individual domain owners have limited recourse for these types of spoofing attempts.
- Inconsistent receiver support: Even with the `np` tag implemented, there's uncertainty about which mail receivers currently respect and fully enforce these policies, leading to a fragmented defense.
- Patience for DMARCbis: Full and consistent implementation of `np` policy enforcement may require waiting for DMARCbis to be fully ratified and widely adopted by email service providers.
- Proactive self-protection: While awaiting broader adoption of the `np` tag, organizations should ensure their own legitimate domains have robust DMARC p=reject policies to protect against spoofing where their actual domain is impersonated.
Expert view
Deliverability expert from Email Geeks clarified that a ServerHold status means the nameservers will not resolve, implying that no DNS records can be added to such a domain. Therefore, email providers should not accept messages from it.
Expert view
Mail security expert from Word to the Wise explains that the goal of email authentication (SPF, DKIM, DMARC) is to establish trust. For domains that don't exist, this trust cannot be established, making them prime targets for abuse if not properly handled by receivers.
What the documentation says
Official documentation and internet standards provide the technical framework for DMARC, including provisions for handling non-existent domains. The DMARC protocol aims to empower domain owners to specify how unauthenticated messages from their domain should be handled. The `np` tag specifically addresses how policies can be set for subdomains that do not exist, offering a mechanism for Top-Level Domain operators to universally prevent spoofing across their domain space.
Key findings
- EPP status codes: ICANN's EPP status codes, such as ServerHold, indicate that a domain is not active and its nameservers should not resolve. This implies that emails from such domains should ideally not be delivered.
- DMARC `np` tag: RFC 9091 (and its successor, DMARCbis) defines the `np` tag, which allows a DMARC record to specify a policy for non-existent subdomains. This means a TLD or domain owner can declare a `p=reject` policy for any subdomain that is not explicitly defined in DNS.
- DMARCbis updates: The DMARCbis draft aims to obsolete previous DMARC RFCs (7489 and 9091) and provide updated guidance, including clarifications on the `np` tag and its expected behavior.
- Policy for non-sending domains: While `np` addresses non-existent subdomains, for existing domains that simply do not send email, DMARC documentation recommends a DMARC record with `p=reject` to clearly indicate that no legitimate email should originate from them.
Key considerations
- TLD-level implementation: The `np` tag is designed for implementation at the TLD (or organizational domain) level, not typically by individual subdomain owners. This requires cooperation from registry operators.
- Receiver interpretation: While documented, the consistent interpretation and enforcement of `np=reject` by all email service providers remain a challenge, as seen with other DMARC policy elements.
- Phased DMARC deployment: The standard DMARC deployment process recommends starting with `p=none` and gradually moving to `p=quarantine` and then `p=reject`, which also applies to the consideration of safely transitioning policies for any domain.
- RFC compliance: Adherence to RFCs is crucial for the interoperability and effectiveness of email authentication protocols like DMARC, SPF, and DKIM.
Technical article
ICANN EPP Status Codes documentation outlines that the ServerHold client status code indicates a domain's inability to resolve and function on the internet. This implies that domains with this status should not be capable of sending email.
Technical article
RFC 9091, Section 3.2, describes the `np` tag, which specifies the policy for non-existent organizational subdomains within a DMARC record. This allows for a `p=reject` policy to be applied to any subdomain that is not explicitly created.
Related resources
11 resources
Related pages
How to implement DMARC p=reject policy safely to avoid email deliverability issues?
What are the best practices for setting DMARC policy, particularly p=reject?
How to use DMARC p=reject to combat email spoofing and its potential impact on legitimate mail?
How should DMARC, SPF, and DKIM records be configured for domains that do not send email?
Can I set DMARC to reject if my domain doesn't send email?
How can I use DMARC to prevent spammers from using my domain?
List of DMARC tags and their meanings
DMARC record and policy examples
The benefits of implementing DMARC
How to safely transition your DMARC policy to quarantine or reject
