What DMARC policy settings are required for BIMI and how do I determine the best setting for sp=?
Matthew Whittaker
Co-founder & CTO, Suped
Published 25 Jul 2025
Updated 27 May 2026
9 min read
Summarize with
For BIMI, your organizational domain needs a DMARC policy at enforcement, and your subdomains need enforcement too. In practical terms, p= must be quarantine or reject, and sp= should also be quarantine or reject. A record with p=reject and sp=none is not the setting I would leave in place for BIMI.
The short recommendation is this: keep p=reject for the root domain if it is already working, then move sp= to reject once every visible From subdomain that sends mail is passing DMARC through SPF or DKIM domain matching. Use sp=quarantine as the safer staging setting when you still have unknown or newly warmed subdomains.
MX records and sender reputation do not decide DMARC compliance. MX tells other servers where to deliver inbound mail. Sender reputation can affect whether a mailbox provider displays a BIMI logo, but the DMARC test depends on SPF or DKIM authentication plus a matching domain in the visible From header. I treat DMARC monitoring as the evidence layer before changing enforcement.
The direct answer for BIMI
The BIMI implementation guide says DMARC must be at enforcement on the organizational domain and subdomains. It lists quarantine and reject as the accepted policies, and it says none policies or pct values below 100 percent are not accepted.
Root policy: Use p=quarantine or p=reject. If the domain is already stable at reject, keep it there.
Subdomain policy: Use sp=quarantine or sp=reject. Do not use sp=none when the goal is BIMI.
Rollout percentage: Use pct=100. A lower percentage weakens enforcement and fails the BIMI policy check.
Authentication: Every real sender needs SPF or DKIM to pass DMARC for the visible From domain.
BIMI minimum
The practical minimum is p=quarantine, sp=quarantine, and pct=100. The final state I prefer for mature domains is p=reject and sp=reject, with reporting still enabled so new senders do not drift outside policy.
BIMI policy threshold
How the main DMARC policy states map to BIMI readiness.
None
Fails
Monitoring only. BIMI policy requirement is not met.
Quarantine
Passes
Enforcement is active. Good staging choice for subdomains.
Reject
Passes
Enforcement is active. Best final choice after sender review.
How to choose sp
The sp tag controls the DMARC policy for subdomains that do not publish their own DMARC record. It applies to mail where the visible From domain is a subdomain, such as mail.example.com or news.example.com. It does not apply just because the return path or bounce domain is on a subdomain.
If a subdomain publishes its own DMARC record, that subdomain record takes priority for mail using that subdomain in the visible From address. That is useful for special cases, but I still prefer a strict parent sp= setting because it protects new and forgotten subdomains by default.
The decision should come from report data, not a DNS guess. I start by listing every observed header From domain in aggregate reports. Then I group each source under the exact domain it sends as. If marketing.example.com, updates.example.com, or receipts.example.com appears, each one needs a clear answer: who owns it, which platform sends it, whether DKIM or SPF passes DMARC, and whether the team expects it to keep sending.
That inventory matters because sp=reject is intentionally unforgiving. It is excellent when the domain is clean. It is painful when an old product notification, trial system, or billing process still sends from a subdomain with broken DKIM. sp=quarantine is the right holding pattern when the report data still has unanswered senders.
Use sp=quarantine
Best fit: You know subdomains send mail, but you have not reviewed every sender yet.
Risk level: Lower than reject because failing mail is normally placed in spam or held.
Duration: Use it as a temporary state while reports prove each subdomain is clean.
Use sp=reject
Best fit: Every visible From subdomain sender is known and passes DMARC reliably.
Risk level: Higher for mistakes, but better for stopping spoofed subdomain mail.
Duration: Use it as the target state once subdomain authentication is proven.
Decision path for moving a DMARC subdomain policy to reject.
My default decision path is simple. If you have no subdomains sending mail, set sp=reject. If you have subdomains sending mail and the reporting data is clean, set sp=reject. If you are still finding senders, set sp=quarantine, fix the failures, then move to reject.
What to verify before changing sp
Before changing sp=, I want proof that subdomain mail is not going to break. The fastest way to get that proof is to review aggregate DMARC reports, group sources by visible From domain, and separate known senders from anything unexpected.
Use a DMARC checker to confirm the DNS syntax, but do not stop there. Syntax only tells you the record can be read. Reports tell you whether real mail will pass after enforcement.
Check
Why it matters
Pass condition
Visible From domains
Shows which subdomains need policy review.
All senders known
DKIM domain
DMARC passes when DKIM signs with the right domain.
Passes DMARC
SPF domain
SPF only helps when its domain matches the header domain.
Passes DMARC
SPF lookups
SPF fails if the 10 lookup limit is exceeded.
10 or fewer
Policy percent
BIMI needs full enforcement, not partial rollout.
100 percent
Report parsing
Raw reports are hard to use for enforcement decisions.
Sources mapped
Pre-change checks for BIMI and subdomain enforcement.
For a first pass, run a broad domain check. It catches obvious DMARC, SPF, and DKIM mistakes before you spend time reading reports. The check is not a replacement for report analysis, but it is good at finding broken DNS.
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
After the DNS check, inspect live report data for at least one normal sending cycle. For a small sender, that can be a week. For a company with many campaigns and transactional systems, I prefer enough time to cover billing mail, password resets, lifecycle mail, sales mail, support mail, and any periodic batch jobs.
Example records that satisfy BIMI
This is the final record shape I like when the domain is mature, reports are clean, and the organization knows which subdomains send mail. It keeps enforcement clear at both the root and subdomain level.
This is the staging record shape I use when subdomains are still being audited. It has BIMI-compatible enforcement, but it gives you a lower-risk step before blocking failing subdomain mail outright.
Do not leave pct=0 or any partial percentage in place and expect BIMI to work. It is useful for a DMARC rollout, but BIMI needs full enforcement.
If you are building the record from scratch, use the DMARC record generator to create the TXT value, then validate it in DNS after publishing.
There is one nuance worth saying plainly. DMARC itself applies the parent p= policy to subdomains when sp= is absent. For BIMI work, I still publish sp= explicitly. It removes ambiguity for people, tools, and future audits.
How Suped handles this workflow
Suped is the best overall DMARC platform for most teams working toward BIMI because it connects the record check, report analysis, enforcement workflow, and ongoing alerts. The important part is seeing the pass or fail result and knowing which sending source needs a fix before you move sp= to reject.
For this specific BIMI use case, Suped's Hosted DMARC helps teams stage policy changes without repeated DNS edits. You can move the domain through monitoring, quarantine, and reject while keeping reports and issue detection in the same workflow.
Automated issue detection: Suped groups failing sources and gives fix steps instead of leaving you with raw XML.
Real-time alerts: You can catch new DMARC failures after moving sp= to quarantine or reject.
Hosted SPF: It helps manage senders and SPF flattening so you stay under DNS lookup limits.
Hosted MTA-STS: It lets you enforce TLS for mail delivery with two CNAME records.
Blocklist monitoring: It watches domain and IP reputation across major blocklist and blacklist sources.
Multi-tenancy: MSPs and agencies can manage many client domains from one dashboard.
The value during a BIMI project is practical: find every subdomain sender, fix the SPF or DKIM domain match, confirm the policy is enforced at 100 percent, then keep watching for new failures after the logo starts appearing.
Views from the trenches
Best practices
Inventory visible From subdomains before changing sp so no live sender is missed.
Use quarantine as a staging step when subdomain report data is still incomplete.
Keep rua reporting active after reject so new senders are caught before damage spreads.
Common pitfalls
Checking only the root domain hides subdomain senders that will break under sp reject.
Confusing return-path domains with visible From domains leads to the wrong DMARC fix.
Sending aggregate reports to a mailbox leaves too much work for enforcement decisions.
Expert tips
Treat BIMI as the last step after DMARC, DKIM, SPF, sender inventory, and logo work.
Make p and sp explicit in DNS so policy intent is clear during future audits.
Move slowly enough to cover periodic mail streams before rejecting subdomain failures.
Marketer from Email Geeks says BIMI requires DMARC enforcement on both the organizational domain and subdomains, with quarantine or reject as the acceptable policies.
2025-02-06 - Email Geeks
Marketer from Email Geeks says MX records and sender reputation do not decide DMARC compliance; SPF or DKIM must pass for the visible From domain.
2025-02-06 - Email Geeks
The setting I would choose
If the root domain is already stable at p=reject, I would keep it there. For sp=, I would use sp=reject when the subdomain inventory is complete and every real sender passes DMARC. That is the cleanest end state for BIMI and spoofing protection.
If the team is still setting up a lifecycle subdomain, a transactional subdomain, or anything newly warmed, I would choose sp=quarantine first, keep pct=100, and review the reports. Once the reports prove clean traffic, move to sp=reject. That matches the safer transition policy pattern without leaving BIMI enforcement behind.
The key is not choosing quarantine or reject by opinion. Choose based on evidence: known subdomains, known senders, passing SPF or DKIM, full percentage enforcement, and ongoing reports. I also leave reporting on after the change because the first broken source often appears after a campaign or product release. For a deeper policy-only explanation, compare the BIMI enforcement requirement with your current DMARC record.
Frequently asked questions
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
