Why does a wildcard DNS record break DMARC inheritance?

You set up a DMARC policy for your domain. You’re confident it protects your brand. Then you notice authentication failures on emails sent from subdomains like mail.company.com — even though those domains have their own SPF and DKIM settings. Why?

It’s not a fluke. It’s often because a wildcard DNS record like *.example.com quietly overrides your intention, breaking DMARC inheritance. The system evaluates policies at the domain level, but wildcards apply to every subdomain — including those meant to be isolated. When misconfigured, they can redirect or block DMARC reports, or even allow unauthorized mail to pass undetected.

Key takeaways

  • Wildcard DNS records (e.g. *.example.com) apply to all subdomains, including those used for email sending, potentially bypassing intended DMARC policies.
  • DMARC inheritance relies on correct DNS configuration at both the parent domain and subdomain level — a wildcard can disrupt this chain by unintentionally overriding subdomain-specific records.
  • Incorrectly configured wildcards may cause DMARC reports to be misdirected or fail to generate, hiding authentication issues and weakening email security.

How do wildcard records interfere with DMARC policy enforcement?

Wildcard DNS records—like a catch-all MX or SPF—can override intended subdomain policies, causing DMARC to incorrectly validate or reject emails. This happens because DMARC evaluates alignment based on the sending domain, and wildcards can mask misconfigurations, leading to false passes or unexpected rejections when a subdomain has its own distinct sending setup.

Wildcard records undermine alignment expectations

DMARC relies on consistent SPF and DKIM alignment between the From domain and the authentication results. If a wildcard SPF record exists at the parent level, it applies to all subdomains, even if a subdomain uses a different sender or service. The receiving mail server sees the wildcard SPF, not the subdomain-specific one, and that breaks alignment. That means a message sent from a subdomain through a third-party platform (like Mailchimp or SendGrid) may appear unauthenticated—despite having valid DKIM signatures—because the SPF policy doesn’t match the From domain.

Let’s say you have a subdomain marketing.yourcompany.com sending transactional emails via a dedicated ESP. If your root domain has a wildcard SPF record like include:_spf.example.com that applies to all subdomains, but the subdomain has its own valid SPF with a different mechanism, DMARC can still fail. The receiving server checks the SPF result against the From address, which points to the subdomain. If that subdomain’s SPF is not properly aligned—or not recognized due to the wildcard override—DMARC fails, even if the message is legitimate.

This issue is documented in RFC 7208, the DMARC standard, which states that alignment must be based on the actual sending infrastructure. Wildcards bypass that by applying a generic policy, obscuring subdomain-specific configurations. According to the Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG), inconsistent DKIM or SPF alignment remains one of the top reasons for DMARC failures in enterprise environments.

Subdomains with unique sending infrastructures are especially vulnerable

When a subdomain handles sensitive or high-volume email (like customer support or marketing blasts), relying on a shared or wildcard SPF record can silently break deliverability. For example, using a global SPF with multiple includes risks including untrusted services. If one of those services gets compromised, the wildcard SPF may still allow it to pass SPF checks—but DMARC will still reject messages if alignment is broken.

If you’re managing sender infrastructure across subdomains, validating email domains before sending is essential. You can check individual addresses for validity and alignment using a reliable email verification tool before sending to catch these issues early. MailTester’s email checker validates both syntax and delivery readiness, including detecting catch-all addresses or domains with conflicting records—helping you spot potential DMARC misalignment risks before they impact deliverability.

What happens when a subdomain sends email but has no explicit DMARC record?

If a subdomain sends email without a DMARC record, mail servers still evaluate DMARC policy based on the parent domain’s record — not the subdomain’s. If the parent domain has no DMARC policy or a permissive one (like p=none or p=quarantine), email from the subdomain may pass DMARC checks even if it’s not properly authenticated. This creates a blind spot that attackers can exploit to spoof mail using your subdomain, especially if SPF and DKIM are not properly configured.

Why inherited policies can create a security gap

DMARC doesn’t work on a per-domain basis; it’s evaluated hierarchically. When a subdomain sends mail, the receiving server checks the parent domain’s DMARC record — even if the subdomain itself has none. If your example.com domain has a p=none, any subdomain like newsletter.example.com inherits that same policy. That means even if the subdomain’s email fails authentication, the receiving server won’t reject it. It might just log it as “pass” or “neutral”.

Let’s say you set up a marketing tool that sends from [email protected]. If that subdomain has no DMARC record, and yourcompany.com also has no DMARC or a p=none policy, the message will likely pass DMARC checks. That’s where spoofing risks creep in. Attackers might forge emails from [email protected] and slip through undetected.

