BIMI with Amazon SES: Complete Implementation Guide (VMC, SVG, DMARC)

Amazon SES documents Using BIMI in Amazon SES as an authentication-adjacent branding layer: supporting mailbox providers may show your logo next to messages that already pass DMARC. Across 2024–2025, major providers also tightened bulk-sender rules (SPF/DKIM alignment, published DMARC, working unsubscribe flows) — so the authentication work that unlocks BIMI is work you likely need for inbox placement anyway (AWS bulk-sender guidance).

This is the AWS-ops decision guide: when to pursue BIMI on SES, how to sequence DMARC → assets → DNS, and which failures actually block logo display. It is not a guarantee that every inbox will show your logo — providers decide.

Artifacts: readiness checklist · readiness benchmark · DNS examples · SVG checklist · Terraform · CloudFormation · CDK · SES CLI · OpenSSL inspect · TCO worksheet

Free tools: BIMI Record Generator · SVG Validator · Readiness Checker

Benchmark pattern (not a cited client) — SES API v2 transactional sender, 1.2M emails/month, Easy DKIM + custom MAIL FROM, starting DMARC p=none. After p=quarantine; pct=100, publishing default._bimi, and fixing logo Content-Type to image/svg+xml on CloudFront, Readiness Checker score moved 38 → 92 / 100. Steady-state logo hosting ~$1.50–6/mo (S3 + CloudFront + Route 53) per tco-worksheet.csv; full steps in bimi-readiness-benchmark.md.

Reproduce this — Follow bimi-readiness-checklist.md. Run cli/ses-bimi-setup.sh, publish DNS from dns-record-examples.md, deploy hosting via Terraform/CDK with explicit SVG MIME, then score with the Readiness Checker.

Executive summary

BIMI (Brand Indicators for Message Identification) lets supporting inboxes show a brand logo on DMARC-authenticated mail. On Amazon SES you own authentication, asset hosting, and DNS; mailbox providers own whether the logo appears. That split is the entire architecture: SES will never “turn on BIMI” for you, and a perfect BIMI TXT will not fix a soft-fail DMARC policy.

What you gain: inbox brand recognition next to authenticated mail, a visual cue that competitors without enforcement cannot claim, and a forcing function to finish DMARC at pct=100 — which you often need for bulk-sender compliance anyway.

What you pay: engineering time to reach DMARC enforcement (usually the real cost), VMC/CMC fees when Gmail/Apple matter ($80–150/mo amortized for VMC per TCO worksheet), and small CloudFront/S3 hosting ($1.50–6/mo). SES send price does not change when you publish BIMI.

What we recommend:

1. Do not publish BIMI until DMARC is quarantine or reject at pct=100.
2. Host logo/PEM on private S3 + CloudFront OAC, not a public website bucket.
3. Budget VMC (trademark) or CMC if Gmail/Apple matter; self-asserted l= alone is usually not enough there.
4. Score with the Readiness Checker before spending on a CA.
5. Treat logo display as progressive enhancement — never as a deliverability SLA or a substitute for list hygiene.

Related SES pillars: Global Endpoints (MREP) · Tenant Management · SES consulting.

If you are mid-migration onto SES, finish identity and DMARC on the new From domain before you chase logos — BIMI on a domain you are about to abandon is wasted CA spend. See SendGrid → SES when the cutover itself is the project.

When to use BIMI

BIMI is a branding layer on top of authentication. If authentication is incomplete, BIMI is theater. Use the sender-profile matrix before you buy a certificate or open a DNS change ticket.

flowchart TD
  score[Score domain with Readiness Checker]
  score --> dmarc{DMARC enforce at pct 100?}
  dmarc -->|no| fixDmarc[Fix DMARC — do not publish BIMI]
  dmarc -->|yes| gmail{Gmail or Apple in scope?}
  gmail -->|yes| cert{VMC or CMC budget?}
  cert -->|no| defer[Defer or Yahoo-only experiment]
  cert -->|yes| ship[Validate SVG then OAC host then publish TXT]
  gmail -->|no| ship

If leadership asks “can we ship BIMI this sprint?” the honest answer is usually: only if DMARC is already at enforcement and the SVG is Tiny PS–valid. Certificate procurement and trademark confirmation are the long poles, not the Route 53 UPSERT.

A useful internal framing: BIMI is a release train, not a feature flag. Auth and DMARC are the platform; SVG/PEM are the release artifact; DNS is the cutover; inbox proof is acceptance testing. Teams that skip acceptance testing announce “BIMI is live” based on dig alone — then spend a week explaining why Gmail still shows a letter avatar.

How BIMI works

BIMI does not change how SES transmits mail. It adds a DNS advertisement that supporting receivers may fetch after DMARC passes.

