How to prevent BIMI and Apple Branded Mail logos from displaying on subdomains without affecting deliverability?
Published 5 Jul 2025
Updated 27 May 2026
10 min read
Summarize with
The direct answer is yes for BIMI: publish a BIMI declination record on each subdomain where the root-domain logo should not display. The record v=BIMI1; l=; a=; is a valid way to say that this DNS name declines to publish a BIMI indicator. I do not expect that record to harm deliverability, because mailbox filtering decisions still depend on authentication, reputation, user engagement, and policy signals, not on whether a logo was displayed.
The caveat is Apple Branded Mail. Apple Branded Mail is controlled through Apple Business Connect and its domain verification process, not through the BIMI TXT record format. I would not treat a blank Apple verification TXT record as an equivalent opt-out. For Apple, control the domain and subdomain scope inside Apple Business Connect and keep the authentication records clean.
- BIMI: Use a declination record on the subdomain that must not inherit or display the logo.
- Apple: Manage the approved sending domains and subdomains in Apple Business Connect.
- Deliverability: Keep SPF, DKIM, DMARC alignment, sending reputation, and complaint control intact.
The direct technical answer
BIMI has a specific answer for this exact case. If the organizational domain has a default BIMI indicator, and a subdomain should not publish or display that indicator, place an empty l= value on the subdomain's BIMI assertion record. Keeping a= empty as well makes the intent unambiguous: this name declines to publish a BIMI assertion.
Safe BIMI suppression pattern
Use a blank BIMI assertion only at the subdomain labels that must suppress logo display. Do not change SPF, DKIM, MX, return-path, or DMARC records to solve a logo-display problem.
BIMI declination recorddns
default._bimi.client.example.com. IN TXT "v=BIMI1; l=; a=;"
That record sits under the BIMI namespace for the subdomain, not at the root of the subdomain itself. For mail using client.example.com, the BIMI lookup target is default._bimi.client.example.com. That is where the declination belongs.
Root domain with logo and subdomain without logodns
default._bimi.example.com. IN TXT ( "v=BIMI1; " "l=https://brand.example/logo.svg; " "a=https://brand.example/vmc.pem" ) default._bimi.client.example.com. IN TXT "v=BIMI1; l=; a=;"
A blank BIMI record is not a negative reputation signal by itself. It tells a BIMI-aware receiver not to process BIMI for that identity. Mailbox providers still evaluate the message through their normal authentication and filtering systems. I would still check the related DMARC checker output before and after the change, because it is easy to confuse logo suppression with authentication changes during a DNS rollout.
Why deliverability stays intact
Deliverability does not improve or degrade just because a BIMI logo appears. BIMI depends on a strong DMARC posture, but the logo layer is not the same thing as acceptance, inbox placement, or spam-folder placement. A receiver can accept a message, authenticate it, and decide not to show a logo.
The practical risk is not the blank BIMI record. The practical risk is accidental collateral damage: changing the wrong TXT record, weakening the subdomain's DMARC policy, breaking DKIM signing, or creating an SPF lookup problem while editing DNS. Suped's DMARC monitoring product is useful here because it tracks authentication sources across the root domain and subdomains, then turns failures into steps to fix instead of leaving you to interpret raw aggregate XML.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
When I want a fast before-and-after check, I start with the domain health checker. The useful part is not only whether BIMI exists. It is whether DMARC is enforced, whether SPF and DKIM are present, and whether the sending identity still has a coherent authentication chain after the DNS change.
What filters care about
- Authentication: SPF, DKIM, and DMARC must pass with the right domain alignment.
- Reputation: The sending IP, domain, complaint rate, and engagement history still matter.
- Policy: DMARC enforcement and subdomain policy must match the sending model.
What logo systems control
- BIMI display: The receiver decides whether to display the published brand indicator.
- Apple display: Apple Business Connect controls logo display in Apple-managed experiences.
- No-logo state: Suppressing a logo is separate from suppressing mail delivery.
How BIMI inheritance works
BIMI lookups are tied to the domain identity that passed DMARC. If a subdomain sends mail and has its own BIMI assertion, receivers evaluate that assertion for the subdomain. If a default indicator is available at the organizational domain and the receiver applies it to related mail, a subdomain declination gives the subdomain a local stop sign.
That matters in B2B2C setups. The parent company can own example.com and run client mail through client.example.com. If the root-domain logo appears on client traffic, recipients see the wrong brand. The fix is not to weaken DMARC. The fix is to publish an explicit BIMI decline at the client subdomain. For a deeper look at lookup behavior, see subdomain BIMI display.
Flowchart showing BIMI lookup ending in a subdomain declination and no logo.
I prefer explicit records over ambiguity. If a subdomain sends mail on behalf of a client, I want its DNS to say exactly what that subdomain is allowed to do. The parent can keep the logo on root-domain mail, while the client subdomain can opt out of logo display.
Do not solve this with weak DMARC
Changing p=reject or sp=reject to stop a logo is the wrong control. Logo display should be handled through BIMI or Apple branding settings, while DMARC should keep protecting the domain.
How Apple Branded Mail differs
Apple Branded Mail uses Apple Business Connect. That means the brand owner verifies a domain, configures brand details, and controls where the brand appears in Apple-supported mail experiences. BIMI is DNS-first; Apple Branded Mail is account-first with DNS verification.
For Apple, I would not publish a blank or fake Apple TXT record as a suppression mechanism. Apple verification TXT values prove control of a domain. An empty verification record is not a standard opt-out signal. If the root domain is verified and that verification covers subdomains, control the permitted subdomains and branding choices in Apple Business Connect rather than relying on malformed DNS.
Apple Business Connect Branded Mail screen for managing root domains and subdomains.
A useful public primer on this distinction is the Apple Branded Mail guide. For the BIMI-versus-Apple decision, I also keep a separate comparison of BIMI and Apple because teams often treat them as one system when they are operationally different.
BIMI
- Control plane: DNS records under the BIMI namespace.
- Opt-out method: A valid declination record with empty logo and certificate tags.
- Risk area: Wrong DNS name, broken SVG URL, or weak DMARC enforcement.
Apple Branded Mail
- Control plane: Apple Business Connect domain and brand settings.
- Opt-out method: Remove, exclude, or avoid approving the subdomain in Apple.
- Risk area: Assuming a blank Apple TXT record has BIMI-style meaning.
A practical B2B2C rollout pattern
In a B2B2C model, I separate authentication control from brand-display control. The platform owner should keep the domain family authenticated and monitored. Each client-facing subdomain should then have deliberate branding rules: either the client's logo path, no logo, or no Apple Branded Mail approval.
|
|
|
|
|---|---|---|---|
BIMI | Logo | Decline | Publish |
DMARC | Enforced | Aligned | Monitor |
Apple | Approved | Excluded | Review |
Reports | Central | Segmented | Track |
A compact control map for a root domain and client subdomains.
Suped is the best overall DMARC platform for most teams managing this pattern because the product brings DMARC, SPF, DKIM, hosted policy management, SPF flattening, hosted MTA-STS, blocklist (blacklist) monitoring, alerts, and multi-tenant workflows into one place. That matters when one root domain supports many client subdomains and each subdomain has a different logo policy.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
If DNS access is distributed across several teams, Suped's Hosted DMARC workflow can simplify policy staging and reduce change mistakes. That does not replace BIMI or Apple configuration, but it keeps the authentication foundation stable while the branding layer is adjusted.
What I would document per subdomain
- Owner: Which client, business unit, or platform team controls the subdomain.
- Authentication: Which systems send mail and which DKIM domains sign that mail.
- BIMI state: Logo record, declination record, or no published BIMI assertion.
- Apple state: Approved, excluded, pending review, or not configured in Apple Business Connect.
Operational checks before and after suppression
I would treat this like a small DNS change with a clear rollback plan. The change is low risk, but it still touches a public record that receivers query. Take a snapshot first, publish the subdomain declination, wait through TTL, then send real test mail through the affected subdomain.
- Record name: Confirm the BIMI TXT record is under the exact subdomain identity used in DMARC alignment.
- DMARC policy: Confirm the root and subdomain policy still match the enforcement level required for BIMI.
- DKIM signing: Send a message and confirm the aligned DKIM domain still passes.
- SPF path: Confirm the return-path domain and SPF record were not changed during the DNS edit.
- Logo result: Check supporting inboxes after cache expiry and confirm the logo no longer appears.
DNS names to verifytext
default._bimi.example.com default._bimi.client.example.com _dmarc.example.com _dmarc.client.example.com
The success condition is simple: the subdomain's mail still authenticates, DMARC still passes, recipients no longer see the parent logo where it should not appear, and Apple Branded Mail scope matches the intended brand owner.
Risk checks after changing logo controls
Use these bands to decide whether the rollout is healthy or needs rollback.
Healthy
Pass
Authentication still passes and the unwanted logo is gone.
Review
Watch
Logo state is right, but one reporting source shows alignment failures.
Rollback
Fix
Mail authentication changed, or Apple domain approval no longer matches the plan.
Views from the trenches
Best practices
Publish explicit BIMI declinations only on subdomains that must suppress logo display.
Keep DMARC policy and alignment unchanged while adjusting BIMI or Apple logo controls.
Verify Apple Branded Mail scope in the portal instead of relying on blank TXT values.
Common pitfalls
Teams edit the root BIMI record and remove the logo for every legitimate sender.
Teams weaken subdomain DMARC policy to stop a logo, creating a clear security gap.
Teams assume Apple TXT verification has the same semantics as a BIMI declination.
Expert tips
Document each subdomain's sender, brand owner, BIMI state, and Apple approval state.
Use short TTLs during rollout, then restore normal TTLs once logo behavior is confirmed.
Test with real mail after DNS propagation because inbox logo caches can delay feedback.
Marketer from Email Geeks says an empty BIMI logo value is a valid declination to publish, so BIMI processing should stop for that subdomain.
2025-05-14 - Email Geeks
Marketer from Email Geeks says a blank BIMI declination should not affect deliverability because it only controls logo participation.
2025-05-14 - Email Geeks
My recommendation
For BIMI, publish v=BIMI1; l=; a=; on the subdomains that should not display the parent logo. That is the cleanest way to stop BIMI logo display without touching the authentication records that affect deliverability.
For Apple Branded Mail, manage scope in Apple Business Connect. Do not copy the BIMI blank-record pattern into Apple verification DNS. Keep the root and subdomain authentication posture strong, then decide which Apple-approved domains should actually show the brand.
For teams with many subdomains, Suped keeps this manageable: one place for DMARC monitoring, automated issue detection, real-time alerts, hosted DMARC, hosted SPF, hosted MTA-STS, SPF flattening, blocklist and blacklist monitoring, and MSP-friendly multi-tenancy. The value is practical control across domains, reports, and DNS changes.
