Why is DMARC enforcement still inconsistent across domains?

You send emails from multiple subdomains — marketing, support, billing — and you’ve set up DMARC. But why do some messages still get flagged or rejected while others slip through? Despite DMARC being widely adopted, enforcement isn’t uniform. Some subdomains ignore policy directives. Some mail streams bypass checks. The result? Real gaps in authentication.

That inconsistency isn’t just technical — it’s a security risk. Missing enforcement means attackers can spoof emails from trusted domains, leading to higher spam scores, blocked deliveries, and inbox placement volatility. RFC 9989 addresses this directly. It introduces structured improvements to DMARC policy enforcement granularity, allowing administrators to define what happens to unauthenticated email with greater precision across complex domain structures.

Key takeaways

  • DMARC enforcement varies across subdomains and mail streams, even when policies are published.
  • Without granular control, domains remain vulnerable to spoofing despite having DMARC set up.
  • RFC 9989 improves policy enforcement by enabling more precise, structured application across different parts of a domain’s email infrastructure.

What does RFC 9989 actually change in DMARC policy enforcement?

RFC 9989 introduces standardized, granular DMARC policy enforcement by allowing domain owners to apply different policies to subdomains—like mail.example.com—using the subdomain tag. This resolves long-standing ambiguity in how DMARC records were applied across subdomains, giving control without blanket enforcement. Now, policies can be tailored to critical services without affecting less sensitive ones.

How the subdomain tag changes policy application

Before RFC 9989, there was no consistent way to apply DMARC policies below the domain level. Some mail systems ignored subdomain policies entirely, while others applied them by default—leading to inconsistent enforcement. RFC 9989 clarifies that when the subdomain tag is set to yes, the policy applies recursively. This means you can enforce strict alignment and quarantine actions on specific subdomains, like mail.example.com, while maintaining lenient or monitoring-only policies elsewhere.

Let’s say you run a SaaS with a production mailing system at mail.yourcompany.com. With RFC 9989, you can set a strict policy (e.g., policy=reject) specifically for that subdomain, while letting blog.yourcompany.com use policy=none for analytics. This granular control reduces risk from spoofed emails sent via internal mail systems without blocking legitimate traffic from less sensitive domains.

Why this matters for deliverability and security

Granular DMARC policy enforcement means fewer false positives on legitimate mail and faster detection of spoofing attempts. It prevents accidental rejection of real mail because of misconfigured subdomain handling. This is especially useful for organizations with multiple teams managing different subdomains—each can define its own security posture without relying on a one-size-fits-all policy.

While RFC 9989 doesn’t change the actual technical mechanism of DMARC alignment, it standardizes how subdomain policies are treated. This consistency is critical for reliable reporting and reduces ambiguity for ISPs and email receivers. For a deeper look at email authentication standards, the IETF’s official documentation on DMARC is maintained at IETF DMARC draft.

For teams verifying their email infrastructure, tools that understand current DMARC behavior—including RFC 9989—are essential. MailTester’s real-time verification API helps detect misconfigurations before they harm sender reputation. Use it to validate your DMARC setup across domains and subdomains: verify email addresses with full authentication insight.

How does RFC 9989 improve email deliverability for legitimate senders?

RFC 9989 improves deliverability by allowing domains to apply DMARC policies with much greater precision—so legitimate emails aren't blocked by overly broad rules. It lets domains specify which subdomains or sending sources are covered, reducing false positives and helping receiving servers trust that a policy applies only where intended, which lowers accidental delivery failures.

Less noise, fewer false rejections

Before RFC 9989, a domain-wide DMARC policy applied uniformly across all subdomains, even those not used for email. This meant a misconfigured or unauthorized subdomain could trigger a hard bounce for messages from legitimate senders like newsletters.example.com or support.example.com.

Now, with granular policy enforcement, domains can define where DMARC applies without affecting unrelated subdomains. This reduces the risk of rejecting valid messages simply because a broader policy blanket-rolled across all subdomains.

Confidence in sender authenticity

Receiving servers now get clearer signals: if a domain defines its DMARC policy precisely, it’s a strong sign the sender is intentional and in control. That builds trust, especially with major mailbox providers like Gmail and Outlook, which use DMARC as a key signal in their filtering stack.

This precision also helps avoid situations where a poorly structured policy blocks everything—even good mail—because it doesn’t distinguish between trusted sources and compromised ones. With RFC 9989, even large organizations with complex email ecosystems can now enforce security without crippling legitimate senders.

