Adding your company logo to emails sounds simple. In practice, getting BIMI (Brand Indicators for Message Identification) working across supported mailbox providers takes more than uploading an image and adding a DNS record.

BIMI depends on your existing email authentication setup. Your sending domains need to pass DMARC, your logo needs to meet the required SVG format, and depending on the mailbox provider, you may need a BIMI certificate such as a Verified Mark Certificate (VMC) or Common Mark Certificate (CMC).

There is another point that is easy to miss: publishing BIMI does not guarantee that your logo will appear in every inbox. Each participating mailbox provider has its own requirements and decides when and where BIMI logos are displayed.

If you are planning a BIMI deployment, use this checklist before publishing your record. Each step covers what needs to be true, then shows where to do it in DMARCS, so you can work through the whole chain from one account at admin.dmarcs.com.

1. Start with your email authentication

BIMI comes after SPF, DKIM and DMARC, not before them. The first question is simple: are all legitimate emails sent from your domain properly authenticated?

Review every service that sends email using your domain: Microsoft 365 or Google Workspace, marketing platforms, CRM and sales tools, customer support systems, transactional email services, HR and finance systems, website forms, cloud applications, monitoring platforms and third-party vendors sending on your behalf. If you have never done this, auditing who sends as you is the place to start.

A domain can have a perfectly valid BIMI record and still have authentication problems elsewhere. Google recommends SPF, DKIM and DMARC for email authentication, while the BIMI Group’s implementation guidance requires DMARC enforcement for BIMI.

Doing this in DMARCS

1. Add the domain. Go to Setup & Records → Record Wizard, enter the domain and publish the DMARC TXT record it gives you, then click Verify Record Now. Extra domains go in under Organization → Settings → Domain Management with Add New Domain (Organization Admin only).

   Type   TXT
   Host   _dmarc
   Value  v=DMARC1; p=none; rua=mailto:rua.reports@dmarcs.com; ruf=mailto:ruf.reports@dmarcs.com

2. Wait for data. Mailbox providers send aggregate reports once a day, so expect the first data 24 to 48 hours after publishing.
3. Inventory your senders. Open Reports → Sending Sources. Every source gets a badge: green Approved, blue Forwarder, amber Unapproved (a real vendor that isn’t set up properly, flagged as a Shadow IT Alert) and red Spoofing.
4. Fix the amber rows. Find out who in the business uses the service, add it to SPF and switch on DKIM at the vendor. Where DMARCS recognises the vendor, the row’s remediation guide gives you the exact DNS change.
5. Leave the red rows alone. There’s nothing to fix on your side. Enforcement is what stops them.
6. Tidy SPF and DKIM. Use SPF Surveyor to see your include tree and Smart SPF if you are near the 10-lookup limit. DKIM Inspector flags weak 1024-bit keys.

Watch Sending Sources for at least two to four weeks so monthly senders, such as invoicing runs or newsletters, have a chance to show up.

Checklist

• SPF is published and valid
• DKIM is enabled for every relevant sending platform
• DMARC is published and reporting into DMARCS
• Legitimate senders pass DMARC (green in Sending Sources)
• SPF and DKIM are aligned with the visible From domain
• Amber Unapproved sources have been fixed or retired
• Third-party email services have been reviewed

This is where many BIMI projects uncover problems that have nothing to do with BIMI itself. If you still have unknown sending sources, resolve those first.

2. Move DMARC to enforcement

This is the main prerequisite. The BIMI Group’s guidance says the organisational domain must have DMARC enforcement at p=quarantine or p=reject, that pct must not be below 100%, and that the relevant organisational and subdomain policies need to be at enforcement. A policy of p=none is not enough.

A typical enforced policy looks like this:

v=DMARC1; p=quarantine; rua=mailto:rua.reports@dmarcs.com; pct=100

or:

v=DMARC1; p=reject; rua=mailto:rua.reports@dmarcs.com; pct=100

The right policy depends on your environment. Jumping from monitoring straight to rejection, without knowing your legitimate senders, can disrupt business email — the difference between quarantine and reject is worth understanding before you move.

Doing this in DMARCS

1. Check readiness. Open Setup & Records → Enforcement Guide. When more than 95% of your mail passes DMARC, the verdict turns green: Ready for Enforcement. Until then it shows Not Ready Yet with your actual pass rate, and the Unverified Sources table lists every sender still failing. Set the date range in the header to cover at least a couple of weeks of normal sending.
2. Switch to Smart DMARC. Open Setup & Records → Smart DMARC, pick the domain and publish the CNAME it shows you at _dmarc. Delete the existing _dmarc TXT record first, because a host can’t hold both a CNAME and a TXT.
3. Tighten the policy. Either click Advance now yourself (starting low, 10% is a sensible first step), or switch on Auto-advance with a target of quarantine or reject. Auto-advance climbs this ladder only when your report data says it’s safe:

   none  >  quarantine 25%  >  quarantine 50%  >  quarantine 100%  >  reject 50%  >  reject 100%

