Hosted BIMI

21 June 2026 · 28 min read

What BIMI is and how it earns you a logo in the inbox

BIMI (Brand Indicators for Message Identification) is the DNS-published standard that lets participating mailbox providers - most notably Gmail and Apple Mail - display your brand's logo next to your emails in the inbox, instead of a generic initial-letter avatar. It is a trust signal, not a security control in its own right: BIMI rides on top of a domain that has already proven, via DMARC, that it is who it says it is.

At a technical level, a receiving mail server that supports BIMI does the following on every inbound message:

1. Checks whether the message passes DMARC (SPF or DKIM aligned, and the DMARC policy record exists).
2. Checks whether the sending domain enforces DMARC at p=quarantine or p=reject and applies that enforcement to (effectively) all mail - a pct=100 policy, or a clear path to it.
3. Looks up a BIMI1 TXT record at default._bimi.<domain> (or a named selector, covered below).
4. Fetches the logo referenced by the l= tag in that record - an SVG file - and, if the receiver requires it, validates an a= tag pointing to a Verified Mark Certificate (VMC) or Common Mark Certificate (CMC).
5. If every check passes, the receiver renders your logo in the inbox list and, on some clients, inside the opened message.

None of this happens unless DMARC enforcement is already in place - BIMI is a reward for authentication hygiene, not a replacement for it. If you haven't yet got your domain to p=quarantine or p=reject, read Hosted DMARC first; everything in this guide assumes that step is done.

Note BIMI adoption varies by mailbox provider. Gmail, Apple Mail (iCloud/Mail app), Yahoo, AOL, and Fastmail support it today. Microsoft (Outlook.com/Microsoft 365) does not display BIMI logos at the time of writing. Publishing BIMI does no harm for non-supporting providers - they simply ignore the record - but don't expect a logo everywhere.

Where the logo actually appears

BIMI rendering differs slightly by client, which matters when you're deciding whether your setup "worked":

• Gmail (web and app): logo shown as the avatar circle in the inbox list, next to the sender name, for every message from an eligible domain.
• Apple Mail (macOS and iOS/iPadOS): logo shown as the sender avatar in the message list and inside the opened message header.
• Yahoo Mail / AOL: logo shown as the sender avatar in the inbox list.
• Fastmail: logo shown in the inbox list, with the option enabled per-user in settings on some plans.
• Outlook.com / Microsoft 365 (Outlook desktop and web): no BIMI support at the time of writing - Microsoft uses its own separate branding mechanisms, not BIMI. Don't treat a missing logo in Outlook as a sign your setup is broken.

Because rendering is client-controlled, the same correctly-configured BIMI record can look "successful" in one inbox and invisible in another, purely down to which mailbox provider the recipient uses - this is expected, not a fault in your configuration.

Designing a BIMI-friendly mark

A few practical design choices make a real difference to how your logo reads once it's shrunk down to inbox size:

• Prefer a simple mark over a full lock-up. Wordmarks with fine typographic detail rarely survive being rendered at 16-24px; a monogram, icon, or simplified badge version of your brand usually reads better than your full logo-plus-wordmark.
• Use solid, high-contrast shapes. Thin strokes and subtle tonal gradients tend to disappear or look muddy at small sizes; bold, filled shapes hold up.
• Centre the mark with generous padding. Many clients render the logo inside a circular mask - if your artwork touches the edges of the canvas, corners of a non-circular mark can be clipped.
• Match your existing brand colours exactly, but don't rely on subtle colour distinctions that won't survive small-scale rendering or slightly different colour management across clients.
• Avoid text entirely if you can. If your logo is primarily wordmark-based, consider whether a distinct icon/symbol version of your brand exists - it will almost always be more recognisable at inbox scale than rendered text.

Tip If you don't already have a square, icon-only version of your brand mark, this is a good moment to have one made - it's reusable well beyond BIMI (app icons, social avatars, favicon) and solves the "my logo is a wordmark" problem at the source rather than trying to force-fit small type into 24 pixels.

Why DMARC enforcement is a hard prerequisite

This is the single most common reason BIMI setup stalls, so it's worth stating plainly: if your DMARC policy is p=none, no mailbox provider will show your BIMI logo, no matter how correct the rest of your setup is. p=none is a monitoring-only policy - it tells receivers "watch and report, but deliver mail even if it fails authentication." BIMI's entire value proposition rests on receivers being able to trust that mail claiming to be from your domain really is from your domain, and a monitoring-only policy doesn't provide that guarantee.