How to close this gap without overcomplicating DNS

You don’t need a DMARC record on every subdomain. But you do need to ensure the parent domain’s policy is enforced, especially for subdomains that send email. Use p=reject at the parent level only if you have strict SPF and DKIM alignment in place across all senders.

For teams managing multiple subdomains — say, for newsletters, support, or third-party tools — use tools that verify both DNS and email deliverability. MailTester’s bulk verification checks whether addresses are valid and aligned with domain policies, revealing potential issues before you send. It helps catch cases where a subdomain sends mail without proper authentication, even if the parent has a DMARC record.

According to the DMARC specification (RFC 7483), policies are inherited from the parent domain unless explicitly overridden. That makes oversight crucial. Never assume a subdomain is safe just because it’s part of your domain. Verify the actual path of email delivery, including alignment with SPF and DKIM — and use real verification tools to test inbox placement and policy enforcement.

Is it safe to use wildcard records for SPF or DKIM configuration?

Using wildcard records for SPF or DKIM is generally unsafe—it can unintentionally authorize any subdomain to send emails on your behalf, breaking your authentication chain and weakening DMARC enforcement. This risk undermines your domain’s credibility and increases the chance of spoofing, even if you think you’re only targeting trusted subdomains.

Wildcard SPF: A hidden backdoor

Imagine an SPF record like include:*.example.com. At face value, it seems practical—onboard new teams by just adding a subdomain. But it means any subdomain, even harmless.nope.example.com, inherits full SPF permission to send for example.com. This is not just theoretical. The IETF’s RFC 7208 explicitly warns against overly permissive includes, particularly wildcards, because they can bypass sender verification. If a subdomain is compromised or misconfigured, that opens a direct path to deliverability failure or abuse.

Let’s say someone creates a subdomain like newsletter.123456789.example.com and sends spam using your SPF allowance. DMARC will see the email as authenticated, so it won’t block it—unless you’re using strict policies. But even then, the damage can already be done. That’s why DMARC record inheritance issues often stem from wildcards: they create unintended trust paths.

DKIM and the same problem

DKIM works similarly: if you set up a wildcard selector like *.example.com in your DNS, any subdomain can publish a DKIM key that passes verification for your domain. If one key is lost or leaked—say, from a forgotten test environment—it’s another vector for spoofing. This isn’t just a hypothetical. According to data from Spamhaus, misconfigured DKIM records (including wildcards) have been linked to a significant portion of reported phishing campaigns.

Even if you control all subdomains, using wildcards reduces your ability to audit and revoke access on a per-subdomain basis. It’s a single point of failure with wide implications. You gain convenience at the cost of control.

Instead of wildcards, use explicit records for each intended sender. If you must use includes, do so with strict, non-wildcard subdomain references. And always monitor your domain reputation with tools that test real inbox placement, not just syntax.

Use our inbox placement reports to check how email from your domain lands in real inboxes, including whether authentication failures are blocking delivery.

How to test if a subdomain is correctly inheriting or overriding DMARC?

You can test DMARC inheritance by checking DNS records at both the parent domain and subdomain levels using tools like MxToolbox or dig. If a subdomain has its own DMARC record, it should override the parent’s; if not, it inherits the parent’s policy. Confirm alignment by sending test emails and reviewing DMARC aggregate reports (RUA) for discrepancies. You’re not just guessing — you’re validating real behavior.

Check DNS records at both levels

  • Use MxToolbox or your terminal’s dig command to query the DMARC record at the parent domain (e.g., _dmarc.example.com).
  • Repeat the query for the subdomain (e.g., _dmarc.reports.example.com).
  • If the subdomain record returns nothing, it’s inheriting the parent’s DMARC policy. If it returns a record, it’s overriding the parent.
  • Check for wildcard records (e.g., *.example.com) that might silently inherit policies without explicit configuration.

Validate actual delivery behavior and reporting

  • Send test emails from the subdomain to major providers (Gmail, Outlook, Yahoo) and monitor the delivery results.
  • Review DMARC aggregate reports sent to the RUA address (typically in rua tag). Look for mismatches between the From domain and the SPF or DKIM signing domains in the report.
  • If the subdomain fails alignment checks — even after setting up a DMARC record — it could mean SPF or DKIM aren’t configured correctly, or the record isn’t being applied.
  • Let’s not assume. You need to verify real-world outcomes. Use tools that test delivery to real mailboxes — like MailTester’s inbox placement tester — to see if your emails land in the inbox or get quarantined.
  • Monitor RUA reports daily for a few days. If errors persist, audit SPF and DKIM records for the subdomain. A common issue is misaligned SPF or DKIM mechanisms causing failure even with correct DMARC policy.