4. Don’t stop at a partial rung. BIMI needs the percentage at 100%. Quarantine 25% or 50% is progress, but your logo won’t qualify until you reach quarantine 100% or reject 100%.

The Enforcement Guide only tells you whether you’re ready. The policy itself changes in Smart DMARC, or in the p= value of your own TXT record if you keep DMARC in your own DNS.

Checklist

• Enforcement Guide shows Ready for Enforcement
• DMARC policy is p=quarantine or p=reject
• pct=100, or no lower percentage is set
• Legitimate email passes DMARC
• Subdomain policy has been reviewed (see step 3)
• DMARC aggregate reports are being monitored
• Unauthorised sending sources have been investigated

BIMI is not a replacement for DMARC. It builds on it.

3. Confirm the domains you actually want to protect

Large organisations rarely send all email from one place. Alongside example.com you may have mail.example.com, marketing.example.com, support.example.com, and separate domains for other brands or business units. Before implementing BIMI, document which domains and subdomains carry customer-facing email. If you are running this across a large estate, managing DMARC at scale covers the wider problem.

The BIMI Group recommends publishing a default BIMI record at the organisational domain so subdomains inherit it. A specific subdomain can have its own BIMI record where needed. You don’t want to configure BIMI for one domain while another quietly sends thousands of messages a month.

Doing this in DMARCS

1. List what you own. Organization → Settings → Domain Management shows every domain in the account as Primary, Active or Pending. Each brand domain you want a logo on needs to be here and verified.
2. Find what you forgot. Monitoring & Risk → Subdomain Monitor lists discovered subdomains with first-seen and last-seen dates. Inspect Details on any row opens DNS Inspector already filled in for that subdomain. Forgotten subdomains are not just a coverage gap — they are how attackers build phishing infrastructure.
3. Check the subdomain policy. Subdomains inherit the main domain’s DMARC policy unless sp= sets a separate one. Make sure sp= is at least as strict as p=, and that no subdomain publishes its own weaker _dmarc record.
4. Hear about new ones. Under Organization → Alerting, create a New Subdomain alert so new subdomains don’t slip past your BIMI and DMARC coverage.

Checklist

• Primary organisational domain identified
• Sending subdomains documented (Subdomain Monitor reviewed)
• Separate brand domains added and verified in Domain Management
• Marketing and transactional domains identified
• sp= is at least as strict as p=
• BIMI inheritance for subdomains reviewed
• Each brand identity mapped to the correct domain

4. Prepare the BIMI logo

Your existing logo can’t simply be uploaded as a PNG or JPEG. BIMI needs it in the SVG Tiny Portable/Secure (SVG Tiny PS) profile, which comes with security restrictions: no scripts, no event handlers, no links to external files.

This is where your design and IT teams need to work together. A logo that looks good on a website may not work at the small size an inbox uses. Keep the BIMI version simple, recognisable at small sizes, suited to a square display area and free of fine detail.

Doing this in DMARCS

1. Export correctly. Re-export the logo from your design tool as SVG Tiny PS, with no embedded images, fonts or scripts. Keep it under 2MB, which is the BIMI Inspector upload limit.
2. Let DMARCS host it (optional). If you use Brand → BIMI Inspector, you upload the file and DMARCS hosts it over HTTPS for you. It also cleans the file on upload, stripping scripts, event handlers and external links.
3. Preview it. The Inbox Preview panel in BIMI Inspector shows roughly how the logo will look beside a sample email, so you catch a cropped or off-centre logo before anyone else does.
4. Read the error if it’s rejected. “Security Violation: the SVG could not be parsed or contains disallowed content” means the file still has something mail providers won’t accept, or isn’t valid SVG. Design tools often add these without telling you.
5. Mark it done. Tick SVG Logo Ready in Brand → VMC Tracker.

If you host the logo yourself instead, it must be served over HTTPS and be publicly reachable. Opening in a browser doesn’t prove it’s valid for BIMI.

Checklist

• Official brand logo selected
• Logo exported as SVG Tiny PS, under 2MB
• No scripts, event handlers or external references
• Logo checked at small sizes (Inbox Preview)
• Logo hosted over HTTPS (by DMARCS or on your own server)
• Logo URL publicly accessible to mailbox providers

5. Decide whether you need a BIMI certificate

This is one of the biggest decisions in the project. A logo can be asserted for BIMI in three ways: self-asserted, with a Common Mark Certificate (CMC), or with a Verified Mark Certificate (VMC).

The BIMI Group notes that self-asserted records have limited support across mailbox providers. A VMC is tied to a registered trademark and verifies authorised use of the logo. A CMC is a newer certificate route for eligible marks. There is no single display rule: each mailbox provider decides which certificates it accepts.