The bar, in practice:

• Gmail requires p=quarantine or p=reject, at effectively 100% enforcement (a pct tag below 100, or no pct tag defaulting to 100, still needs to cover all mail - a partial rollout at, say, pct=50 is inconsistent and risky for BIMI).
• Apple Mail requires the same DMARC enforcement bar and additionally requires a VMC (see below) for the logo to display.
• Yahoo/AOL require DMARC enforcement; they will accept either a VMC or, in some cases, no certificate at all for basic display, though requirements have tightened over time.

If you're still ramping up your DMARC policy from p=none towards p=reject, use the DMARC builder to track your ramp and the Analytics page to confirm your legitimate mail streams (marketing platform, helpdesk, invoicing tool, and so on) are all passing alignment before you flip enforcement on. Jumping straight to p=reject without first confirming every legitimate sender is aligned is the fastest way to have real customer emails silently rejected - see Hosted DMARC for the ramp methodology (p=none → p=quarantine → p=reject, raising pct at each stage).

Warning Do not publish a BIMI record while sitting at p=none "just to get ahead of it." Some receivers cache negative lookups and re-check infrequently; you may find your logo doesn't appear for days or weeks after you correctly raise enforcement, simply because the receiver already decided "not eligible" and hasn't rechecked. Get enforcement solid first, then add BIMI.

Logo requirements: SVG Tiny Portable/Secure (SVG Tiny P/S)

BIMI does not accept an arbitrary SVG, PNG, or JPEG. The specification mandates SVG Tiny Portable/Secure (SVG Tiny P/S), a deliberately restricted subset of SVG Tiny 1.2 designed to eliminate any executable or externally-referencing content - no <script>, no <a> links, no raster image embeds, no external stylesheets, no animations, no filters, no CSS @import. The restrictions exist because your logo is fetched and rendered directly by the mail client, and a full-featured SVG is a plausible attack surface (script injection, tracking pixels via external references, and so on).

Concretely, an SVG Tiny P/S file must:

Converting your logo to SVG Tiny P/S

Most brand logos start life as a vector file in Illustrator, Figma, or a similar tool, or as a raster PNG that needs tracing into vector shapes first. The conversion path:

1. Start from a clean vector source. If you only have a raster logo (PNG/JPG), trace it into vector paths first (Illustrator's Image Trace, Inkscape's Trace Bitmap, or a professional redraw) - BIMI logos should be crisp vector art, not an embedded photo.
2. Simplify the artwork. Remove drop shadows, gradients-as-raster-effects, embedded fonts (convert text to outlines/paths), and any filter effects. BIMI renders at small sizes (roughly 16-32px in most inbox UIs), so intricate detail is wasted anyway.
3. Set a square canvas. Use a square viewBox, centring the logo with reasonable padding - many brands render their logo inside a circle or rounded-square "badge" for consistency with how avatars typically display.
4. Export as plain SVG from your design tool (Illustrator: Save As SVG; Figma: Export as SVG; Inkscape: Save As Plain SVG).
5. Strip it down to SVG Tiny P/S using a dedicated converter. The most widely used free tool is Vecta.io's SVG Tiny P/S converter, and there is also a validator maintained via the BIMI Group. These tools will flag anything the spec disallows (scripts, external refs, unsupported elements) and typically offer an auto-fix pass.
6. Add baseProfile="tiny-ps" and a <title> if your converter hasn't already inserted them.
7. Validate the output. Run it through a BIMI SVG validator before publishing - a failed validation is invisible to you (the file still "looks right" opened in a browser) but will cause receivers to silently ignore your BIMI record.
8. Check file size and rendering at small scale. Preview the SVG shrunk down to roughly 16-24px to make sure it's still legible - this is genuinely how small it renders in most inbox lists.

Tip Use the free DNS lookup tool to sanity-check your BIMI DNS record once published, and keep a copy of your validated SVG Tiny P/S file somewhere durable (your design system repo, brand asset store) - you'll need to re-upload it if you ever rotate selectors or refresh the artwork.

The VMC / CMC certificate: what it is and when you need one

