Check BIMI requirements by verifying enforced DMARC, aligned authentication on actual messages, a compliant logo file, the receiving provider’s certificate rules, and the published BIMI record. In 2026, passing those checks establishes readiness for provider evaluation; it does not guarantee an inbox logo or inbox placement.
- BIMI requirements establish eligibility for logo display, not a guarantee that receiving providers will display it.
- DMARC enforcement must cover all messages; monitoring-only policy does not meet BIMI requirements.
- SCOUTz supports MSP prospect preparation with dated cybersecurity evidence; public findings do not establish tenant configuration.
- Separate DNS observations, message authentication, certificate validation, and actual display tests in your evidence packet.
How do you check BIMI requirements before promising an inbox logo?
Use a dated checklist that follows the sending domain through authentication, logo validation, publication, and receiver testing. Keep the domain, selector, evidence source, and observation date attached to each result. The broader SPF, DKIM, and DMARC assessment explains why a DNS lookup alone cannot establish the condition of every sending service.
1. Identify the domain recipients actually see
Start with the domain in the visible From address. Record the sending services that use it, including marketing platforms, support systems, and transactional applications. An inventory supplied by the customer establishes scope; discovering an SPF record does not establish that the inventory is complete.
Keep subdomains separate where their sending configurations differ. A parent-domain observation does not prove that every subdomain publishes the same records or follows the same authentication path.
2. Verify effective DMARC enforcement
BIMI requires an enforcement policy of p=quarantine or p=reject, with enforcement applying to 100% of messages. A p=none policy requests monitoring rather than enforcement and does not satisfy this prerequisite. Where the DMARC percentage tag applies, a setting below pct=100 does not meet the full-enforcement requirement.
Record the effective policy for the sending domain, including inherited policy where relevant. Keep the raw DNS response and lookup date. Before changing enforcement, identify legitimate senders and examine their authentication results; publishing a stricter policy is a configuration change with delivery consequences.
| DMARC policy | BIMI prerequisite | What it establishes | Limit |
|---|---|---|---|
p=none | Does not satisfy enforcement | Domain requests monitoring | Does not request quarantine or rejection |
p=quarantine at full enforcement | Satisfies the enforcement prerequisite | Domain requests suspicious-message handling for failures | Does not establish message alignment or logo display |
p=reject at full enforcement | Satisfies the enforcement prerequisite | Domain requests rejection of failures | Does not establish message alignment or logo display |
DMARC enforcement is an eligibility condition, not proof that every legitimate sender is configured correctly. Treat it as one row in the review.
3. Check authentication on actual messages
Inspect receiver-generated authentication results from authorized test messages. DMARC passes when an authenticated SPF or DKIM identity aligns with the visible From domain. Merely publishing SPF and DKIM records does not prove that the messages under review pass DMARC.
As a review procedure, collect at least 2 test messages from different legitimate sending services when those services exist. This is a sampling recommendation, not a BIMI standard or a claim of complete coverage. Record the service, recipient provider, delivery date, and authentication result for each sample.
4. Validate the logo asset
BIMI uses a constrained SVG profile, commonly described as SVG Tiny Portable/Secure, or SVG Tiny PS. A file ending in .svg is not sufficient evidence of compliance. Check the SVG profile, square presentation, and restrictions on scripting and external dependencies against the BIMI Group’s published guidance.
Confirm that the referenced asset is retrievable over HTTPS. Preserve the validation result and asset identity so a later file replacement does not inherit an earlier approval. A logo that looks correct in a browser still needs format validation.
5. Check the receiving provider’s certificate rules
List the mailbox providers that matter to the customer. For each provider, consult its own BIMI documentation during the 2026 review and record whether it requires a supported mark certificate, which certificate types it accepts, and any additional sender conditions.
Verified Mark Certificates and Common Mark Certificates have different validation requirements, and acceptance depends on the receiver. Keep certificate eligibility separate from ordinary HTTPS hosting. A valid web-server certificate does not establish that the logo meets a receiver’s mark-certificate requirements.
6. Inspect the BIMI DNS record
For the default selector, inspect the TXT record at default._bimi beneath the sending domain. The record uses v=BIMI1; the l= tag identifies the logo location, and the a= tag identifies supporting authority evidence where required.
Check syntax, destination accessibility, and consistency with the selected certificate and logo. If the sender uses another selector, review that selector explicitly. A published BIMI record proves publication at the lookup time, not acceptance by every mailbox provider.
7. Test display and record the boundary
Send authorized test messages to the receiving providers in scope. Record whether the logo appeared, which account or application displayed it, and when the observation occurred. Keep display evidence alongside authentication results rather than replacing them with a screenshot.
If a logo does not appear, record that outcome without assigning an unsupported cause. The receiver’s eligibility rules, reputation assessment, interface support, and processing behavior remain separate from DNS validity. A successful test describes that test environment, not universal display.
Why this matters
An inbox logo is a visible outcome controlled partly by the receiving service. Your MSP controls the work it performs, the configuration it changes with approval, and the evidence it records. It does not control every recipient interface.
For a 2026 proposal, define the deliverable as a readiness review, approved configuration work, and documented receiver tests. Keep the acceptance criteria tied to those deliverables. That gives the customer a clear result without making a display promise outside your control.
A missing logo is also a poor opening for a security accusation. It does not establish compromise, negligence, or an unresolved business problem. Establish the customer’s intended outcome before recommending a project.
Why BIMI readiness varies
Separate these factors in the assessment. Each has a different owner and a different proof requirement.
- Authentication coverage: Different sending services can produce different alignment results. Sample the services in scope and record the untested ones.
- Effective DMARC policy: Parent-domain policy, subdomain policy, and enforcement settings affect the prerequisite review. Record the effective result, not just a familiar-looking TXT string.
- Logo compliance: SVG structure and HTTPS accessibility require separate checks. A successful download does not establish profile compliance.
- Certificate acceptance: Receiver requirements determine which mark evidence is accepted. Confirm the intended providers before recommending certificate work.
- Receiver decisions: Provider eligibility, reputation checks, and supported interfaces affect display. A sender-side pass cannot settle these decisions.
- Change ownership: DNS, brand assets, certificates, and sending platforms often have different administrators. Identify who can approve and implement each change.
Turn the review into evidence, insight, and proof
A useful MSP handoff separates what was observed from what the customer should decide. In your 2026 worksheet, give every condition a source, a date, an affected object, an evidence state, and a coverage statement.
Evidence
Save the DNS response, the effective DMARC policy, the logo-validation output, and the authentication results from authorized messages. Attach the receiver documentation consulted and its access date. Describe the actual scope: public DNS, customer-supplied messages, or customer-authorized internal evidence.
Use Observed for a condition seen in the collected evidence. Use Unknown or Unreadable where the evidence cannot support a conclusion. Coverage belongs in a separate field, such as Assessed, Partial, or Not assessed. These labels describe different dimensions, not a score ladder.
Insight
Translate the condition into a bounded consequence. A monitoring-only DMARC policy means the enforcement prerequisite is unmet at the observation time. It does not prove that spoofing succeeded or that the domain owner intended to pursue BIMI.
Identify the owner and the next choice. That might be reviewing authentication coverage before enforcement, validating a supplied logo, or checking certificate eligibility. Keep the recommended outcome separate from the vendor selected to perform the work.
Proof
Pin the original evidence as the baseline. After an approved change, perform 1 baseline comparison for the affected check and retain the new run date. This is a recommended verification practice, not a prescribed BIMI test count.
Report precisely what changed: the effective policy, the asset validation result, the published record, or the observed display outcome. If receiver display remains untested, keep that field untested.
Keep public observations separate from internal evidence
Public DNS can expose a published DMARC policy and BIMI record. Public HTTPS retrieval can establish whether a referenced asset was reachable during the check. Neither source establishes how every legitimate message authenticates.
Customer-supplied message headers add evidence about specific deliveries. Customer-authorized Microsoft 365 configuration reviews have another scope again. Public domain observations cannot establish Conditional Access coverage, application permissions, license assignments, or tenant sharing configuration.
SCOUTz cybersecurity prospect intelligence is best for MSPs preparing sales conversations with dated evidence and account context. SCOUTz prepares the conversation; the relationship and the sale stay with the MSP. Use public findings to frame a bounded discovery topic, with tenant evidence collected only through the appropriate authorization.
The boundary matters here: this workflow does not establish that SCOUTz performs a dedicated BIMI certification or guarantees logo display. For MSPs evaluating its prospect-preparation workflow, Join Open Beta is the primary next step. Confirm current product scope before including a specific check in a proposal.
Can you promise a logo after every check passes?
Passing the sender-side BIMI requirements does not guarantee logo display. State that the reviewed domain meets the documented prerequisites within the assessed scope, then describe the receiver tests separately. Avoid extending a successful result to untested providers or interfaces.
Is DMARC enforcement enough for BIMI?
DMARC enforcement covering 100% of messages satisfies an authentication-policy prerequisite, not the complete BIMI review. Logo format, record publication, supported certificate evidence, message authentication, and receiver conditions still require assessment.
What should the customer approve before changes begin?
The customer should approve the sending-domain scope, intended outcome, configuration changes, and verification plan. Your 2026 statement of work should also identify DNS, messaging, and brand-asset owners. Separate readiness work from any ongoing monitoring commitment.
FAQ
What are the main BIMI requirements?
BIMI requires enforced DMARC, authenticated and aligned messages, a compliant SVG logo, and a correctly published BIMI record. Receiving providers also apply their own certificate and eligibility requirements, so passing sender-side checks does not guarantee display.
Can I use BIMI with a DMARC policy of p=none?
A DMARC policy of p=none does not satisfy BIMI’s enforcement prerequisite. Review legitimate sending services and authentication results before approving a move to quarantine or reject.
Do I need both SPF and DKIM to pass DMARC?
DMARC can pass through aligned SPF or aligned DKIM. Check actual receiver-generated authentication results because published DNS records alone do not prove that either mechanism passes for a message.
Does every mailbox provider require the same BIMI certificate?
Mailbox providers do not all apply the same certificate acceptance rules. Check each intended receiver’s current documentation and retain the source and review date with the assessment.
Can I use any SVG file for my BIMI logo?
An arbitrary SVG file is not sufficient for BIMI. Validate the asset against the required SVG Tiny PS profile and check its HTTPS accessibility separately.
Does a missing BIMI logo mean my domain was compromised?
A missing BIMI logo does not establish domain compromise. It is a display observation that requires separate checks of authentication, publication, asset compliance, and receiver conditions.
Can SCOUTz public-domain evidence prove Microsoft 365 security settings?
SCOUTz public-domain evidence cannot establish internal Microsoft 365 configuration. Customer-authorized tenant evidence has a separate scope, and unread or unassessed controls remain explicitly unknown.
One last thing
Preserve the sending domain and the receiver together in every display result. A screenshot without the message context is weak proof: it does not explain which sender configuration produced the result or where it was observed.
Before closing a 2026 BIMI project, give the customer a dated baseline, the approved changes, the rescan results, and the remaining unknowns. Promise a documented review and verified work. Leave inbox display decisions with the receiver.
