Apple is distrusting Entrust CA and VMCs because affected VMCs chain to Entrust public roots that Apple marked untrusted for new issuance after November 15, 2024. This is a certificate trust-store decision, not mainly an Apple Branded Mail decision. The same change reaches TLS, S/MIME, timestamping, client authentication, and BIMI/VMC certificates when they chain to affected Entrust roots.
The practical answer is simple: if your Entrust VMC was issued on or before November 15, 2024, plan to replace it before it expires. If you need a new, renewed, rekeyed, or reissued certificate after that cutoff, choose a non-Entrust-rooted path such as DigiCert, GlobalSign, SSL.com, or Sectigo, then retest BIMI in Apple Mail and the other inboxes your audience uses.
The direct answer
Apple's distrust is about root trust and certificate issuance dates. Entrust's notice states that Apple will no longer support TLS, S/MIME, timestamping, and VMC certificates issued from Entrust public roots after November 15, 2024. Sectigo's analysis also calls out the unusual scope: Apple extended the distrust beyond browser TLS into email certificate use cases, including VMC.
That matters because BIMI depends on more than a DNS record and an SVG logo. When a mailbox provider requires a VMC, the certificate must chain to a trusted public root. If Apple no longer trusts that chain for certificates issued after the cutoff, Apple clients can reject the VMC evidence even when the BIMI TXT record, logo file, and DMARC policy look correct.
Do not reissue blindly
The risky move is rekeying or reissuing an older Entrust-rooted VMC without checking the resulting issuance date and chain. The old certificate can still be accepted until expiry, but the replacement can fall after Apple's cutoff.
- Check issuance date: Confirm whether the current VMC was issued on or before November 15, 2024.
- Check certificate chain: Verify whether the PEM chains to an affected Entrust public root.
- Check inbox scope: Test Apple Mail separately from Gmail and Yahoo because each provider applies its own display rules.
Entrust-rooted VMC risk by issue date
Use the certificate issue date as the first triage filter, then confirm the chain and BIMI result.
Issued before cutoff
Lower risk
Plan replacement before expiry.
Issued on cutoff date
Review
Confirm chain and Apple behavior.
Issued after cutoff
High risk
Replace with a trusted non-Entrust-rooted path.
Why VMCs are in scope
A VMC is an X.509 certificate used as evidence that a brand controls a logo for BIMI. Because it is a public certificate, it depends on the same trust-store model that makes browsers and email clients accept or reject certificate chains. Apple controls the root store used across its platform, so its distrust policy has consequences beyond Safari.
BIMI display depends on DMARC, DNS, logo hosting, VMC hosting, and certificate trust.
This is why the Apple change surprised teams that only thought about BIMI as a marketing logo program. Apple Branded Mail and Apple Business Connect can affect Apple-specific brand display, but they do not replace a trusted VMC for BIMI across the mailbox providers that require one. Apple requirements still need to be handled as their own Apple-facing layer.
Branded Mail assumption
- Apple-only scope: This would affect only Apple's own brand-logo program.
- No certificate concern: The BIMI PEM file would remain a normal mailbox-provider issue.
- Limited migration: The team would update Apple brand settings and leave VMC alone.
Certificate trust reality
- Root-store scope: Apple is changing trust for certificates issued from affected roots.
- VMC evidence risk: A valid-looking BIMI record can fail if the certificate chain is not trusted.
- Replacement path: The clean fix is a new mark certificate from a trusted chain.
What to replace Entrust with
The realistic alternatives are specific. For a VMC or CMC path, start with DigiCert, GlobalSign, SSL.com, or Sectigo. If the problem is only Apple logo display, Apple Business Connect is also relevant, but I would not treat it as a VMC replacement because it does not solve Gmail and Yahoo BIMI certificate requirements.
DigiCert CertCentral screen for managing mark certificates.
|
|
|
|---|---|---|
DigiCert VMC or CMC | Teams wanting the conservative, widely used route. | Higher visible cost, but mature validation workflow. |
GlobalSign Mark Certificate | Brands that want API-friendly certificate operations. | Validation details vary by region and mark type. |
SSL.com Mark Certificate | Teams comparing VMC, CMC, and government options. | Confirm provider display rules before relying on CMC. |
Sectigo VMC or CMC | Entrust customers moving through a Sectigo route. | Confirm the final chain before issuance. |
Apple Business Connect | Apple-specific brand presentation. | Does not replace BIMI VMC needs elsewhere. |
No certificate yet | Early BIMI DNS testing. | Logo display remains limited. |
Practical replacement choices for Entrust-rooted VMC risk.
For the deeper vendor question, compare VMC vendors by chain, validation friction, logo hosting, renewal handling, and support. For the policy question, the VMC requirement still depends on the mailbox provider, and the DNS record is only one input.
My default order of operations is to preserve the existing working VMC until the replacement is validated, then switch the BIMI record during a low-risk window. Do not remove the current PEM URL early. A broken BIMI record is easy to create and annoying to diagnose because mailbox providers cache results.
Migration steps
I handle the migration as a certificate replacement plus an email-authentication check. The VMC is only one piece. BIMI display also depends on DMARC enforcement, SPF or DKIM alignment, DNS correctness, HTTPS hosting, SVG formatting, and recipient-side support.
Flowchart for moving from an Entrust-rooted VMC to a trusted replacement.
- Inventory certificates: Find every BIMI record, VMC PEM URL, logo URL, and sending domain that uses the brand.
- Confirm the chain: Open the PEM and check issuer, root, validity dates, and issue date.
- Select the replacement: Choose DigiCert, GlobalSign, SSL.com, or Sectigo based on validation fit and chain trust.
- Validate DMARC: BIMI needs enforcement, usually p=quarantine or p=reject with aligned authentication.
- Stage the files: Host the new SVG and PEM over HTTPS, then test access without redirects that break validation.
- Switch and monitor: Update the BIMI TXT record, seed test mailboxes, and watch authentication reports.
DMARC enforcement exampleDNS
Host: _dmarc.example.com Type: TXT Value: "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=s"
Before buying the replacement certificate, run the domain through a DMARC checker. If the record is missing or still at monitoring mode, use a record generator to create a clean starting point, then move to enforcement only after legitimate senders are authenticated.
BIMI record after certificate replacementDNS
Host: default._bimi.example.com Type: TXT Value: "v=BIMI1; l=https://e.co/bimi.svg; a=https://e.co/vmc.pem;"
Where Suped fits
Suped is not a certificate authority, so it does not issue the VMC. Suped's product handles the authentication and monitoring layer around it: DMARC monitoring, SPF, DKIM, hosted policy management, alerts, and deliverability signals. For most teams, that makes Suped the best overall DMARC platform to run before and after a VMC migration.
The reason is practical. A certificate replacement does not fix bad alignment, unknown senders, missing DKIM signatures, or an SPF record that breaks the lookup limit. Suped surfaces those issues in one place and turns aggregate DMARC data into specific source-level fixes.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For a team already close to enforcement, Suped's Hosted DMARC can simplify policy staging and reduce DNS changes. Hosted SPF helps when sender management is the blocker, and blocklist (blacklist) monitoring gives reputation context during a visible brand-logo rollout.
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
The workflow I prefer is to use the domain health result as a readiness gate. If DMARC, SPF, and DKIM are clean, proceed with the mark certificate order. If they are not clean, fix authentication first. A trusted VMC attached to a weak authentication setup gives the team a false sense of progress.
Checks before you switch
The highest-risk part of this work is assuming a successful DNS lookup means the logo will display everywhere. BIMI validation is layered. A mailbox provider can accept DMARC and still reject the logo because of SVG rules, PEM hosting, chain trust, certificate expiry, or provider-specific support.
Pre-switch checklist
- DMARC policy: Use enforcement at the organizational domain and check subdomain inheritance.
- Authentication alignment: Confirm that important mail passes aligned SPF or aligned DKIM.
- Logo format: Use a BIMI-compatible SVG and verify that the URL returns the expected content type.
- Certificate evidence: Confirm the new PEM chain, subject details, expiry, and public availability.
- Mailbox tests: Send real messages to Apple Mail, Gmail, Yahoo, and any other important audience domain.
I also recommend keeping a small change log with the old BIMI TXT value, the old PEM URL, the new PEM URL, the certificate serial number, and the exact time DNS changed. When a logo disappears for a subset of recipients, that record cuts the troubleshooting time sharply.
The DigiCert FAQ is useful for the broader certificate distrust timeline, especially where teams also have Entrust-rooted TLS inventory. Keep the BIMI project connected to the wider PKI inventory so the brand team is not the only group discovering certificate risk.
Views from the trenches
Best practices
Inventory VMC issue dates and chain names before changing DNS or asking teams to test logos.
Move DMARC to enforcement before buying a mark certificate, not after validation starts.
Keep the old PEM hosted until replacement passes in Apple Mail, Gmail, and Yahoo test inboxes.
Common pitfalls
Reissuing an old Entrust VMC can create a certificate that falls after Apple's cutoff date.
Treating Apple Business Connect as a BIMI replacement leaves Gmail and Yahoo needs unsolved.
Changing the BIMI TXT record before the new PEM is public creates avoidable logo failures.
Expert tips
Ask the issuer to confirm the root chain before payment instead of relying on the quote.
Test with a real campaign seed message because inbox rendering can lag behind DNS propagation.
Document the renewal owner since mark certificates have short validity and brand dependencies.
Expert from Email Geeks says Apple including VMCs changes the risk calculation because BIMI depends on root trust rather than mailbox-provider logo rules alone.
2024-12-31 - Email Geeks
Expert from Email Geeks says certificates issued before the cutoff are not a crash emergency, but replacement planning should start before renewal pressure arrives.
2024-12-31 - Email Geeks
My practical recommendation
If you already have an Entrust-rooted VMC issued on or before November 15, 2024, keep it running while you plan the replacement. Do not create risk by reissuing early without confirming the new chain. Treat the expiry date as your hard deadline and complete the replacement well before then.
If you are issuing now, choose a currently trusted mark certificate path and validate the whole BIMI stack before launch. DigiCert is the most common conservative move I see for VMC replacement, but GlobalSign, SSL.com, and Sectigo are real alternatives when their validation process fits your trademark, logo, and support needs.
The certificate choice matters, but the bigger failure mode is weak email authentication underneath it. Get DMARC enforcement, aligned DKIM, clean SPF, and sender inventory under control first. Then the VMC change is a controlled migration instead of an inbox-logo scramble.