A Verified Mark Certificate (VMC) is a certificate issued by an authorised Certificate Authority (currently DigiCert or Entrust) that cryptographically attests your logo is a legally registered trademark owned by your organisation, and binds that trademark to your sending domain. A Common Mark Certificate (CMC) is a newer, lighter-weight alternative that verifies your organisation's use of the logo without requiring a formal trademark registration - useful for organisations that have an established brand mark but haven't registered it as a trademark in a covered jurisdiction.

Do you need one?

In short: if your goal is "logo shows up in Gmail and/or Apple Mail," a VMC (or CMC) is not optional. If you only care about smaller providers that don't currently mandate one, you can publish BIMI with just the logo and skip the certificate - but you should expect to add one later as more providers tighten requirements.

Getting a VMC or CMC

1. Confirm your trademark status. A VMC requires a registered trademark for your logo, valid in a jurisdiction the issuing CA recognises (this typically means a national or regional trademark office, not just common-law use). If you don't have a registered mark, look at a CMC instead, or begin the trademark registration process with your legal/IP counsel.
2. Choose an issuing CA. As of writing, DigiCert and Entrust are the two established issuers of VMCs; CMC issuance is also emerging through the same and adjacent CAs. Check current pricing and turnaround directly with the issuer, as this changes.
3. Submit your validated SVG Tiny P/S logo and trademark documentation to the CA as part of the application. The CA will validate the mark against trademark registries and confirm your organisation's legal right to it.
4. Complete organisation validation. Expect a process broadly similar to Extended Validation (EV) certificate issuance - proof of legal entity, domain control, and authorised requester.
5. Receive your VMC/CMC file (a .pem certificate) once issued. Turnaround is typically days to a couple of weeks depending on how quickly trademark validation clears.
6. Reference it in your BIMI record's a= tag - see the DNS record layout below. DMARC Engine doesn't issue or host the certificate file itself; you host the .pem at a URL you control (commonly on your own web server) and point the a= tag at that URL.

Note A VMC/CMC has its own expiry and renewal cycle, independent of your DMARC/SPF/DKIM setup. Calendar a renewal reminder well before expiry - an expired certificate will cause Gmail and Apple to stop showing your logo even though every other part of your BIMI record is still fine.

Common reasons receivers reject a BIMI submission

Before you publish anything, it's worth knowing the shortlist of reasons a receiver will silently decline to show your logo - "silently" because there is generally no bounce, error email, or notification when this happens; the logo just doesn't appear:

1. DMARC not enforcing, or not enforcing at 100%. By far the most common cause - covered in detail below.
2. A legitimate sending source is failing alignment, which drags your effective pass rate down even if your policy tag says p=reject.
3. Invalid SVG Tiny P/S - wrong baseProfile, disallowed elements, or a missing <title>.
4. Missing or invalid VMC/CMC for a provider that requires one (Gmail, Apple).
5. Expired VMC/CMC - a certificate that was valid at setup time but has since lapsed.
6. Logo or certificate URL unreachable - for self-hosted files, a 404, timeout, TLS error, or wrong Content-Type header on the response.
7. BIMI record published at the wrong hostname - for example, published under a subdomain that isn't actually the one used in the From: address of your mail.
8. DNS not yet propagated, or a typo in the CNAME target/selector.

Cross-reference this list against the troubleshooting table further down, which maps each of these to a concrete fix.

How hosted BIMI works on DMARC Engine

DMARC Engine hosts your BIMI record the same way it hosts your DMARC, SPF, DKIM and MTA-STS records: you publish a single CNAME in your own DNS, pointing at a per-selector, per-domain hostname we serve. We then manage the actual BIMI1 TXT content on our side - logo reference, certificate reference, and any future spec updates - without you needing to touch your DNS again after the initial delegation.

The hosted BIMI CNAME pattern, using your domain's selector and the per-domain hosting slug shown in the app:

<selector>._bimi.<domain>.    IN  CNAME  <selector>.<slug>._bimi.dmarcengine.com.

