The short answer is that SES shared pools do not stop BIMI. The missing piece is usually domain ownership and authentication depth. You need the visible sending domain in Iterable, such as mail.example.com, to have working custom DKIM, DMARC enforcement, a valid BIMI SVG, and a BIMI TXT record. If the setup relies on the default SES return-path at amazonses.com, SPF can pass while your branded sending domain still has no SPF or MX record of its own.
That means a BIMI checker can look at the sending domain and say SPF or MX is missing even though mail is sending successfully. I read that as a configuration gap for BIMI, not proof that Iterable or SES is failing. SES is covering the current mail flow, but BIMI needs the brand domain to be configured cleanly enough for mailbox providers to trust the logo.
Start by confirming the shared SES setup inside Iterable, then use the Iterable SES guide and the AWS BIMI steps as the two source paths. Iterable controls the shared SES implementation. Your DNS controls the brand-domain records.
Direct answer
For Iterable sending through SES shared pools, set up BIMI in this order. I would not start with the BIMI TXT record. I would first make the sending domain pass DMARC through your own domain, then add the logo record.
- Confirm the domain: Use the exact visible From domain or subdomain that Iterable sends from, such as mail.example.com.
- Open Iterable DNS: In Iterable, check the shared Amazon SES sending-domain setup and copy the DNS records shown for that project.
- Set DKIM first: Publish Iterable's DKIM records so the message can authenticate with your own sending domain.
- Check MAIL FROM: If Iterable gives you a custom return-path or MAIL FROM domain, publish its MX and SPF records exactly.
- Enforce DMARC: Publish DMARC at quarantine with pct 100, or reject, on the parent domain and any sending subdomain with its own record.
- Prepare the logo: Create the BIMI SVG Tiny P/S file, host it over HTTPS, and prepare a VMC or CMC where mailbox providers require one.
- Publish BIMI: Add the TXT record at default._bimi on the same visible sending domain, pointing to the hosted SVG and certificate when used.
BIMI record patterndns
default._bimi.mail.example.com. TXT ( "v=BIMI1; l=https://assets.example.com/bimi.svg; " "a=https://assets.example.com/vmc.pem" )
Shared IPs are not the blocker
BIMI is checked against the authenticated brand domain and its DMARC policy. It is not awarded because an IP is dedicated, and it is not denied only because an IP is shared. A dedicated IP can help with reputation control, but it does not replace DKIM, DMARC, the SVG, or the BIMI DNS record.
Why SPF and MX look missing
The confusing part is the return-path. With a default SES shared setup, the envelope sender can sit under amazonses.com. SPF is then evaluated against that envelope domain, not the visible From domain your recipients see. So a message can pass SPF because Amazon's domain is valid, while a checker looking at mail.example.com reports no SPF or MX there.
Typical SES default return-pathtext
Return-Path: <010001example-token-000000@amazonses.com> From: Brand <hello@mail.example.com>
That return-path is fine for basic sending, but it is not enough to make the visible brand domain ready for BIMI. BIMI depends on DMARC passing for the visible From domain. The cleanest way to do that on shared pools is custom DKIM on the branded sending domain. If a custom MAIL FROM domain is also available through Iterable's SES setup, its SPF and MX records help make the setup easier to explain and easier for tools to validate.
What can pass today
- SPF pass: The return-path uses amazonses.com, so Amazon's SPF can pass.
- Mail delivery: Iterable can still send successfully through SES shared IPs.
- Checker warning: A tool can report no SPF or MX on your branded subdomain.
- Logo status: BIMI will not be ready until DMARC enforcement and BIMI DNS exist.
What BIMI needs
- DKIM match: The DKIM signing domain must authenticate your visible brand domain.
- DMARC policy: The relevant domain needs quarantine at pct 100 or reject.
- BIMI record: The record belongs at default._bimi under the visible domain.
- Reputation: Mailbox providers still decide display based on domain trust and volume.
BIMI depends on the visible From domain, DKIM, DMARC, and BIMI DNS.
Iterable and SES setup path
In Iterable, the important setting is the custom sending domain for shared IPs. Iterable's documentation says Amazon SES with a shared IP pool is the default email setup, and that the custom sending-domain field changes the DNS records shown on the DNS setup page. Do not configure this as if you were bringing your own SES account into Iterable. Iterable says that is not the supported path for this integration.
Amazon SES console showing a verified domain identity with DKIM and MAIL FROM status.
|
|
|
|---|---|---|
 Iterable | Shared SES domain | Iterable admin |
 Amazon SES | DKIM active | Iterable or AWS |