sequenceDiagram
  participant App as Application
  participant SES as Amazon SES
  participant DNS as DNS
  participant MB as Mailbox Provider
  participant CDN as Logo Host HTTPS

  App->>SES: SendEmail / SMTP
  SES->>SES: Sign DKIM
  SES->>MB: Deliver message
  MB->>DNS: SPF / DKIM / DMARC checks
  MB->>DNS: Lookup default._bimi
  MB->>CDN: GET logo.svg
  MB->>CDN: GET certificate.pem
  MB->>MB: Validate SVG + cert + DMARC
  MB->>MB: Display logo or fallback avatar

1. App submits mail via SES API v2, SMTP, or SDK.
2. SES signs with Easy DKIM (or BYODKIM).
3. SPF may pass via custom MAIL FROM; DKIM should pass for the From domain.
4. DMARC evaluates alignment under an enforcement policy (quarantine or reject).
5. Supporting providers look up default._bimi.<domain>, fetch l= (and optional a=), validate SVG Tiny PS and certificate chain, then display or fall back to a generic avatar.

The practical implication: every BIMI “failure” that looks like branding is usually authentication, MIME, certificate expiry, or provider product policy. Start debugging at DMARC, not at the SVG designer.

Amazon SES and BIMI

AWS’s BIMI page is explicit about the boundary: SES helps you authenticate; you publish BIMI elsewhere.

Shared IPs are fine for BIMI. Dedicated IPs do not unlock logos. If someone on your team is blocking BIMI until “we get dedicated IPs,” they are conflating reputation tooling with brand indicators.

Requirements

BIMI’s hard gate is DMARC enforcement. SPF and DKIM are how you pass that gate with alignment.

DMARC rollout progression

Do not jump from p=none to BIMI in one change window. Use aggregate reports (rua=) to find shadow senders — marketing tools, ticket systems, HR platforms — before you enforce.

Reject sample with forensic reporting (optional; many orgs skip ruf= noise):

v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-agg@example.com; ruf=mailto:dmarc-forensic@example.com; fo=1

Expert tip — Publishing BIMI while pct is stuck at 10% is a common false start: dig looks fine, logos never appear. Finish pct=100 first.

Subdomains inherit parent DMARC unless they publish their own. AWS notes that subdomain BIMI generally expects parent enforcement (or matching subdomain enforcement). If you send as noreply.example.com but only _dmarc.example.com is p=none, fix the parent before you invent a BIMI record on the child.

Alignment notes that trip SES teams

DMARC passes when either SPF or DKIM aligns (unless you set stricter organizational policy). On SES, Easy DKIM alignment is usually the reliable path; custom MAIL FROM makes SPF alignment available when the MAIL FROM domain is a subdomain of the From organizational domain. If you send From: support@example.com but DKIM-sign a different domain, BIMI on example.com will not save you — fix signing first.

Also watch for multiple SPF TXT records on the same name (invalid), and for third-party tools that inject their own DKIM without aligning to your From domain. Those show up in rua= as fail volume long before anyone notices a missing logo.

VMC vs CMC

Mark certificates are the part of BIMI that feels like procurement, not DNS. Decide early so legal and brand teams are not surprised mid-sprint.

Self-asserted BIMI (l= only, no a=) is valid syntax with limited display. Use it for Yahoo experiments or internal demos — not as the Gmail production plan. Inspect PEMs with openssl-vmc-inspect.sh before you point a= at a file you have never opened.

The logo inside the certificate must match the hosted SVG. A redesign that updates S3 but not the CA-issued mark is a silent failure mode: dig and MIME look perfect; Gmail still refuses the logo.

Logo and hosting

SVG must be SVG Tiny PS / SVG P/S:

• version="1.2" and baseProfile="tiny-ps"
• Square viewBox (1:1)
• File ≤ 32 KB
• No scripts, animations, external refs, or embedded rasters
• Prefer a solid background (transparent often fails in clients)

Full rules live in svg-tiny-ps-checklist.md. Validate with the SVG Validator before you spend time on CloudFront.

Opinionated default: OAC over public S3 website. ACM certificates for the logo hostname must be in us-east-1 for CloudFront. Serve the logo as image/svg+xml; serve the PEM as application/x-pem-file or text/plain consistently. Prefer a dedicated hostname such as bimi.example.com so logo TTL and app CDN policies do not collide.

What broke — Lab publish day: SVG uploaded from the S3 console without Content-Type: image/svg+xml. CloudFront served binary/octet-stream. Dig showed a correct BIMI TXT, but the Readiness Checker logo check stayed at warn/fail. Detected with curl -sI. Fixed by CLI re-upload with --content-type image/svg+xml and invalidating /logo.svg (benchmark notes).