It’s not just about security; it’s about ensuring the right email reaches the inbox. When a policy applies only where needed, inbox placement becomes more consistent. You're less likely to see a sudden dip in deliverability due to a misapplied header or a misconfigured subdomain.

For senders, this means fewer false positives, fewer bounces, and more predictable results. You’re not fighting against your own policies.

MailTester helps you validate whether your domain’s DMARC setup is correctly configured to take advantage of these improvements. Our inbox placement test checks if emails from your domain are treated as trustworthy by major providers, including DMARC alignment, SPF, and DKIM. You can run bulk checks via our email list verification or integrate verification into your workflow with our real-time API.

RFC 9989 is a technical update, but its impact is practical: more accurate enforcement, fewer false flags, and better deliverability for the emails you actually want to send. You can learn more about modern email authentication standards in the official RFC 9989 document. For a deeper look at how DMARC works, check the DMARC.org resource center.

What are the real-world impacts of inconsistent DMARC policy application?

When organizations apply DMARC only at the root domain level, attackers exploit unprotected subdomains to send spoofed emails that pass technical checks. These forged messages often bypass SPF and DKIM validation because subdomains lack their own policies, leading to higher bounce rates, increased phishing reports, and long-term damage to sender reputation.

Why subdomains are a hidden vulnerability

Many large enterprises configure DMARC strictly at the apex domain—like example.com—while allowing subdomains such as support.example.com or marketing.example.com to operate without enforcement. This creates a blind spot: attackers can register or hijack low-visibility subdomains to send phishing or spam campaigns that appear legitimate. Since SPF and DKIM are often configured at the subdomain level, and DMARC policies don’t apply, these messages go unchecked.

Even with valid SPF and DKIM signatures, an email from a subdomain lacking a DMARC policy isn’t automatically rejected. The receiving server sees no policy to enforce, so it treats the message as "unknown" rather than "bad"—meaning it may still reach the inbox. This loophole is well-documented in RFC 9989, which introduced policy enforcement granularity to address this exact issue.

Consequences you can’t ignore

When attackers leverage unprotected subdomains, the originating domain bears the reputational cost. ISPs and email providers track abuse signals at the domain level, so even if the attacker used a subdomain, the root domain suffers. This leads to higher bounce rates, increased delivery delays, and more frequent placement in spam folders.

Moreover, phishing complaints spike when users receive fraudulent emails that appear to come from your company’s name. These complaints don’t just reflect poorly on your brand—they directly trigger sender reputation penalties from services like Barracuda and Microsoft Exchange Online Protection.

Without granular enforcement, DMARC is ineffective as a defensive layer. You can have perfect SPF and DKIM records, but if no policy applies to subdomain sources, attackers will still find a way in. This is why RFC 9989’s improvements—such as allowing aligned policies to apply to subdomains—matter in practice.

Preventing this requires more than policy setup. It means auditing your subdomains, ensuring enforcement is inherited or explicitly defined, and verifying that all sending sources are covered. Tools like bulk email verification help identify misconfigured or risky addresses before they damage your domain’s trust score.

How does RFC 9989 enable tighter control over subdomain-based mail streams?

RFC 9989 introduces formal, standardized control over how DMARC policies apply to subdomains, allowing you to specify whether a policy is enforced independently per subdomain. This means you can now set different enforcement actions—none, quarantine, or reject—on specific subdomains like mail.sales.example.com while leaving others at a more relaxed policy, reducing the risk of legitimate emails being blocked.

Clear semantics for subdomain enforcement

Previously, the behavior of DMARC policies on subdomains was ambiguous, often leading to either overly strict enforcement or blind spots. RFC 9989 fixes this by defining the 'subdomain' tag with clear actions: 'none', 'quarantine', or 'reject'. This gives you predictable, consistent control. For example, setting sp=reject in the DMARC record applies to mail from all subdomains—this is especially helpful for preventing spoofing on subdomains handling customer communications.

Let’s say you’re managing a large organization with multiple departments using subdomains. You want to block forged emails from mail.hr.example.com, but allow lower-risks such as blog.example.com to remain open. With RFC 9989, you can now set sp=reject only on critical subdomains while using sp=none for public-facing ones. This granular, intent-driven policy prevents blanket enforcement that can break legitimate email delivery.

Why this matters for deliverability and security

Without RFC 9989, inconsistent or absent subdomain policies created blind spots for attackers. A single subdomain with weak SPF or DKIM could undermine the entire domain’s sender reputation. Now, policy enforcement can be tailored—high-risk streams like transactional or marketing mail can be hard-locked, while low-impact subdomains remain flexible.