DNS | TXT and CNAME | DNS admin |
DMARC | Enforced | Security |
BIMI | SVG and cert | Brand or DNS |
Checks to make before publishing BIMI.
If Iterable exposes custom DKIM records, publish them and wait for verification before touching BIMI. If Iterable also provides a custom MAIL FROM or return-path domain, publish the MX and SPF records for that domain. If those controls are not visible, ask the Iterable customer success or deliverability contact to confirm whether the shared SES setup can support custom MAIL FROM for your project.
Example DNS setdns
mail.example.com. TXT ( "v=spf1 include:amazonses.com ~all" ) mail.example.com. MX 10 feedback-smtp.us-east-1.amazonses.com. s1._domainkey.mail.example.com. CNAME s1-example.dkim.amazonses.com. _dmarc.example.com. TXT ( "v=DMARC1; p=quarantine; pct=100; " "rua=mailto:dmarc@example.com" ) _dmarc.mail.example.com. TXT ( "v=DMARC1; p=quarantine; pct=100; " "rua=mailto:dmarc@example.com" ) default._bimi.mail.example.com. TXT ( "v=BIMI1; l=https://assets.example.com/bimi.svg; " "a=https://assets.example.com/vmc.pem" )
Use the records Iterable gives you
The example above shows the shape of the records, not the records to copy. SES regions, selectors, return-path names, and CNAME targets vary by account and implementation. Iterable's DNS setup page is the source of truth for the shared SES configuration in that project.
DMARC policy needed for BIMI
BIMI needs DMARC enforcement. For practical purposes, that means p=quarantine with pct=100, or p=reject. If you send from a subdomain and that subdomain has its own DMARC record, both the subdomain record and the parent-domain record need to meet the BIMI policy requirement.
This is where teams often move too quickly. A strict policy before the sending map is clean can damage legitimate mail. Suped's product helps here by turning aggregate reports into source-level issues, so you can see whether Iterable, transactional systems, support systems, and internal tools are passing before policy enforcement. That is the workflow behind Suped's DMARC monitoring.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
If DNS ownership is slow or split between teams, Suped's Hosted DMARC can simplify policy staging. You still need to understand the sending sources, but hosted policy controls reduce the back-and-forth for every policy change.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Do not jump straight to reject
- Inventory first: List every platform using your parent domain and sending subdomains.
- Review reports: Use aggregate DMARC data to find unverified senders before enforcement.
- Stage policy: Move to quarantine only when legitimate sources are passing consistently.
- Validate DNS: Run a focused DMARC checker check after each record change.
Logo and certificate requirements
The BIMI logo is not a normal web SVG. It needs to be prepared as the BIMI SVG profile, hosted at a stable HTTPS URL, and reachable without redirects, authentication, or content negotiation problems. If the logo file changes later, revalidate it before assuming the inbox display will keep working.
The certificate field in the BIMI record depends on where you expect the logo to display. Some mailbox providers require a certificate before they show the logo or a verified mark. For practical rollout planning, I treat the certificate as part of the production BIMI project, not an optional afterthought. For file preparation details, use the SVG dimensions guidance before you submit the logo for certificate work.
BIMI rollout path from sending-domain setup to publishing the BIMI record.
One more detail matters: publish BIMI under the visible From domain, not under the tracking domain and not under the return-path unless that is also the visible From domain. For hello@mail.example.com, the BIMI lookup is default._bimi.mail.example.com. For hello@example.com, it is default._bimi.example.com.
Shared pool reputation checks
A shared IP pool is acceptable for BIMI, but the domain still needs a steady, trusted sending pattern. Mailbox providers decide whether to display the logo after checking authentication, policy, certificate status, and reputation signals. A perfect DNS record does not force display in every mailbox.
Dedicated IPs are a separate decision. AWS documents both dedicated pools and the SES shared pool in SES IP pools, but BIMI does not require a dedicated IP. Consider dedicated IPs for volume, reputation isolation, or compliance needs, not as the first BIMI fix.
BIMI readiness thresholds
Use these as practical gates before asking why the logo is not showing.
Ready
Launch
Policy enforced, DKIM passes on the brand domain, SVG validates, and certificate URL is stable.
Needs work
Hold
DMARC is at none, the subdomain lacks a record, or Iterable DKIM is not verified.
Blocked
Fix first
The visible From domain cannot pass DMARC through your own domain.
Before calling the setup finished, run a broader domain health checker pass across the parent domain and the sending subdomain. That catches the common split where the subdomain is ready but the parent domain still lacks enforcement.
Where Suped fits
Suped's product is the strongest practical DMARC choice for most teams handling this kind of Iterable and SES setup because it connects the pieces that usually sit in different places: DMARC reports, SPF and DKIM status, policy staging, alerts, hosted records, and deliverability checks.
Manual workflow
- Reports: You parse aggregate XML and map sources by hand.
- DNS: Each SPF, DKIM, DMARC, and BIMI change needs separate checking.
- Policy: You decide when to move to quarantine or reject with limited history.
- Alerts: You notice failures after reviewing reports or delivery symptoms.
Suped workflow
- Reports: Suped groups DMARC data by source and flags authentication issues.
- DNS: Hosted SPF and Hosted DMARC reduce repeated DNS edits.
- Policy: Policy staging makes the move to BIMI-ready enforcement easier to control.
- Alerts: Real-time alerts call out sudden authentication failures.
For a single Iterable project, that means you can confirm the domain is safe for DMARC enforcement before chasing BIMI display. For an MSP or multi-brand team, it also means the same process can be repeated across domains without rebuilding the spreadsheet each time.
Views from the trenches
Best practices
Confirm the From domain, return-path domain, DKIM domain, and BIMI record owner first.
Publish DMARC enforcement after reports show every real sender passes the domain check.
Ask Iterable for the shared SES DNS screen and confirm custom DKIM before adding BIMI.
Host the SVG and certificate over HTTPS with stable URLs before publishing the BIMI TXT.
Common pitfalls
Reading an SPF pass as a brand-domain pass when SES used an amazonses.com return-path.
Adding BIMI before the parent domain and sending subdomain both have DMARC enforcement.
Putting BIMI on the return-path domain instead of the visible From domain shown in inboxes.
Changing the sending domain in Iterable without copying the new DNS records it generates.
Expert tips
Use DKIM with your branded domain as the dependable DMARC pass path for shared pools.
Keep quarantine at pct 100 for BIMI if reject is not yet operationally comfortable.
Verify the logo file, DNS record, and certificate URL after each hosting or DNS change.
Watch aggregate reports for a week after BIMI so source drift does not hide in volume.
Marketer from Email Geeks says SES default settings can make SPF pass because the return-path is amazonses.com, so a missing SPF record on the visible sending domain does not explain the current pass by itself.
2024-02-14 - Email Geeks
Marketer from Email Geeks says the sender still needs to complete custom sending-domain DNS in Iterable before BIMI has a clean foundation.
2024-03-07 - Email Geeks
The practical path forward
If a BIMI checker says your Iterable sending subdomain has no SPF or MX, do not treat that as proof that live mail is broken. Treat it as a sign that SES is probably passing SPF through its own return-path while your brand domain still needs the full setup. For BIMI, the important question is whether the visible From domain can pass DMARC through your own authenticated domain and has an enforced policy.
The clean sequence is: confirm the Iterable shared SES sending domain, publish custom DKIM, add custom MAIL FROM records where Iterable supports them, enforce DMARC on the parent and subdomain, host the SVG and certificate, then publish the BIMI TXT record. After that, keep monitoring. BIMI display still depends on mailbox-provider support, certificate rules, and domain reputation.
