Fetched BIMI logo lacks ShipReady's basic SVG signal
ShipReady received HTTP 200 from the selected BIMI logo URL but found neither an SVG content type nor an SVG element near the start of the bounded response body.
Why it matters
The logo URL in a BIMI record should be reviewed when its observed response does not even meet this basic SVG signal. A positive signal is not full BIMI validation, and a finding does not diagnose the deployed logo format beyond the tested response.
How ShipReady detects it
What it inspects
ShipReady makes one bounded request to the HTTPS l= URL from a selected BIMI record and evaluates only a successful HTTP 200 response.
What triggers a finding
The rule triggers when the response Content-Type does not contain svg and the first 512 left-trimmed response characters do not contain the literal SVG opening-tag marker. An SVG tag suppresses the finding even if the Content-Type is not SVG.
What the evidence shows
The successful bounded response lacked ShipReady's two basic SVG signals.
Limits of this check
ShipReady does not parse or validate SVG XML, verify the SVG Tiny P/S profile, inspect certificates or BIMI certificates, or establish whether a mailbox provider accepts or displays the logo.
How to fix it
Inspect what the URL actually serves
Request the exact l= URL and confirm it serves the intended logo rather than an HTML error page, a different image format, or an empty response.
Validate the logo for BIMI separately
Use a BIMI-aware validator or provider guidance to check profile and certificate requirements beyond ShipReady's basic response sniff.
How to verify the change
Verify the deployed logo response
Request the published URL after deployment and validate the delivered file with tooling appropriate to BIMI.
Expected: The URL serves the intended logo and independent BIMI validation succeeds where required.