DMARC is only as effective as the underlying SPF and DKIM alignment. A correct policy on a subdomain won’t help if SPF fails to verify the sending domain.

Wildcard records can obscure issues. If you’ve set *.example.com as a catch-all, be cautious: it may apply DMARC policies to unintended subdomains. Always verify the exact configuration using DNS lookup tools. And remember: a DMARC record at the parent level doesn’t guarantee subdomain compliance — unless you explicitly test it.

What DMARC policy should be applied to subdomains with mail-sending roles?

You should apply a DMARC policy of p=quarantine or p=reject to every subdomain that sends email. DMARC policies do not inherit through wildcard DNS records. Relying on wildcards leads to inconsistent enforcement and opens your domain to abuse. Always set explicit DMARC records for known sending subdomains, and avoid using wildcards for any subdomain that sends mail.

Why wildcard DNS records break DMARC inheritance

Wildcard DNS records (like *.example.com) apply a single policy to all subdomains, including those never intended to send email. If your DMARC policy is set at the root domain, a wildcard can inadvertently extend that policy to subdomains that shouldn’t be governed by it. This creates blind spots in authentication enforcement and can allow spoofing from unauthorized sources.

For example, a subdomain like dev.example.com or staging.example.com may be used only for testing or internal tools. But if a wildcard applies a permissive DMARC policy, those subdomains could be exploited to send phishing emails without detection.

As outlined in RFC 7483 (the DMARC specification), policy application is based on the subdomain being explicitly defined in DNS. Wildcards bypass this. You can verify this behavior using tools like MXToolbox or the official DMARC RFC.

What to do instead of relying on wildcards

  • Define explicit DMARC records for every subdomain that sends email (e.g., mail.example.com or newsletter.example.com).
  • Use p=quarantine for subdomains where you want to flag potentially unauthorized mail, or p=reject if you require strict enforcement.
  • If wildcards are unavoidable, ensure they only apply to non-sending subdomains (e.g., dev.*, test.*, staging.*).
  • Regularly audit your DNS records to detect unintended wildcard propagation and remove them where they conflict with sending infrastructure.
  • Test your configuration using tools like MailTester’s inbox placement tester to validate delivery and DMARC compliance across real inboxes.
DMARC policies apply at the domain level — but only when explicitly defined. Wildcards blur that boundary and weaken email security.

You can prevent DMARC-related delivery failures by validating every sending source—especially subdomains—with real-time checks, testing inbox placement from those subdomains, and bulk-verifying your list to catch spoofed or disposable addresses. This stops sends from violating DMARC policies before they go out.

Verify individual sources before sending

  • Use the real-time verification API to check each sender’s address and subdomain alignment in real time—before any email is sent.
  • Check if a subdomain’s DNS configuration (like SPF or DKIM) is correctly set, and detect if a wildcard record is allowing unintended inclusions that confuse DMARC enforcement.
  • Confirm whether the sender’s domain has a valid, properly aligned DMARC policy, or if it’s being misused due to incomplete configurations.

Test inbox placement from subdomains

  • Run inbox-placement tests from the same subdomains you plan to send from—using the inbox tester—to see if they’re blocked, marked as spam, or delayed.
  • DMARC failures often follow from poor authentication or subdomain misconfiguration; these tests surface those red flags early.
  • Compare results across multiple major providers (Gmail, Outlook, Yahoo) to detect inconsistent filtering behavior tied to subdomain policies.

Scan your email list for risky senders

  • Run a bulk verification of your email list to detect disposable domains, role accounts, and addresses spoofing your brand—many of which fail to meet DMARC alignment.
  • Identify subdomains or domains on your list that don’t have valid SPF/DKIM or lack DMARC records, making them vulnerable to bypassing DMARC.
  • Filter out high-risk senders—such as those using temporary or catch-all domains—before sending, reducing bounce rates and reputational risk.

According to RFC 7483, DMARC relies on consistent SPF and DKIM alignment. If a subdomain inherits policies via wildcard DNS but lacks proper authentication, it can fail DMARC checks. This is why you must verify each sender and test deliverability independently.

DMARC enforcement fails when subdomain policies are unclear or misaligned. Verification should happen before sending—not after.

MailTester’s 98.9% accuracy ensures you’re not trusting false positives. You don’t need to manage multiple tools: all checks—from single address validation to bulk list scrubbing—are integrated into a single workflow, with no expiration on purchased credits.

