BIMI on Subdomains: Your `sp` DMARC Policy Is Breaking Your Logo

You did everything right. You got your domain to DMARC `p=reject`. You published a valid BIMI record with your SVG logo hosted correctly. You even have the required Verified Mark Certificate (VMC). You send a test from your primary domain, `you@corp.com`, and there it is: your beautiful logo, right in the inbox. Victory.

Then, your marketing team sends a campaign from `newsletter@marketing.corp.com`. The logo is gone. A support ticket is sent from `help@support.corp.com`. No logo there either. What happened? You have `p=reject` at the organizational level. Shouldn't that cover everything?

It should, but it doesn't. You've just stumbled into one of the most misunderstood corners of DMARC: subdomain policy inheritance and its critical, logo-breaking interaction with the `sp=` tag.

DMARC Inheritance Isn't Simple 'Trickle-Down'

The core assumption many admins make is that a DMARC policy set on an apex domain (`corp.com`) automatically applies in full to all its subdomains (`marketing.corp.com`, `billing.corp.com`, etc.). This is only partially true, and that missing part is where BIMI deployments go wrong.

RFC 7489, which defines DMARC, establishes a clear mechanism for inheritance. If a subdomain does not have its own explicit DMARC TXT record, a receiving mail server will look to the parent domain for instructions. This is where the `p=` and `sp=` tags diverge in their roles.

The `p=` and `sp=` Tags: A Tale of Two Policies

The `p=` tag (policy) is the most familiar. It declares the action—`none`, `quarantine`, or `reject`—that should be taken on mail claiming to be from the *organizational domain itself* if it fails DMARC checks. For a record at `_dmarc.corp.com`, the `p=` tag applies to mail from `@corp.com`.

The `sp=` tag (subdomain policy) is different. It's an optional tag that declares the action to be taken for mail from any *subdomain* of the organizational domain if that subdomain does not have its own explicit DMARC policy. This tag, when present in the `_dmarc.corp.com` record, acts as the default for all subdomains below it.

Here's the critical distinction: If the `sp=` tag is present, it is the *only* policy inherited by subdomains. The parent's `p=` tag is ignored for subdomain evaluation. If the `sp=` tag is *absent*, then and only then do subdomains inherit the parent's `p=` policy. This single point of logic is the root of the problem.

Anatomy of a Silent BIMI Failure

Let's walk through the exact failure scenario. It’s a common configuration, especially for organizations that have been progressively rolling out DMARC over time. You have a strong parent policy, but you've left a door open on a subdomain, likely for a third-party sender you haven't fully aligned yet.

The 'Safe' Subdomain Policy

Imagine your IT team has worked hard to get `corp.com` to full enforcement. The DNS record is a thing of beauty:

_dmarc.corp.com. IN TXT "v=DMARC1; p=reject; rua=mailto:agg@dmarc.corp.com;"

Meanwhile, the marketing department uses a third-party platform that sends from `marketing.corp.com`. During the initial setup, to avoid blocking legitimate mail while getting SPF and DKIM sorted, an admin placed a monitoring-only policy on that specific subdomain:

_dmarc.marketing.corp.com. IN TXT "v=DMARC1; p=none; rua=mailto:mktg-agg@dmarc.corp.com;"

This seems logical. You're protecting the main domain while safely observing the marketing subdomain. But when the BIMI rollout happens, this creates a direct conflict. The mailbox provider sees an email with a `From:` header of `newsletter@marketing.corp.com`. It performs a DMARC lookup for that domain. It finds the explicit `p=none` record. The `p=reject` policy on the parent `corp.com` is never even checked, because the subdomain has its own policy. BIMI requires enforcement (`quarantine` or `reject`). Since the effective policy is `none`, the BIMI check fails. No logo.

Why Mailbox Providers Are So Strict About This

This isn't a bug or an oversight by Gmail, Yahoo, or other mailbox providers. It's a deliberate and necessary security evaluation. The BIMI standard is built on the foundation of DMARC enforcement. The logo is a reward for proving you have control over your domain's email ecosystem and are actively preventing spoofing.

The evaluation must be performed on the *effective policy* of the domain found in the `From:` header. This is the domain the end-user sees, and it's the identity the logo is meant to vouch for. Allowing a subdomain with a `p=none` policy to display a BIMI logo would undermine the entire system. It would create a scenario where an unmonitored, unprotected subdomain could trade on the reputation of its secure parent, creating a new vector for brand impersonation.

Authentication-Results: mx.example.com; dmarc=none (p=none sp=NULL dis=none) header.from=marketing.corp.com — A familiar sight in failure analysis