# AWS CLI v2 — set MIME explicitly after terraform/cdk apply
aws s3 cp logo.svg "s3://${BUCKET}/logo.svg" \
  --content-type "image/svg+xml" \
  --cache-control "public,max-age=86400"
aws s3 cp certificate.pem "s3://${BUCKET}/certificate.pem" \
  --content-type "application/x-pem-file" \
  --cache-control "public,max-age=86400"
aws cloudfront create-invalidation \
  --distribution-id "$DIST_ID" \
  --paths "/logo.svg" "/certificate.pem"

Deploy the bucket + distribution from Terraform, CloudFormation, or CDK — then always re-assert MIME on upload. Infrastructure-as-code creates the distribution; it does not magically fix a console upload with the wrong Content-Type.

Implementation phases

Six phases replace a 15-step console dump. Details live in artifacts; this section is the sequence and the decision gates.

Phase 1 — Auth (SES)

Verify the domain identity in every sending region you use. Enable Easy DKIM (or publish BYODKIM). Configure custom MAIL FROM with the SES-provided MX and an SPF TXT that includes include:amazonses.com.

Use ses-bimi-setup.sh with DOMAIN, REGION, and optional MAILFROM. Confirm DKIM Successful and MAIL FROM Success in the SES console before you touch DMARC policy. Wire configuration sets so bounce/complaint events are visible during the enforcement ramp.

If you already run multi-region SES (MREP / Global Endpoints), treat identity parity as part of Phase 1: a secondary region that lacks DKIM or MAIL FROM will fail DMARC on failover and make BIMI look “flaky” when the real bug is regional config drift. See the MREP enterprise guide.

Phase 2 — DMARC enforce

Publish _dmarc with p=none and a monitored rua= mailbox if you do not already have reports. Fix non-aligned senders. Ramp pct under quarantine, then land at pct=100. Move to reject only when quarantine is boringly clean.

Gate: do not publish default._bimi until enforcement is real. BIMI without this gate is a vanity TXT.

Practical rollout tips that keep change windows small:

• Lower _dmarc TTL before the first pct bump so rollback is fast.
• Raise pct in deliberate steps (10 → 25 → 50 → 100) only when aggregate fail volume is explained.
• Keep a named owner for the rua= mailbox — unread reports are how teams “surprise” themselves into quarantine pain.

Phase 3 — Assets

1. Export / design SVG Tiny PS; run the SVG Validator.
2. Deploy hosting (Terraform / CloudFormation / CDK).
3. Upload SVG (and PEM when required) with explicit MIME.
4. Invalidate CloudFront paths.
5. Confirm curl -sI shows 200 and the correct Content-Type over HTTPS.

If you need a VMC or CMC, start CA procurement in parallel with Phase 2 — certificate lead time often exceeds DNS lead time. Brand should freeze the mark that will appear in the certificate; a last-minute logo redesign after CA issuance means another PEM cycle.

Store the PEM next to the SVG on the same distribution so l= and a= share TLS, caching, and invalidation habits. Split hosts only when compliance forces it — dual-host setups double the MIME failure surface.

Phase 4 — BIMI DNS

Minimum DNS set for a typical SES domain:

Copy-paste shapes for Route 53, Cloudflare, GoDaddy, Namecheap, Google Domains, and DNS Made Easy live in dns-record-examples.md. Build the TXT string with the Record Generator so you do not hand-type semicolons wrong.

With certificate:

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

Logo only (limited display):

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

Subdomain senders publish default._bimi.<subdomain> and still need parent (or matching) DMARC enforcement. Prefer absolute HTTPS URLs in l= and a= — relative paths and HTTP schemes fail provider fetches.

After publish, verify with both authoritative dig and the Readiness Checker (DoH). A single recursive resolver that still caches NXDOMAIN is not proof the record is wrong worldwide.

Phase 5 — Proof

Score with the Readiness Checker — export the printable PDF if you need change-control evidence. Then send authenticated tests and log results with dates:

Allow reputation and cache time. A correct DNS publish on Monday does not imply Gmail logo on Monday afternoon. If Gmail shows no logo after 48–72 hours of authenticated volume, re-check PEM validity and SVG Tiny PS before opening a “SES is broken” ticket — SES is almost never the display layer.

Phase 6 — Operate

Steady-state work is boring and important: renew certificates, update logos without breaking MIME, and keep DMARC reports monitored. Use bimi-readiness-checklist.md §10 for logo update, cert renew, and emergency revoke runbooks. Review rua= weekly during rollout, monthly in steady state.

Calendar VMC/CMC renewal 30–45 days out. Expired PEMs are a high-visibility failure: dig still looks perfect, hosting still returns 200, and Gmail quietly drops the logo.

Testing and troubleshooting