For example, if your domain is example.com, your hosting slug (shown on your domain's page in the app) is a1b2c3, and you're using the conventional default selector:

default._bimi.example.com.    IN  CNAME  default.a1b2c3._bimi.dmarcengine.com.

Once that CNAME resolves, we serve the actual BIMI1 TXT record content on our side - including the l= logo URL and, if you've supplied one, the a= certificate URL - and update it centrally if you rotate the logo or certificate, without requiring any further DNS change from you.

The manual (self-managed) alternative

If you'd rather not delegate via CNAME - for example, your DNS is managed by a team that prohibits third-party CNAMEs on security-sensitive records, or you're hosting the logo file yourself and want full control - you can publish the BIMI1 TXT record directly instead:

default._bimi.example.com.    IN  TXT  "v=BIMI1; l=https://example.com/assets/bimi/logo.svg; a=https://example.com/assets/bimi/vmc.pem"

Tag reference:

With the manual route, you host both the SVG and the certificate file yourself, over HTTPS, on infrastructure you maintain - and you're responsible for keeping those URLs stable and correctly served (correct Content-Type, valid TLS, no redirects that break the fetch). With the hosted route, you upload the logo (and, if you have one, the certificate reference) once in the app, and we take care of serving it correctly and keeping the DNS content current.

Tip The hosted CNAME approach is strongly recommended even for BIMI specifically, because logo and certificate rotations are common - brand refreshes, VMC renewals - and each rotation under the manual approach means editing the TXT record by hand (or at minimum, editing the hosted file and hoping nothing about the URL changed). Under hosted BIMI, you just re-upload in the app and the served record updates automatically; your DNS entry never changes.

Setting up BIMI step by step

BIMI setup has more moving parts than most of the other records DMARC Engine hosts, largely because two of the prerequisites - DMARC enforcement and a VMC/CMC - sit outside the DNS record itself and have their own lead times. It helps to think of the work in three tracks that can partly run in parallel:

Because the certificate track has the longest and least predictable lead time, it's worth starting that application in parallel with finishing your DMARC ramp, rather than waiting until DMARC is fully enforced before even enquiring with a CA. The DNS record itself - the CNAME you publish - takes minutes to set up once the other tracks are ready, and you can add the certificate reference later without touching DNS again if it clears after your logo goes live.

Step 1: Confirm DMARC is enforcing

1. Open Domains and select the domain you want to enable BIMI for.
2. Go to the domain's DMARC page and confirm the policy shown is p=quarantine or p=reject, with pct=100 (or no pct tag, which defaults to 100).
3. Check Analytics for the last 7-14 days and confirm no legitimate sending source is still failing DMARC alignment. If anything is failing, fix that source's SPF/DKIM alignment before proceeding - see Hosted SPF and Hosted DKIM.

Warning Don't skip this step because "the policy tag says reject." A policy tag of p=reject with a sending source that's still failing alignment means real mail from that source is actively being rejected right now - that's a mail-delivery incident, not a BIMI blocker, and it needs fixing regardless of BIMI. Resolve it first.

Step 2: Prepare your logo

1. Export your brand mark as a clean, square vector SVG (see the conversion steps above).
2. Run it through an SVG Tiny P/S converter/validator and confirm baseProfile="tiny-ps", a <title> element, and no disallowed content remain.
3. Preview it at small scale (roughly 16-24px) to confirm it's still legible.
4. Keep the validated file to hand - you'll upload it in Step 4.

Step 3 (recommended): Obtain a VMC or CMC

1. Decide whether you need Gmail/Apple support (if yes, a VMC/CMC is mandatory).
2. Engage an issuing CA (DigiCert or Entrust, at time of writing) with your trademark documentation and validated logo.
3. Once issued, save the .pem certificate file.
4. You'll reference this in Step 4 as well, or add it later - BIMI can be published logo-only first and the certificate added once issued, without disturbing the DNS record you've already delegated.

Step 4: Add the domain and upload assets in the app

1. In Domains, confirm the domain is added and verified.
2. Open the domain's BIMI page.
3. Upload your validated SVG Tiny P/S logo file.
4. If you have a VMC/CMC, upload or link it in the certificate field on the same page.
5. Choose or confirm the selector for this record - see Step 5.
6. Save. The app will show you the exact CNAME hostname to publish, generated from your domain's hosting slug and chosen selector.

Step 5: Choose your selector

BIMI selectors let you run more than one BIMI record for a domain - most commonly used when you want a different logo or certificate for different sending contexts, or when rotating credentials without downtime (publish the new selector alongside the old one, then cut over). If you have no reason to run more than one, use the conventional default selector; it's what most receivers expect if no other selector is specified in the message.

1. On the BIMI page, enter your chosen selector name (letters, digits, and hyphens; keep it short and lower-case) or accept default.
2. Note the exact hostname the app now shows for your CNAME - it will be in the form <selector>.<slug>._bimi.dmarcengine.com.

Step 6: Publish the CNAME in your DNS

1. Log in to your DNS provider's control panel for the domain.
2. Create a new CNAME record:
3. - Host/Name: <selector>._bimi (for example, default._bimi)
4. - Type: CNAME
5. - Value/Target: the exact hostname shown in the app, e.g. default.a1b2c3._bimi.dmarcengine.com
6. - TTL: your provider's default (typically 300-3600 seconds) is fine
7. Save the record.
8. Allow time for DNS propagation - this is usually minutes, occasionally longer depending on your provider and any existing TTL on that hostname.

; Example zone file entry
default._bimi.example.com.    3600  IN  CNAME  default.a1b2c3._bimi.dmarcengine.com.

Step 7 (alternative): Publish the record manually

If you're not delegating via CNAME, publish the BIMI1 TXT record directly at the same hostname, pointing at logo and (optionally) certificate files you host yourself over HTTPS:

default._bimi.example.com.    3600  IN  TXT  "v=BIMI1; l=https://example.com/assets/bimi/logo.svg; a=https://example.com/assets/bimi/vmc.pem"

Remember that with this route, you are responsible for the ongoing availability, correct MIME type, and valid TLS of both hosted files - a broken link here is invisible until a receiver tries to fetch it and silently drops your BIMI eligibility.

Verify it worked

1. Check DNS resolution. Use the free DNS lookup tool or dig to confirm the CNAME (or TXT) resolves correctly:

   dig CNAME default._bimi.example.com
   

or, for a manual TXT record:

   dig TXT default._bimi.example.com
   

1. Confirm the app shows a green/verified BIMI status. Return to the BIMI page - it will flag whether the record resolves as expected and whether the logo and certificate (if supplied) are reachable.
2. Re-confirm DMARC enforcement hasn't drifted. Check DMARC and Analytics again - BIMI display can silently stop if a new unaligned sending source appears and pushes your effective pass rate down, or if anyone quietly drops the policy back to p=none.
3. Send a real test email to a Gmail and/or Apple Mail account you control, from the domain in question, using a properly authenticated sending path (a source that passes SPF/DKIM alignment). Check the inbox list view for the logo.
4. Be patient with caching. Even with everything correctly configured, mailbox providers cache BIMI eligibility decisions and don't necessarily recheck on every message. It can take anywhere from a few hours to a few days after first going live for the logo to consistently appear, and providers may only pick it up on the next message they choose to reevaluate.
5. Check Audit for a consolidated view confirming DMARC, SPF, DKIM, and BIMI are all correctly aligned for the domain.

Tip If you've just added or renewed a VMC/CMC, test with a fresh message rather than assuming an already-delivered message will retroactively show the logo - inbox rendering is generally decided close to delivery time, not recalculated afterwards.

Common problems and fixes

Frequently asked questions

Does BIMI improve deliverability or inbox placement?
Not directly - BIMI does not change spam-filtering decisions. Its value is purely presentational: a verified, recognisable logo next to your emails, which can improve open rates and brand trust, but it won't rescue mail that's otherwise landing in spam.

Can I use BIMI without a VMC or CMC?
Yes, for providers that don't mandate one (Fastmail, and historically some Yahoo/AOL rollouts), a logo-only BIMI record can display. Gmail and Apple Mail currently require a VMC or CMC - without one, your logo simply won't render in those clients, even though the rest of your record is valid.

What's the difference between a VMC and a CMC?
A VMC requires your logo to correspond to a registered trademark, verified against trademark registries by the issuing CA. A CMC is a lighter alternative that verifies your organisation's established use of the mark without requiring formal trademark registration - useful if you have a genuine, in-use brand mark but haven't (yet) registered it as a trademark.

Do I need a different logo for BIMI than the one on my website?
Not necessarily the artwork itself, but the file format is different: your website logo is very likely a PNG, standard SVG, or embedded font glyph, none of which meet the SVG Tiny P/S restrictions BIMI requires. You'll need to produce a dedicated, validated SVG Tiny P/S export specifically for BIMI, even if the visual design is identical to your existing brand mark.

Can I run BIMI on a subdomain rather than my root domain?
Yes. Publish the BIMI record (and ensure DMARC enforcement) at the exact hostname used in the From: address of the mail stream you want the logo on - for example, default._bimi.marketing.example.com for mail sent from @marketing.example.com.

What happens if I change my logo later?
With hosted BIMI, re-upload the new SVG on the BIMI page - the served record updates automatically and your DNS CNAME doesn't need to change. With the manual/self-hosted route, replace the file at the existing URL (or update the l= tag if the URL changes) and be mindful of any receiver-side caching delaying the visible update.

Do I need a separate selector per mail platform?
No - one default selector covering your primary sending identity is sufficient for almost every organisation. Multiple selectors are only useful if you deliberately want different logos/certificates for different sending contexts, or you're doing a staged credential rotation.

Will BIMI work if my DMARC policy is p=quarantine but not p=reject?
Yes - p=quarantine at pct=100 meets the enforcement bar most receivers require for BIMI, provided your legitimate mail streams are genuinely passing alignment (quarantine still moves failing mail to spam, which is real enforcement, just less strict than outright rejection). p=none does not qualify under any circumstances.

Can I test BIMI before going fully live with DMARC enforcement?
You can prepare and validate your logo, obtain your VMC/CMC, and even publish the BIMI CNAME ahead of time - but don't expect any mailbox provider to actually display the logo until your DMARC policy is genuinely enforcing at effectively 100%. Some receivers may cache a "not eligible" result from an early check, so it's often cleaner to finish DMARC enforcement first and add BIMI once that's stable.

Where do I check overall authentication health across DMARC, SPF, DKIM, MTA-STS and BIMI together?
Use Audit for a single consolidated view, and Alerts if you want to be notified automatically when something regresses (a new unaligned sender, an expiring certificate reference, and so on).

Is BIMI free to set up?
The DNS record and the SVG logo hosting are free through your DMARC Engine plan once you have a domain added - see Domains. The VMC or CMC certificate itself is a paid product from the issuing CA (DigiCert or Entrust), independent of your DMARC Engine subscription, and pricing is set by the CA rather than by us.

Does every sending platform (marketing tool, helpdesk, invoicing software) need to support BIMI separately?
No - BIMI is evaluated per authenticated sending domain, not per platform. As long as each platform sending on your behalf is properly aligned under your DMARC policy (via SPF and/or DKIM), the same BIMI record covers all of them. If a specific platform sends from a distinct subdomain, confirm that subdomain also meets the DMARC enforcement bar.

Can I preview how my logo will look before going live?
Yes - open the validated SVG file directly in a browser and shrink the browser zoom, or use your design tool's export preview at a small pixel size, to approximate inbox rendering. The BIMI page also renders a preview of the uploaded logo once accepted.

What happens to BIMI if I later have to roll DMARC enforcement back to p=none (for example, after discovering an unaligned sender causing delivery problems)?
Your logo will stop appearing at supporting mailbox providers until enforcement is restored, because the DMARC check happens on every BIMI evaluation - it isn't a one-off gate. The BIMI DNS record itself can stay published; it simply won't be honoured while your policy is below the enforcement bar.

Keeping BIMI healthy over time

BIMI isn't a "set once and forget" record in the way a static TXT value might be - three things can quietly break it after a successful launch, and it's worth building a light routine around each:

1. DMARC drift. A new marketing tool, a migrated helpdesk, or a forgotten legacy sender can start failing alignment months after your initial rollout, pulling your effective enforcement below the bar receivers expect. Review Analytics periodically, and consider turning on Alerts so a newly-failing source surfaces automatically rather than being discovered only when someone asks "why did our logo disappear?"
2. Certificate expiry. VMCs and CMCs are issued for a fixed term and must be renewed with the issuing CA before they lapse. Track the expiry date the same way you'd track a TLS certificate renewal, and update the reference on the BIMI page as soon as the replacement is issued.
3. Brand refreshes. If your organisation updates its logo, remember BIMI needs its own re-export and re-validation to SVG Tiny P/S - it won't automatically pick up a new PNG or standard SVG dropped into your marketing site. Re-upload the refreshed artwork on the BIMI page; with hosted BIMI the DNS record stays untouched.

None of this requires ongoing DNS work under the hosted model - the CNAME you publish once continues to point at DMARC Engine regardless of how many times the underlying logo or certificate reference changes on our side.

Related guides

• Hosted DMARC - the enforcement prerequisite for BIMI
• Hosted SPF - aligning sending sources and flattening includes
• Hosted DKIM - signing keys and selectors
• Hosted MTA-STS - transport security to pair with your authentication stack