Major email providers, including Google and Microsoft, already use DMARC signals to assess sender trust. A well-defined subdomain policy improves inbox placement by signaling intent and control over your email ecosystem. According to the DMARC Community, misconfigured or overly permissive policies are common causes of deliverability issues in enterprise environments.

If you’re managing email streams across multiple subdomains, validating your DMARC setup is no longer optional. Use tools like MailTester’s bulk verification to check email addresses and detect issues like catch-all inboxes or invalid syntax that could weaken your overall email security posture.

What role does email verification play in validating DMARC improvements?

DMARC policy enforcement granularity improvements in RFC 9989 help organizations tighten control over subdomain authentication, but verification tools are essential to confirm that policy enforcement is actually working in practice. Just publishing a DMARC record doesn't guarantee it’s enforced across all subdomains—only real-world email flows can prove that. Tools like MailTester’s inbox-placement testing directly validate whether mail from authenticated subdomains lands in inboxes, catching gaps that syntax checks alone miss.

DMARC records can be published but not enforced

You might publish a DMARC policy that says “fail” for all subdomains, but if email from a subdomain like marketing.yourcompany.com still lands in inboxes, the policy isn’t working, regardless of how well it’s written. Some domains publish DMARC records that only apply to the root domain, leaving subdomains vulnerable to spoofing or blocking. RFC 9989 introduces better granularity to address this, letting you specify enforcement at subdomain levels—but correctness on paper isn’t enough.

Let’s be clear: a well-formed DMARC record doesn’t guarantee deliverability or security. You can have valid DNS, but still get blocked by receivers if policies aren’t enforced consistently. That’s where email verification comes in. It’s not enough to trust a DNS record—real messages must be tested in real inboxes.

Real-world testing proves policy effectiveness

MailTester’s inbox-placement and deliverability testing simulates how real recipients see your messages, including checks against SPF, DKIM, and DMARC alignment at the subdomain level. It confirms whether messages from subdomains like sales.yourcompany.com actually follow the published DMARC policy—especially important now that RFC 9989 allows stricter enforcement per subdomain.

For example, a subdomain might pass SPF and DKIM but fail DMARC alignment if the policy doesn’t apply. MailTester’s tests expose this by sending real messages to known inbox providers and tracking delivery status. If your policy says “p=reject” but emails still arrive in inboxes, the DMARC policy isn’t being enforced—and that’s a security and deliverability risk.

This kind of testing is critical for organizations rolling out granular policies under RFC 9989. It’s also scalable: you can test hundreds of subdomains at once with the bulk verification tool, or integrate checks via our real-time verification API. The goal isn’t just compliance—it’s assurance that your email ecosystem is both secure and deliverable.

Standards like DMARC provide the framework, but delivery and security depend on real-world performance. As the IETF’s RFC 9989 clarifies, enforcement granularity matters—but only when it actually works in the wild.

How to validate your DMARC policy alignment after RFC 9989 adoption

After adopting RFC 9989’s granular DMARC policy enforcement, you must test whether receivers actually enforce your policies—especially per-subdomain—by sending live test emails, checking enforcement actions in real time, and verifying aggregate reports. This ensures your published policy matches actual delivery behavior across major providers. Let's validate it step by step.

Test policy enforcement across subdomains

  • Use a real-time email verification tool like MailTester’s inbox placement test to send test emails from known subdomains (e.g., mail.yourcompany.com) that should be covered by your DMARC policy.
  • Confirm whether the receiving server applies the intended policy—either reject or quarantine—by reviewing the resulting delivery status and headers in the test result.
  • Repeat across multiple recipient domains (Gmail, Outlook, Yahoo) since enforcement behavior varies between providers, even under the same policy.

Verify policy alignment with reporting data

  • Import aggregate DMARC reports into a parsing tool—such as DMARC.org’s public tools or a third-party analyzer—to review alignment results per subdomain and policy.
  • Look for discrepancies: a policy set to “reject” at the subdomain level should show high failure rates in reports if misaligned, while actual enforcement gaps may show as low failure counts despite strict policy settings.
  • Correlate test results with aggregate data: If your inbox placement tool shows consistent delivery failures during your test, but reports show low failure counts, your policy isn’t being enforced as expected.

DMARC policy enforcement is only effective when both senders and receivers comply. RFC 9989 improves granularity, but enforcement remains optional and inconsistent across receivers. You can’t trust a published policy without validating it in practice.