What are the risks of relying on wildcard DNS for subdomains with mail services?

Wildcard DNS records can let anyone send emails from any subdomain of your domain—even if they don’t own it—because the mail server accepts any subdomain as valid. This breaks DMARC alignment, lets spoofers hide in plain sight, and risks your domain’s reputation if untrusted senders abuse it. Check your subdomain email policies before relying on wildcards.

How wildcard DNS undermines email authentication

  • Wildcard DNS records allow any subdomain (e.g., [email protected]) to resolve to your mail server—even if no formal MX or SPF record exists for that subdomain.
  • If your domain doesn’t set strict SPF/DKIM/DMARC policies per subdomain, spammers or misconfigured third-party tools can send emails from fake subdomains and still appear to align with your domain.
  • DMARC reports may show these forged messages as “aligned” because they pass SPF or DKIM checks tied to the parent domain, leading to false positives and hiding real impersonation attempts.
  • This undermines the entire purpose of DMARC, which is to detect and reject unauthorized senders. Without careful subdomain controls, you may unknowingly allow spoofing campaigns to bypass detection.

Why this damages your sender reputation and inbox placement

  • Some email services use wildcards as a red flag. If your subdomain uses a wildcard and sends mail without proper authentication, receiving systems may treat it as high risk—even if you’re sending legimately.
  • If a third-party marketing platform or API uses a wildcard subdomain to send emails on your behalf, their poor sending practices (e.g., high bounce rates, spam complaints) can tarnish your domain’s reputation.
  • Even if your main domain is clean, one poorly managed subdomain with a wildcard can trigger blacklisting or trigger filtering rules that reduce inbox placement across Gmail, Outlook, and other providers.
  • According to Return Path’s deliverability research, consistent authentication failures—even on subdomains—can reduce inbox placement by up to 30% when reputation thresholds are breached.

To catch these issues early, verify your sending infrastructure with tools that test email deliverability across all subdomains. Use MailTester’s inbox placement tester to see where your messages land when sent from subdomains, and spot alignment problems before they harm reputation.

How do you fix a DMARC inheritance problem caused by wildcards?

If your wildcard DNS records apply to sending subdomains, they can cause DMARC policies to inherit from the wrong scope, leading to alignment failures and email rejection. To fix this, remove wildcard records targeting SPF, DKIM, or DMARC for sending subdomains. Instead, define explicit DMARC policies for each subdomain that sends email. Monitor deliverability and alignment across all subdomains using aggregated reports from tools like DMARC analysts or third-party reporting services.

Step-by-step: Fix DMARC inheritance with wildcards

  1. Identify which subdomains send email and check if wildcard records (like *.example.com) are set for SPF, DNSKEY, or DMARC. Wildcards can cause unexpected policy inheritance when subdomains aren’t meant to follow the root domain’s rules.
  2. Remove wildcard records that include sending subdomains from your DNS configuration. For example, delete v=DMARC1; p=none; records at _dmarc.*.example.com if they’re applied across all subdomains but aren’t intended for every sender.
  3. Add explicit DMARC records to each subdomain that sends email. If newsletter.example.com sends marketing mail, set _dmarc.newsletter.example.com with its own policy. This ensures alignment and accurate reporting from that source only.
  4. Verify correct DNS propagation using tools like DNSChecker.org or MxToolbox to confirm changes are live before testing email flow.
  5. Use a central monitoring tool to collect and analyze aggregate DMARC reports (RUA) from all domains and subdomains. Tools like dmarcian.com or Postmark’s DMARC tools help detect misalignment issues early across your infrastructure.

Prevent future issues with proactive validation

Regularly audit your DNS zone files for unintended wildcards—especially when adding new subdomains. Let’s treat each subdomain that sends email as a unique entity, not just a passive recipient of parent-domain policies. You can validate individual addresses or test deliverability ahead of send using MailTester’s inbox placement tester, which checks alignment, SPF/DKIM records, and mailbox delivery in real-time. Use the email checker before sending to catch invalid or risky addresses early.

DMARC inheritance is not a bug—it’s a feature of how DNS and policy evaluation work. But wildcards can turn intended control into unintended failure.

Why does a DMARC policy fail to apply even when set at the domain level?

DMARC policies can fail at the subdomain level because wildcard DNS records may override or mask the domain-level policy. If a subdomain lacks a DMARC record or has a conflicting one, the parent domain's policy may be ignored, leading to inconsistent enforcement and reduced sender reputation. This happens even if the root domain has a strict DMARC policy set.

How wildcard DNS records interfere with DMARC