flowchart TD
  start[Logo not showing]
  start --> dmarc{DMARC enforce and pass?}
  dmarc -->|no| fixDmarc[Fix policy or alignment]
  dmarc -->|yes| bimi{BIMI TXT present?}
  bimi -->|no| pub[Publish default._bimi]
  bimi -->|yes| https{HTTPS SVG and MIME OK?}
  https -->|no| host[Fix CloudFront or S3 Content-Type]
  https -->|yes| cert{Provider needs PEM?}
  cert -->|missing or expired| vmc[Issue or renew VMC or CMC]
  cert -->|ok| rep[Check cadence reputation and cache wait]

What broke — CloudFront custom error pages can turn PEM 403/404 into text/html. Providers then fail certificate parsing even though “the file is on S3.” Disable HTML error responses for /certificate.pem (and /logo.svg) and fix OAC so the origin returns real 404s only when the object is missing.

Expert tip — If you rotate SVG without changing the URL, some providers keep a failed validation cache. Prefer logo-v2.svg plus an updated l= after a bad publish, rather than hoping invalidation alone clears every mailbox cache.

When troubleshooting, keep a single evidence packet: dig TXT, two curl -sI transcripts, OpenSSL dates, Authentication-Results snippet, and the inbox matrix row. That packet closes most “is BIMI broken?” threads without another architecture review.

Costs

BIMI does not change SES per-message pricing. The bill you feel is certificate amortization plus a small hosting line item — and the engineering time to finish DMARC.

Model your own mix in tco-worksheet.csv. Year-1 engineering (DMARC cleanup + SVG + DNS + inbox proof) usually dwarfs hosting. If finance asks for ROI, frame it as brand trust on authenticated mail plus compliance progress on DMARC — not as a guaranteed open-rate lift.

Do not budget BIMI as a line item that “pays for itself in opens.” Budget it as the last mile of an authentication program you already need for bulk-sender rules — with logo display as the visible payoff when providers cooperate. That framing survives a quarter where Outlook still shows an avatar.

Enterprise patterns

For multi-brand portfolios, prefer one BIMI hostname with path-per-brand (/acme/logo.svg, /acme/certificate.pem) over dozens of ad-hoc buckets. Keep IAM and invalidation runbooks identical across brands so on-call does not invent a new procedure per logo.

Agencies and ESPs should treat BIMI as a customer-owned DNS deliverable: you host the SVG/PEM (or give them the Terraform module), you generate the TXT with the Record Generator, and they paste it into their registrar. Do not hold customer BIMI records in your corporate zone unless you also control their From domain — that coupling breaks the day they leave.

Tenant-management shops (one SES account, many customer domains) should automate Phase 1–4 per tenant the same way they automate DKIM CNAMEs today. Manual BIMI for the tenth customer is how MIME and PEM expiry bugs become systemic. Pair this guide with Amazon SES Tenant Management when isolation and reputation boundaries matter as much as branding.

FactualMinds expert recommendations

1. DMARC first, BIMI second — logo DNS without enforcement wastes CA money and burns stakeholder trust when logos never appear.
2. OAC hosting — treat public website buckets as a prototype only; production should be private origin + CloudFront.
3. MIME in CI — add a curl -sI Content-Type check after every logo deploy; the lab MIME failure is too easy to repeat.
4. Score before CA spend — Readiness Checker should be green on DMARC/BIMI/logo before you buy VMC/CMC.
5. Document provider reality — Outlook and corporate gateways may never show the logo; set expectations in the inbox matrix, not in a launch email that promises “branded inbox everywhere.”
6. Version logo URLs after bad publishes — logo-v2.svg beats hoping every provider honors invalidation.
7. Keep evidence — dig, curl, OpenSSL, Authentication-Results, and the printable Readiness PDF close audits faster than narrative status updates.

What to Do This Week

1. Run the Readiness Checker on your top sending domain.
2. If DMARC is p=none, start rua= monitoring and a pct rollout — do not publish BIMI.
3. Validate the logo in the SVG Validator.
4. Deploy S3 + CloudFront from the Terraform/CDK artifact; upload with explicit MIME.
5. Generate and publish TXT with the Record Generator.
6. Inbox-test Gmail and Apple Mail; wait out cache before declaring failure.
7. Work the full readiness checklist, including §10 runbooks.

What This Post Doesn’t Cover

• Purchasing a specific CA’s VMC/CMC SKU or filing a trademark
• Guaranteeing logo display at any provider
• Full DMARC XML parsing pipelines or automated rua dashboards
• Non-SES ESPs (except migration context — see SendGrid → SES)
• Designing the SVG itself beyond Tiny PS constraints (hand that to brand with the SVG checklist)

Official references: Using BIMI in Amazon SES · Custom MAIL FROM · Easy DKIM · DMARC in SES · Gmail BIMI help