A receiving MTA doesn't make assumptions. It follows a simple algorithm: look up the DMARC record for the `From:` header domain. If it exists, use that policy. If it doesn't, look up the parent domain. If the parent has an `sp=` tag, use that. If it has no `sp=` tag, use its `p=` tag. The result of this algorithm is the domain's 'effective policy.' For BIMI to pass, that final effective policy must be `p=quarantine` or `p=reject`.

The Fix: Asserting Control Across Your Namespace

Fixing this issue requires you to stop thinking of DMARC as a single record and start seeing it as a policy framework governing your entire domain hierarchy. You have two primary paths to a BIMI-compliant configuration: the blanket approach and the granular approach.

Option 1: The `sp=reject` Blanket Policy

The most powerful and straightforward fix is to add `sp=reject` (or `sp=quarantine`) to your parent domain's DMARC record. This is the ultimate statement of control.

Your record at `_dmarc.corp.com` would change to: `v=DMARC1; p=reject; sp=reject; rua=...`

With this in place, any subdomain that does not have its own DMARC record automatically inherits `reject`. Now, when mail comes from `new-project.corp.com` (which has no DMARC record), receivers will find no local policy, look up to `corp.com`, see the `sp=reject` tag, and apply it. This makes the subdomain instantly BIMI-eligible, assuming its SPF/DKIM is aligned. It also has the massive security benefit of preventing unsanctioned mail from any unused subdomain.

Option 2: Explicit Per-Subdomain Policies

In some large, decentralized organizations, a blanket `sp=reject` might be too risky. Perhaps you have legacy services or third-party vendors tied to specific subdomains that you can't immediately bring into alignment. In this case, you must manage policies granularly.

This means leaving your parent domain's DMARC record as is (or even setting `sp=none` to be explicit) and then creating an individual DMARC record for every single subdomain that sends mail and requires a BIMI logo.

For `marketing.corp.com`, you'd change its record to: `_dmarc.marketing.corp.com. IN TXT "v=DMARC1; p=reject; rua=..."`. For `support.corp.com`, you'd add: `_dmarc.support.corp.com. IN TXT "v=DMARC1; p=quarantine; pct=100; rua=..."`. This is more work and requires meticulous DNS hygiene, but it provides pinpoint control without affecting other parts of your namespace.

Playbook: Auditing Your Domain Hierarchy for BIMI

You can't secure what you can't see. Before you can deploy a fix, you need a complete map of your domain landscape and their effective DMARC policies. This isn't a one-time task; it's an ongoing security process.

Discover Your Subdomains

First, build a comprehensive list of your subdomains. Don't just rely on your primary DNS zone file. You need to find subdomains that might have been created elsewhere. Use Certificate Transparency logs, which record all publicly trusted SSL/TLS certificates issued for your domain and its subdomains. Supplement this with passive DNS databases and bruteforce enumeration tools. The goal is to cast the widest net possible.

Query and Evaluate Policies

With your list in hand, you need to script an audit. For each subdomain, perform a DNS query for a TXT record at `_dmarc.subdomain.corp.com`. If a record is found, parse the `p=` tag. That's its policy. If no record is found (an `NXDOMAIN` or `NOERROR` with no answer), you must then query the parent domain's DMARC record at `_dmarc.corp.com`.

Once you have the parent record, check for an `sp=` tag. If it exists, its value is the subdomain's effective policy. If it does not exist, the parent's `p=` tag value is the effective policy. You must automate this logic to get an accurate picture.

Categorize and Prioritize

The final step is to correlate this DMARC policy data with your knowledge of which subdomains actually send email. Group your subdomains into three buckets: known senders, known non-senders, and unknown/unauthorized. For every 'known sender' that needs a BIMI logo, verify its effective policy is `quarantine` or `reject`. If it's not, you've found your next task.

The takeaway

The disappearing BIMI logo isn't a glitch; it's a symptom of a DMARC policy that's only half-implemented. Treating subdomains as an afterthought is a common but dangerous blind spot. The `sp=` tag isn't just a minor setting—it's the lever that determines whether your domain security policy is a fortress or a fence with a gate left wide open.

True brand protection and email security require a holistic view. You must look beyond the apex domain and manage the policy of your entire namespace as a single, cohesive system. Auditing your subdomain hierarchy isn't just for BIMI; it's fundamental security hygiene. Platforms like MailSleuth.AI can automate this discovery and evaluation process, turning a week of scripting and manual lookups into a continuous, actionable security dashboard.