When you set a wildcard DNS record (like * in your DNS zone), it can silently apply to subdomains that don’t define their own records. If your subdomain doesn't have its own DMARC record but gets a wildcard hit, the email system sees no policy at that level. As a result, even if your root domain enforces DMARC, the subdomain may not be protected — and mail receivers will treat it as unverified.

For example, if you send from [email protected] and support.yourcompany.com has no DMARC record but the wildcard *.yourcompany.com exists, the receiving server may not enforce DMARC at all for that subdomain. This is standard behavior defined in RFC 7483, which outlines how DMARC policies propagate (or fail to propagate) across domains and subdomains.

Subdomain-level misconfigurations break domain-wide security

Even if your primary domain has a strict DMARC policy (like p=reject), any subdomain that either ignores DMARC or declares a permissive policy (p=none) can undermine the entire framework. Receiving servers often apply the most permissive policy in the hierarchy. So if a subdomain allows unauthenticated emails, it can bypass your domain-wide enforcement.

Worse, some bulk email tools or old email systems create subdomains dynamically (like mail123456.yourcompany.com) without a DMARC record. If those are hit by a wildcard, the sender reputation still gets hurt — especially if those subdomains are used for spam. This can make your entire domain look untrustworthy, even if the parent-level DMARC was correct.

Let’s be clear: you can’t rely on a domain-level DMARC record alone. You need to audit every subdomain, especially if wildcards exist. Use a tool like MailTester’s email checker to validate individual addresses and detect potential delivery risks tied to subdomain misconfigurations before they reach your inbox.

Final step: verifying domain and subdomain alignment with real sends

True deliverability only confirms when emails land in inboxes after real-world sends. Use MailTester’s inbox-placement testing to send from your subdomains and observe how receivers handle the message.

Check the real-time report for indicators of DMARC failure—rejections, spam markings, or delays. These signals reveal whether your DMARC record inheritance from the parent domain is effective across subdomains, or if misalignment is blocking delivery.

AI-powered insights for immediate action

  • Use MailTester’s in-app AI assistant to analyze inbox-placement reports.
  • It identifies whether DMARC failure traces back to missing or incorrect SPF/DKIM records on subdomains.
  • The AI suggests precise fixes—like adding subdomain-specific records or adjusting policy enforcement levels.

Sources

Keep reading

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

Frequently asked questions

Can wildcard DNS records cause DMARC to fail?

Yes. Wildcard records can override or inherit misconfigured policies, leading to improper DMARC enforcement across subdomains. This can allow spoofing and lower deliverability.

Should I use wildcards for DMARC records?

No. Wildcards in DMARC records can break alignment and allow unauthorized senders to appear legitimate. Use explicit records for each subdomain that sends email.

How do I know if a subdomain is inheriting the wrong DMARC policy?

Check DNS records at both the domain and subdomain level. Compare the policies. Use DMARC aggregate reports to identify alignment failures.

What is the impact of misconfigured wildcard DNS on email deliverability?

It can cause emails to be marked as spam or rejected due to DMARC failures. It also increases the risk of spoofing attacks and harms sender reputation.

Can MailTester verify if a subdomain’s DMARC record is properly configured?

While MailTester does not test DNS records directly, it can verify individual email addresses used by subdomains and simulate inbox placement to detect DMARC-related delivery issues.

What should I do if my subdomain has no DMARC record but still sends mail?

Add a DMARC record with a policy like `p=quarantine` or `p=reject` to prevent spoofing and maintain alignment. Avoid relying on wildcard inheritance.

Is it safe to use SPF wildcards like include:*.example.com?

No. SPF wildcards allow uncontrolled inclusions of subdomains, which can unintentionally authorize malicious senders and weaken authentication.

How often should I audit my DMARC records?

Audit at least quarterly, especially after adding new subdomains or changing email infrastructure. Use consistent monitoring tools and real email testing.

What happens if a subdomain sends email without proper DMARC alignment?

It may be rejected by receiving servers, marked as spam, or contribute to a poor domain reputation, even if the parent domain has strong DMARC.

How can I test DMARC policy enforcement without sending real email?

Use DNS lookup tools and third-party validators. For real-world accuracy, test with inbox-placement tools like MailTester that simulate delivery.

Does a wildcard DNS record override DMARC records?

A wildcard DNS record does not directly override DMARC, but it can interfere with policy application by causing unexpected inheritance or misalignment.

Can a subdomain with no DMARC record still pass DMARC checks?

Only if the parent domain has a permissive DMARC policy. But this reduces security and increases risk of spoofing. Explicit policies are required.