If Gmail visibility is part of the goal, don’t leave the certificate question until the end. Certificate requirements have long been a central part of Gmail’s BIMI support.

Doing this in DMARCS

Open Brand → VMC Tracker. It’s one page that shows how far along you are across the trademark office, the certificate authority, your design team and your DNS.

When the certificate arrives, you need it in PEM format (a text file starting -----BEGIN CERTIFICATE-----), under 512KB. Not a zip, not a .p7b, not the private key. Your certificate authority can supply the PEM version.

You can publish BIMI before the certificate is ready. The logo will show in providers that don’t require one, and you add the certificate later.

Checklist

• Self-asserted approach evaluated
• VMC requirements checked
• CMC eligibility considered
• Trademark status confirmed (VMC Tracker)
• Certificate requirements reviewed for target mailbox providers
• Certificate obtained in PEM format, under 512KB
• Renewal date recorded in your calendar

6. Publish the BIMI DNS record

Once authentication and the logo are ready, you can publish. The record lives at default._bimi.example.com. Its basic structure is:

v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/certificate.pem

v= identifies the BIMI version, l= points to the SVG logo, and a= points to the VMC or CMC. For a self-asserted record, a= can be left out.

DMARCS gives you two ways to publish. Pick one per domain.

Option A: hosted, with BIMI Inspector

DMARCS hosts the logo, the certificate and the record. Your side is one CNAME.

1. Open Brand → BIMI Inspector and pick the domain.
2. Upload your SVG Tiny PS logo (under 2MB).
3. Upload your VMC in PEM format (under 512KB) if you have one. Skip this if you don’t yet.
4. Click Publish Record. It stays disabled until a logo is uploaded.
5. Add the single CNAME DMARCS shows you, at the default._bimi host, pointing at the DMARCS-hosted target. Copy the target from the app rather than retyping it.

Type   CNAME
Host   default._bimi
Value  (DMARCS-hosted target, copied from BIMI Inspector)

The advantage: when you replace the logo or renew the certificate later, you upload the new file in DMARCS. Your DNS doesn’t change.

Option B: self-hosted, with BIMI Builder

Use this if you’d rather keep the logo and certificate on your own servers.

1. Open Brand → BIMI Builder and enter the domain.
2. Enter the HTTPS URL of your SVG logo and, optionally, of your certificate.
3. Copy the TXT record DMARCS builds as you type:

   Type   TXT
   Host   default._bimi
   Value  v=BIMI1; l={logoUrl}; a={certUrl};

4. Click Check for Conflicts to compare it with whatever is already at default._bimi, so you don’t end up with two records.
5. Publish it yourself at your DNS provider. BIMI Builder only advises; it doesn’t write DNS for you.

General guidance, not from DMARCS docs: if your DNS is on Cloudflare, set the default._bimi CNAME to DNS only (grey cloud), not proxied. Otherwise Cloudflare answers in place of DMARCS.

Checklist

• Hosted (BIMI Inspector) or self-hosted (BIMI Builder) chosen
• Record published at default._bimi
• Only one record at that host (Check for Conflicts run, if self-hosted)
• v=BIMI1 included (self-hosted)
• l= points to the correct SVG
• a= points to the correct certificate where applicable
• No stray spaces or formatting errors
• Public DNS lookup confirms the record

7. Validate the entire chain

Don’t stop at checking that the BIMI record exists. A working deployment depends on every link holding, in this order:

1. Email authentication (SPF and DKIM)
2. DMARC alignment
3. DMARC enforcement at 100%
4. BIMI DNS record
5. SVG accessibility
6. Certificate validation, where required
7. Mailbox provider eligibility

If any one of these fails, the logo may not appear.

Doing this in DMARCS

• BIMI status badge. In Brand → BIMI Inspector, green Live & Protecting means your CNAME resolves and the live record is correct. Amber Pending CNAME means DMARCS has published its side and is waiting for your CNAME to appear in DNS. Amber Could not verify means the DNS check itself failed; it doesn’t mean BIMI is broken, so try again later. Grey Not Detected means nothing is published yet.
• VMC Tracker. DMARC Enforcement and Publish BIMI tick themselves automatically from live DNS, so a missing tick points you straight at the broken link.
• Dashboard. Reports → Home shows the Domain Security panel with SPF, DKIM, DMARC and BIMI status for the selected domain.
• DNS Inspector. Inspect → DNS Inspector → DNS Inspector shows the raw DMARC and SPF values the world currently sees, useful for confirming p= and pct= after a change.

The BIMI Group’s own BIMI Inspector is a useful independent second opinion.

Checklist

