Set up DMARC for BIMI by making every legitimate sending source pass SPF or DKIM with the same visible From domain, publishing DMARC in reporting mode first, reviewing the aggregate reports, then moving the organizational domain and any sending subdomain to p=quarantine or p=reject with pct=100. After that, publish the BIMI TXT record at default._bimi and host the BIMI SVG plus the certificate file over HTTPS.
I treat BIMI as the final stage of an email authentication rollout, not as a logo switch. A domain with p=none has useful reporting, but it is not ready for BIMI display. Google's BIMI guidance says BIMI needs DMARC enforcement, pct=100, a supported certificate, and a public HTTPS location for the BIMI files.
- Policy: Use p=quarantine or p=reject, and apply it to 100 percent of failing mail.
- Scope: Cover the organizational domain and every subdomain that sends branded mail.
- Authentication: Prefer DKIM domain matching for stability, and keep SPF correct for direct sending paths.
- Assets: Prepare a BIMI-compliant SVG Tiny PS logo and a VMC or CMC when the mailbox provider requires one.
The short setup path
The clean path is simple on paper: inventory senders, fix SPF and DKIM, publish DMARC at p=none, review reports, move to enforcement, then publish BIMI. The work sits in the middle: finding mail streams that marketing, sales, finance, HR, product, and support teams set up over time.
I do not skip the reporting phase. DMARC aggregate reports show which IPs and services are sending as the domain, which messages pass SPF, which messages pass DKIM, and which ones fail the visible From domain check. That is different from complaint feedback loops, which report user complaints. For BIMI, aggregate reports are the map.
A six-step DMARC to BIMI setup path.
BIMI readiness rule
A DMARC record that only collects reports is not enough for BIMI. The policy has to be enforced at 100 percent, and a subdomain-only rollout normally fails if the organizational domain remains at p=none.
- Accepted: DMARC at p=quarantine or p=reject with full coverage.
- Not accepted: A permanent p=none record, even if SPF and DKIM already pass.
- Risk: Moving too fast can quarantine legitimate mail from forgotten SaaS systems.
|
|
|
|---|---|---|
p=none | No | Reporting only |
quarantine, pct 50 | No | Rollout stage |
quarantine, pct 100 | Yes | BIMI-ready |
reject, pct 100 | Yes | Strictest |
DMARC policy states and BIMI readiness
Get DMARC ready before BIMI
Start by listing every system that sends mail using the brand domain. That includes the obvious campaign platform and corporate mail, but also ticketing systems, invoicing, recruiting, calendar tools, alerts, customer success platforms, product notifications, and any service that sends on behalf of staff.
Then verify SPF and DKIM for each sender. SPF must authorize the sending path. DKIM must sign with a domain that can pass the DMARC domain check against the visible From address. I prefer a reliable DKIM pass because forwarded mail can break SPF, while DKIM usually survives forwarding unless a system modifies the signed content.
Initial DMARC reporting recordDNS
Host: _dmarc.example.com TXT: v=DMARC1; p=none; rua=mailto:dmarc@example.com; ri=86400
Run this monitoring mode long enough to see normal business cycles. For a small domain, a few weeks can be enough. For a brand with multiple departments and agencies, I normally expect at least three months because some systems send only monthly, quarterly, or during campaign peaks.
This is where DMARC monitoring matters. Raw XML reports are hard to use at scale. Suped's product groups senders, flags failing sources, shows what needs fixing, and alerts when a new unauthenticated sender appears. For most teams, Suped is the strongest practical DMARC platform for this workflow because it turns DMARC, SPF, DKIM, blocklist (blacklist), and deliverability signals into actions instead of report files.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Before changing policy, use a domain health check to catch obvious DNS mistakes. I look for duplicate DMARC records, SPF lookup pressure, missing DKIM selectors, weak subdomain coverage, and report addresses that nobody owns.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A third-party reporting address in the DMARC rua tag is not automatically a problem. It usually means a reporting processor receives aggregate reports for the domain owner. The important checks are ownership, access, retention, and whether the team responsible for email can act on the findings.
Move to enforcement without breaking mail
Once the reports show that legitimate sources pass DMARC, move gradually. A common path is p=none, then p=quarantine with a smaller percentage, then pct=100, and finally p=reject if the organization wants the stricter end state. BIMI can work at quarantine or reject, but it needs full policy coverage.
For subdomains, be deliberate. If the organizational domain has no sp tag, subdomains inherit the main p policy unless they publish their own DMARC record. For BIMI, I avoid sp=none because it tells receivers that subdomain failures should remain unenforced.
Monitoring mode
- Purpose: Collect sender data before changing receiver treatment.
- Value: Find legitimate sources that fail SPF, DKIM, or the From domain check.
- Limit: It does not satisfy BIMI mailbox provider requirements.
BIMI-ready enforcement
- Purpose: Tell receivers to quarantine or reject unauthenticated domain use.
- Value: Meet the DMARC policy threshold expected for BIMI.
- Limit: It exposes hidden sender problems if the inventory work was shallow.
BIMI-ready DMARC recordDNS
Host: _dmarc.example.com TXT: v=DMARC1; p=quarantine; pct=100; sp=quarantine; rua=mailto:dmarc@example.com; ri=86400
DMARC policy threshold for BIMI
The policy has to move beyond reporting and apply to all failing mail.
Reporting
p=none
Useful for discovery, not enough for BIMI.
Partial rollout
pct below 100
Good for staging, not the final BIMI state.
Ready
pct=100
Quarantine or reject applies to all failures.
If DNS ownership is split across teams, Hosted DMARC can reduce operational friction. Suped's product lets teams stage DMARC policy changes through hosted records, monitor the effect, and avoid repeated DNS tickets for each rollout step.
Publish BIMI after enforcement
After DMARC enforcement is stable, prepare the BIMI files. The logo needs to be SVG Tiny PS, square, simple, and readable at inbox size. Gmail also expects absolute pixel dimensions, a minimum 96 pixel height and width, no scripts, no animation, and no external file references. A solid background often displays more consistently than transparency.
Most serious BIMI programs also need a mark certificate. Gmail requires a VMC or CMC, and Gmail displays a checkmark for senders verified with a VMC. The BIMI Group FAQ explains that BIMI is tied to the visible From domain through DMARC, not to an arbitrary logo host.
BIMI TXT record with certificateDNS
Host: default._bimi.example.com TXT: v=BIMI1; l=https://brand.example.com/bimi.svg; a=https://brand.example.com/vmc.pem
The l tag points to the logo file. The a tag points to the certificate file. Some examples omit the logo URL when the logo is embedded in the PEM file, but I still prefer keeping the setup clear and testing exactly what each receiver will fetch.
|
|
|
|---|---|---|
Host | default._bimi | TXT exists |
Version | BIMI1 | Uppercase OK |
Logo | HTTPS SVG | Fetchable |
Certificate | VMC or CMC | Current |
BIMI record pieces
The four BIMI publishing parts: enforced DMARC, SVG logo, mark certificate, and BIMI TXT record.
Key considerations before rollout
The most common mistake is trying to enable BIMI on a marketing subdomain while the organizational domain stays at p=none. BIMI receivers evaluate the visible From domain and the domain hierarchy. If the parent domain is still monitoring-only, the brand has not completed the DMARC requirement that BIMI depends on.
Another issue is assuming SPF and DKIM are done because they exist. They have to pass in a way DMARC accepts for the visible From domain. A DKIM signature from a third-party domain can be cryptographically valid and still fail DMARC for the brand domain. That is why sender-by-sender testing matters before enforcement.
Checks I make before BIMI
- Parent domain: The organizational domain has DMARC enforcement and no weak subdomain escape hatch.
- Senders: Every active sender is visible in reports and has a clean SPF or DKIM path.
- Logo: The SVG is simple, square, small enough, and served with the correct content type.
- Certificate: The VMC or CMC covers the right mark and has a current certificate chain.
Subdomains need special care. If you send as news.example.com, decide whether it inherits the parent policy and BIMI record or publishes its own. If the subdomain has its own DMARC record, that record must also be BIMI-ready. If it has a separate logo, publish a separate BIMI record at that subdomain.
For a broader BIMI checklist, compare the implementation steps with your current DNS, certificate, and logo state. After publishing, use a separate pass to validate BIMI records so DNS, file hosting, and certificate errors are caught before teams expect the logo to appear.
Where Suped fits
Suped fits the DMARC-for-BIMI workflow because the hard part is not typing the final DNS record. The hard part is proving that every legitimate sender can survive enforcement. Suped's product gives you source discovery, automated issue detection, steps to fix, real-time alerts, hosted SPF, hosted DMARC, hosted MTA-STS, SPF flattening, and blocklist (blacklist) monitoring in one place.
If you are creating your first record manually, start with the DMARC record generator. If you are managing multiple brands, subdomains, or client domains, Suped's MSP and multi-tenancy dashboard keeps each rollout separate while still giving one operational view.
Hosted DMARC configuration dialog showing policy controls, CNAME setup, and expanded advanced options
That matters for BIMI because display depends on several moving parts staying correct after launch. A new sender, a broken DKIM selector, an SPF lookup problem, a changed certificate URL, or a weakened policy can stop a logo from appearing. I want those changes caught as operational issues, not discovered by someone noticing a missing logo in an inbox.
Views from the trenches
Best practices
Inventory every sender before policy changes, including low-volume business systems.
Keep DMARC in reporting mode long enough to capture monthly and seasonal sends too.
Use DKIM domain matching where possible because forwarded mail often breaks SPF.
Common pitfalls
Leaving the organizational domain at p=none blocks many BIMI display attempts today.
Treating DMARC aggregate reports like complaint feedback loops causes confusion.
Publishing BIMI before enforcement creates a record receivers are likely to ignore.
Expert tips
Move policy in stages, but finish at pct=100 before expecting BIMI to display in inboxes.
Check subdomain DMARC records because they can override the parent domain policy.
Confirm the report processor is owned and watched before depending on its data weekly.
Expert from Email Geeks says SPF and DKIM should be deployed across every mail stream before DMARC policy moves beyond reporting.
2024-02-14 - Email Geeks
Expert from Email Geeks says DMARC should run at p=none first so missed senders and DKIM failures can be fixed before enforcement.
2024-03-05 - Email Geeks
A practical finish
The DMARC requirement for BIMI is complete when the domain is enforced at 100 percent and the legitimate mail you care about still passes. A visible logo is the outcome of a working authentication program, a compliant SVG, a valid certificate where required, and stable public hosting.
My practical order is: make senders pass DMARC, observe reports, enforce the organizational domain and sending subdomains, publish BIMI, then keep monitoring. That order prevents the two common failures: breaking real mail during enforcement, or publishing a BIMI record that mailbox providers ignore.
- First: Fix authentication and reporting before touching BIMI DNS.
- Second: Move DMARC to enforcement only after the reports look clean.
- Third: Publish BIMI assets and keep monitoring for sender drift.
