What DMARC policy settings are required for BIMI and how do I determine the best setting for sp=?
Published 25 Jul 2025
Updated 4 Aug 2026
10 min read
Summarize with
Updated on 4 Aug 2026: We updated this guide for RFC 9989 and current BIMI enforcement requirements.
For BIMI, both the organizational domain and the domain in the visible From address need an enforced DMARC policy. In practical terms, p= must be quarantine or reject, and any explicit sp= must also be quarantine or reject. A record with p=reject and sp=none does not meet BIMI's policy requirement.
The short recommendation is to 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 while unknown or newly introduced subdomain senders remain, but keep full enforcement and do not use t=y for a BIMI-ready policy.
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 domain match with the visible From header. DMARC monitoring provides the evidence needed before changing enforcement.
The direct answer for BIMI
The BIMI implementation guide says DMARC must be at enforcement on the organizational domain and subdomains used for mail. It lists quarantine and reject as accepted policies and rejects none policies or legacy pct values below 100 percent. RFC 9989 now makes pct historic, so new records can omit it. If it remains for compatibility, keep it at 100.
- Set the root policy to p=quarantine or p=reject. If the domain is already stable at reject, keep it there.
- Set an explicit subdomain policy to sp=quarantine or sp=reject. Do not use sp=none when the goal is BIMI.
- Use full enforcement. Under RFC 9989, omit the historic pct tag and leave t absent or set it to n. If a legacy pct tag remains, use 100.
- Make sure every real sender passes DMARC through SPF or DKIM domain matching for the visible From domain.
BIMI minimum
The practical minimum is p=quarantine, sp=quarantine, and full enforcement. For a new RFC 9989 record, omit pct and do not publish t=y. The target state for a mature domain is p=reject and sp=reject, with reporting 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 requirements are not met.
Quarantine
Passes
Passes when enforcement is fully applied. It is a staging choice for subdomains.
Reject
Passes
Passes when enforcement is fully applied. Use it after sender review.
Meeting the DMARC requirement makes a message eligible for BIMI processing. It does not guarantee that the logo will appear because each mailbox provider applies its own display criteria. BIMI does not require adkim=s or aspf=s; the message needs to pass DMARC under the domain's configured matching mode.
How to choose sp
The sp tag controls the DMARC policy for existing 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 record's p= value takes priority for mail using the subdomain in the visible From address. Under RFC 9989, an sp= tag inside a subdomain-level DMARC record is ignored. A strict parent sp= setting still protects new and forgotten existing subdomains by default.
The decision should come from report data, not a DNS guess. List every observed visible From domain in aggregate reports, then group each source under the exact domain it uses. If marketing.example.com, updates.example.com, or receipts.example.com appears, each one needs a clear owner, sending platform, DMARC result, and decision on whether it should keep sending.
That inventory matters because sp=reject is intentionally unforgiving. It works well when the domain is clean. It causes legitimate mail failures when an old product notification or billing process still sends from a subdomain with broken DKIM. sp=quarantine is the right holding pattern while report data still contains unanswered senders.
Use sp=quarantine
- Use it when subdomains send mail but every sender has not yet been reviewed.
- Receivers are asked to quarantine failing mail, which often means spam placement rather than rejection.
- Keep it as a temporary state while reports prove each subdomain is clean.
Use sp=reject
- Use it when every visible From subdomain sender is known and passes DMARC reliably.
- It has a higher cost for authentication mistakes but stops more spoofed subdomain mail.
- Keep it as the target state once subdomain authentication is proven.
DMARC sp policy decision path for BIMI subdomains.
The default decision path is simple. If no existing subdomains send mail, set sp=reject. If subdomains send mail and the reporting data is clean, set sp=reject. If new senders are still appearing, set sp=quarantine, fix the failures, then move to reject.
What to verify before changing sp
Before changing sp=, collect proof that legitimate subdomain mail will not break. Review aggregate DMARC reports, group sources by visible From domain, and separate known senders from unexpected traffic.
Use a DMARC checker to confirm the DNS syntax, but do not stop there. Syntax only tells you the record can be read. Reports show whether real mail will pass after enforcement.
|
|
|
|---|---|---|
Visible From domains | Shows which subdomains need policy review. | All senders known |
DKIM domain | A valid DKIM signature must have the required domain match with the visible From domain. | Passes DMARC |
SPF domain | A passing SPF identity must have the required domain match with the visible From domain. | Passes DMARC |
SPF lookups | SPF can return a permanent error if the 10-lookup limit is exceeded. | 10 or fewer |
Effective policy | BIMI requires full enforcement rather than a testing policy. | No t=y; no pct below 100 |
Report analysis | Sources must be mapped before policy changes are safe. | 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 report analysis. The check is not a replacement for report data, but it can find broken DNS quickly.
?
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. A week can be enough for a small sender, but the review period must also cover less frequent billing, account, campaign, and batch mail. Do not move to reject until every expected cycle has appeared in the reports.
Example records that satisfy BIMI
This is the final record shape for a mature domain with clean reports and a complete sender inventory. It keeps enforcement clear at the root and for existing subdomains, and it uses current RFC 9989 syntax.
Final BIMI-ready DMARC recorddns
_dmarc.example.com. 3600 IN TXT ( "v=DMARC1; p=reject; sp=reject; " "rua=mailto:dmarc@example.com" )
This staging record keeps the root domain at reject while existing subdomains remain at quarantine. It maintains BIMI-compatible enforcement without rejecting every subdomain failure immediately.
Staged BIMI-ready DMARC recorddns
_dmarc.example.com. 3600 IN TXT ( "v=DMARC1; p=reject; sp=quarantine; " "rua=mailto:dmarc@example.com" )
Common BIMI policy mistake
Do not use a legacy pct value below 100 or the RFC 9989 setting t=y and expect BIMI eligibility. New records should omit pct. If it remains for legacy compatibility, set it to 100. Leave t absent or set it to n so enforcement is not reduced.
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.
When sp= is absent, an existing subdomain without its own DMARC record inherits the parent p= policy. Publishing sp= explicitly still makes the intended subdomain policy clear during reviews and future DNS changes.
What RFC 9989 changes for BIMI
RFC 9989 replaced the earlier DMARC specification. It makes pct historic and introduces t as a testing control. This changes how a new BIMI-ready record should express full enforcement, even though some BIMI and mailbox-provider documentation still describes the older pct=100 rule.
- Omit pct in a new RFC 9989 record. If an older record keeps the tag for compatibility, use only pct=100.
- Do not use t=y for BIMI. It asks receivers to apply a policy one level below the published policy. Omit t or use t=n.
- Use sp for existing subdomains covered by the organizational-domain record. A subdomain with its own record uses its own p policy.
- Use np=reject when you want an explicit reject policy for non-existent subdomains. np does not replace sp for subdomains that exist in DNS.
The safest interoperability position is full, unambiguous enforcement: use quarantine or reject, do not publish sp=none, do not use t=y, and never retain a legacy pct value below 100.
How Suped handles this workflow
Suped is the DMARC reporting and email authentication platform behind this site. For a BIMI rollout, it connects DMARC record checks, aggregate report analysis, policy changes, and alerts so the team can see which source needs a fix before moving sp= to reject.
Hosted DMARC configuration dialog showing policy controls, CNAME setup, and expanded advanced options
For this BIMI workflow, Suped's Hosted DMARC lets teams stage policy changes without repeated DNS edits. The domain can move through monitoring, quarantine, and reject while reports and issue detection stay in the same workflow.
- Group report data by visible From domain and sending source to build the subdomain inventory.
- Trace failed domain matching to SPF or DKIM so each legitimate sender has a specific fix.
- Stage and review policy changes before moving existing subdomains to reject.
- Alert on new DMARC failures after enforcement so newly added senders are caught.
The practical workflow is to find every subdomain sender, fix SPF or DKIM domain matching, confirm full enforcement, then monitor for new failures after BIMI mail becomes eligible for logo display.
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 stays clear during future security 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
Recommended sp setting
If the root domain is already stable at p=reject, keep it there. Use sp=reject when the subdomain inventory is complete and every legitimate sender passes DMARC. That is the clearest target state for BIMI and subdomain spoofing protection.
If any sending subdomain is new or still being configured, use sp=quarantine first and review the reports under full enforcement. Once the reports show clean traffic across every expected sending cycle, move to sp=reject. That follows a safer transition policy without dropping BIMI enforcement.
Choose quarantine or reject using evidence: known subdomains, known senders, SPF or DKIM domain matching, full enforcement, and ongoing reports. Keep reporting active after the change because a broken source often appears only when a scheduled campaign or product process runs.