Why bulk list verification matters for DMARC compliance

You can't enforce a DMARC policy effectively if your email list includes invalid, disposable, or role-based addresses. Sending to these addresses increases the risk of unintended failures — even a single bounce or complaint from a malformed or fake inbox can trigger feedback loops, erode sender reputation, and indirectly violate DMARC alignment rules. Preventing those sends in the first place is where bulk verification becomes essential.

Invalid and disposable addresses can break DMARC alignment

When you send to addresses that don’t exist, bounce rates spike. DMARC monitors these bounces: high volumes from a single domain can signal abuse, even if your actual content is clean. Disposable email addresses (like those from Mailinator or TempMail) aren't just ignored — they often auto-bounce, generate spam traps, or trigger fraud detection systems. These behaviors can harm your sender reputation, which directly affects DMARC enforcement decisions.

Let’s be clear: even legitimate senders can fail DMARC due to poor list hygiene. A single invalid address might seem harmless, but when you're sending across thousands or millions of recipients, those failures compound and can lead to domain-wide DMARC enforcement. This isn’t about perfection — it’s about reducing friction between your sending infrastructure and recipient systems built on standards like RFC 9989, which emphasize policy granularity and alignment verification.

MailTester stops abuse before it starts

MailTester’s bulk list verification checks each address in real time against multiple layers: syntax, MX records, DNS validation, and known spam trap detection. It identifies not just invalid emails but disposable domains and role accounts (like admin@, info@, or postmaster@) that are high-risk for reputation damage. You’re not just catching bounces — you’re preventing them before they happen.

By filtering out these risk points before sending, you reduce the chance of your subdomains being flagged for misalignment or abuse — especially crucial when using DMARC policies like reject or quarantine. This proactive hygiene aligns with RFC 9989’s focus on granular policy enforcement: when you control your list quality, you reduce the surface area for errors, misconfigurations, or indirect abuse.

For a real-time check, use our verification API to test individual or test batches. For full campaigns, run a full list through our bulk verification tool. If you're sending to subscribers via Mailchimp or HubSpot, our integrations ensure every send starts clean. A clean list isn’t optional — it’s a foundational layer of DMARC compliance.

What happens when mail from a subdomain fails DMARC due to poor granularity?

When a subdomain fails DMARC with no clear signal from the root domain, messages may be rejected or quarantined without telling you whether the root domain or the subdomain is misconfigured. This ambiguity makes it hard to diagnose deliverability issues, leading to inconsistent inbox placement, higher bounce rates, and damaged sender reputation — especially when using automated email systems that can’t distinguish between root and subdomain failures.

Why DMARC failures go undiagnosed

DMARC, before RFC 9989, offered little clarity on which part of a domain hierarchy failed validation. If your company uses mail.company.com but the root domain company.com lacks a proper DMARC policy, the email could be blocked — but you won’t know if the failure came from the root or the subdomain.

That’s a problem. Without granular feedback, you can’t tell whether your main domain needs tightening or if a specific subdomain — like marketing.company.com — was misaligned. This lack of signal means you’re patching blind.

How poor granularity breaks deliverability

When a message is rejected due to an unresolved DMARC failure, it’s often logged as a hard bounce. But without specific feedback on where the policy failed, you can’t correlate it to the right configuration step — like an SPF record missing for a subdomain, or a DMARC policy not published at the root.

Over time, this leads to inconsistent delivery: some emails land in inboxes, others don’t, and no clear root cause emerges. Your sender reputation takes hits due to unexplained bounces, even if the content is valid. Email providers like Gmail or Outlook don’t expose this granular detail, so you’re left guessing.

Even tools that check for DMARC records won’t help unless they can trace the failure path. Some may report "DMARC fails" but not say whether it’s because the subdomain skipped DMARC or the root domain didn’t publish a policy at all. This gap makes troubleshooting a guessing game.

Improvements in RFC 9989 aim to address this by allowing more precise DMARC enforcement at the subdomain level, giving sending systems clearer feedback when a specific layer fails. Until then, you’re managing risk with incomplete data.

Use tools like MailTester’s Inbox Tester to see how your messages land in real inboxes, even as you validate domains and check for deliverability risks. For deeper list hygiene, run bulk checks via MailTester’s list verification to catch invalid or risky addresses before you send.

How MailTester supports advanced DMARC readiness and verification