• BIMI record resolves at default._bimi (Live & Protecting, if hosted)
• SVG and certificate URLs resolve, where self-hosted
• SPF, DKIM and DMARC pass, with correct alignment
• DMARC policy enforced at 100%
• SVG valid and served over HTTPS
• Certificate valid and matching both the logo and the domain
• Certificate accepted by the relevant mailbox providers

8. Test with real mail

A validator can confirm your configuration is technically sound. It can’t guarantee a logo in every inbox, because mailbox providers make their own display decisions. Yahoo, for example, says its BIMI display depends on a valid record, an enforced DMARC policy, mail volume, and sufficient sender reputation and engagement.

So test with real messages across corporate, marketing and transactional mail, different From addresses, different sending platforms, different domains and subdomains, and the mailbox providers your audience actually uses (Gmail, Yahoo Mail and others).

Doing this in DMARCS

1. Open Inspect → Domain Health and copy the test address and code with the copy button.
2. Send a message containing the code to check@dmarcs.com, from the mail system you want to test. Checking Microsoft 365? Send from Outlook, not from a marketing tool.
3. Click Check Results. DMARCS shows a pass, fail or unknown badge for SPF, DKIM and DMARC as a receiver saw them. “Email not found yet” usually means the message is still in transit.
4. Repeat for every platform that sends as the domain: your CRM, your newsletter tool, your ticketing system.

Domain Health confirms that each system authenticates. The logo itself you confirm by sending to real Gmail and Yahoo mailboxes and looking.

Record what you see, and don’t treat a logo in one mailbox as proof the deployment is complete.

9. Monitor after implementation

BIMI is not a set-and-forget DNS record. Marketing adds a new email platform. A CRM starts sending directly. A business unit launches a subdomain. The brand team changes the logo. Any of these can break the chain, and because BIMI sits on top of DMARC, a quiet authentication failure is enough to make the logo disappear.

Doing this in DMARCS

Set up alerts under Organization → Alerting with New Alert, pick a trigger and Save. Alerts are always emailed; some can also post to Microsoft Teams or Slack.

Keep working these pages too:

• Reports → Sending Sources for new amber or red sources.
• Inspect → DNS History for a timeline of every DMARC and SPF record version, when you need to know what changed and when.
• Brand → BIMI Inspector status badge after any DNS or certificate change.
• Reports → Reports Hub → Automation to schedule a regular report to the people who own email.

A VMC is a paid certificate with an expiry date. When it lapses, your logo stops showing and nothing tells you. Put the renewal date in your calendar when you buy it.

Checklist

• DMARC Downgrade and Auth Rate Drop alerts created
• DNS Record Change and New Subdomain alerts created
• Sending Sources reviewed on a regular schedule
• BIMI Inspector badge checked after DNS or certificate changes
• Logo availability confirmed (hosted or self-hosted)
• Certificate renewal date in the calendar
• Mailbox-provider display behaviour spot-checked

10. Plan for logo changes

A brand refresh can create an unexpected BIMI task. The BIMI Group specifically calls out logo changes as a technical consideration for organisations already using BIMI. If you hold a VMC or CMC, the certificate covers a specific mark, so a new logo usually means a new certificate as well.

Doing this in DMARCS

1. Export the new logo as SVG Tiny PS and check it in the Inbox Preview.
2. Get the new certificate issued for the new mark, if you use one, and update Trademark Verified and Purchase VMC in VMC Tracker.
3. Hosted (BIMI Inspector): upload the new logo and certificate and click Publish Record again. Your default._bimi CNAME stays as it is.
4. Self-hosted (BIMI Builder): replace the files on your server, update the URLs in BIMI Builder, run Check for Conflicts and update the TXT record if the URLs changed.
5. Confirm the BIMI Inspector badge returns to Live & Protecting, then re-test in Gmail and Yahoo.

Your brand team should bring in whoever owns email security or DNS before a major logo change goes live, not after.

BIMI implementation checklist

Use this as the final pre-deployment review. The right-hand column shows where to check each item in DMARCS.

• Email authentication complete
• DMARC enforced at 100%
• Domains and subdomains covered
• Logo ready
• Certificate decision made and, where needed, obtained
• BIMI record published
• Chain validated
• Real mail tested
• Monitoring and alerts in place
• Logo changes added to change management

BIMI is the last step, not the first

BIMI is usually sold as a way to put your logo next to your emails. That’s the visible part.

The work starts much earlier. Before a mailbox provider will consider your logo, you need to know who sends email as you, authenticate those sources, enforce DMARC at 100%, publish a valid BIMI record and supply a logo that meets the technical rules. Certificates add another layer where required.

That’s why BIMI works best as part of a wider email authentication programme rather than a one-off DNS job. In DMARCS the same account that shows your sending sources, tells you when you’re ready to enforce and moves your policy up is also where you publish the logo, track the certificate and get alerted when something slips. If you would rather walk through it with someone, get in touch.

The logo is what people see in the inbox. The work behind it is what keeps it there.