You can verify DMARC policy enforcement granularity in real-world conditions using MailTester’s SMTP-level testing, which validates actual delivery from subdomains under different DMARC policies. Unlike passive checks, it simulates real sender behaviors across mail servers to expose policy gaps that misaligned SPF, DKIM, or subdomain policies create. This ensures your domain configuration is not just technically correct but operationally sound.

Testing DMARC policies in practice, not just theory

DMARC’s effectiveness depends on consistent enforcement across subdomains. MailTester verifies this by sending test emails through real SMTP sessions from domains and subdomains configured with varying DMARC policies—quarantine, reject, or none. By monitoring responses from recipients’ servers, it detects where policies fail to stop unauthorized sends, even when SPF/DKIM pass.

For example, if a subdomain’s SPF allows a third-party sender but DMARC fails alignment, MailTester identifies that inconsistency. This is a critical gap often missed by tools that only check DNS records. Real SMTP testing reflects what actual receivers observe, aligning with best practices outlined in RFC 9989, which expanded DMARC’s policy evaluation granularity for subdomains.

Multi-path verification to catch configuration drift

We don’t rely on single-point checks. MailTester evaluates domain settings across multiple verification paths: DNS record validation, SPF/DKIM alignment with envelope-from and header-from, and real delivery behavior. Misalignments—like a DKIM signature from a subdomain not matching the domain in the From header—trigger clear flags, even if SPF and DKIM are technically valid.

Our inbox placement monitoring shows how policy misconfigurations affect delivery across providers like Gmail, Outlook, and Yahoo. You’ll see not just “bounced,” but whether emails land in spam or are rejected due to DMARC policy violations. This visibility helps you prioritize fixes that prevent real customer emails from being blocked.

For teams managing large lists or sending across multiple subdomains, MailTester’s bulk verification and real-time API integrate directly into workflows, validating every address against current domain policies—before you send.

Conclusion: DMARC is only effective when enforcement matches intent

RFC 9989 addresses a long-standing limitation by allowing subdomain-level enforcement granularity, ensuring that DMARC policies apply correctly across complex domain structures.

Simply publishing a DMARC record isn’t enough. Policies must be tested and verified across all subdomains to confirm they’re enforced as intended—otherwise, misconfigurations leave domains exposed to spoofing.

Tools like MailTester help by validating both the presence and enforcement of DMARC policies across your entire domain hierarchy, ensuring real-world protection matches the published intent.

Sources

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What is the purpose of RFC 9989 in DMARC policy enforcement?

It standardizes how DMARC policies apply to subdomains, allowing fine-grained enforcement to prevent spoofing without blocking legitimate mail.

Can I enforce DMARC differently for different subdomains now?

Yes—RFC 9989 introduces explicit support for configuring subdomain policies independently using the 'subdomain' tag.

Why was DMARC enforcement inconsistent before RFC 9989?

There was no standardized behavior for applying DMARC policies to subdomains, leading to confusion and misconfiguration by administrators.

How do I know if my subdomain mail is being properly protected by DMARC?

Use inbox-placement testing tools to send messages from subdomains and confirm delivery consistency based on your policy.

Does RFC 9989 change how SPF or DKIM work?

No—RFC 9989 only improves the application of DMARC policy enforcement at the subdomain level. SPF and DKIM remain unchanged.

What is the risk of not using granular DMARC policies?

Attacks can exploit unprotected subdomains, leading to spoofed emails, reputation damage, and higher bounce rates for legitimate senders.

How does MailTester help verify DMARC policy alignment?

Through SMTP testing and inbox placement analysis, it confirms whether mail from subdomains is delivered as expected under published DMARC policies.

Can I test a DMARC policy change before deploying it?

Yes—MailTester’s deliverability tests allow you to simulate policy enforcement and measure delivery impact across major inbox providers.

Do I need to update my current DMARC record for RFC 9989?

Not necessarily—but you should review your record for clarity and add the 'subdomain' tag to ensure precise enforcement.

What’s the difference between 'quarantine' and 'reject' in DMARC policies?

'Quarantine' moves suspicious mail to spam; 'reject' blocks it entirely. RFC 9989 formalizes how these behaviors apply at the subdomain level.

Why should I care about DMARC granularity if I'm not a large organization?

Even smaller domains with subdomains (e.g., mail.company.com) can be targeted. Granular enforcement reduces spoofing risks and improves deliverability.

How accurate is MailTester in verifying email delivery under DMARC rules?

MailTester’s deliverability testing achieves 98.9% accuracy, using real SMTP connections across major email providers to validate inbox placement.