DMARC Checker: Read Your DMARC Record Like a Pro
A DMARC checker helps you read the policy your domain publishes for email authentication failures. It tells you whether your domain has a DMARC record, what the policy does, where reports are sent, whether subdomains are covered, how strict alignment is, and whether the record is only monitoring mail or actively protecting the domain from spoofing.
This guide explains how to read your DMARC record like a pro. You will learn what each DMARC tag means, how to use a DMARC checker, what p=none, p=quarantine, and p=reject actually do, how aggregate reports work, how SPF and DKIM alignment affect DMARC, and what to fix before moving from monitoring to enforcement.
The short version: a good DMARC record starts with v=DMARC1, publishes one policy with p=, usually includes a rua= reporting address, protects subdomains intentionally with sp=, uses pct= only during rollout, and depends on SPF or DKIM alignment to pass. A DMARC checker turns that compact DNS string into a readable set of campaign and security decisions.
Try the BuffSend DMARC Checker
Enter your domain below to check the DMARC record published at _dmarc.yourdomain.com. Use the sending domain, not a full URL. For example, enter example.com, not https://www.example.com.
What Is a DMARC Record?
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It builds on SPF and DKIM by telling receivers what to do when a message claiming to be from your domain does not pass aligned authentication. DMARC also gives domain owners a way to receive reports about who is sending mail that appears to use the domain.
The core DMARC specification is RFC 7489. In everyday operations, you do not need to memorize the full RFC. You do need to understand the record tags, alignment rules, and rollout path so you do not accidentally block legitimate mail or leave the domain unprotected forever.
What DMARC Checks
DMARC checks whether a message passes SPF or DKIM and whether the authenticated domain aligns with the visible From domain. This alignment is the point many teams miss. SPF can pass for one domain, DKIM can pass for another domain, and DMARC can still fail if neither authenticated domain aligns with the From domain recipients see.
DMARC pass condition
A message passes DMARC when at least one of these is true: SPF passes and aligns with the From domain, or DKIM passes and aligns with the From domain. Both do not need to pass, but at least one aligned mechanism must pass.
What DMARC Does Not Do
DMARC does not guarantee inbox placement, replace consent, fix poor list quality, or prove that recipients want the message. It is an authentication policy and reporting layer. Inbox providers still evaluate reputation, complaints, bounce behavior, content, engagement, and sending volume.
DMARC is not a spam filter score
A strict DMARC policy can protect your domain from spoofed mail, but a legitimate campaign can still go to spam if it is unwanted, sent to stale contacts, or sent too aggressively. DMARC is necessary infrastructure, not a complete deliverability strategy.
Where the DMARC Record Lives
A DMARC record is a DNS TXT record published at _dmarc.example.com. The record begins with v=DMARC1 and includes tags separated by semicolons.
v=DMARC1; p=none; rua=mailto:dmarc@example.com; pct=100That sample record says the domain is publishing DMARC, using a monitoring-only policy, sending aggregate reports to dmarc@example.com, and applying the policy to all applicable messages.
How to Read a DMARC Record
DMARC records look intimidating because they compress policy, reporting, alignment, and rollout settings into one DNS value. Once you break the tags apart, the record becomes readable. A DMARC checker does this parsing for you, but you should still know what the tags mean so you can make better decisions.
v=DMARC1: Version
The v tag identifies the record as DMARC. It should appear as v=DMARC1. If this tag is missing or misspelled, receivers may ignore the record.
What to check
Confirm the record starts with v=DMARC1. Do not publish more than one DMARC record at the same _dmarc host. Multiple DMARC records can create parsing problems.
p=: Domain Policy
The p tag is the main DMARC policy. It tells receivers what the domain owner asks them to do with mail that fails DMARC.
| Policy | Meaning | Typical Use |
|---|---|---|
| p=none | Monitor failures but do not ask receivers to quarantine or reject them. | Initial setup, discovery, report collection. |
| p=quarantine | Ask receivers to treat failing mail as suspicious, often spam placement. | Partial enforcement after legitimate senders are aligned. |
| p=reject | Ask receivers to reject failing mail. | Strong enforcement once the domain is ready. |
What to check
If your record is still p=none after months of reporting, the domain is monitoring but not enforcing. That can be fine during setup, but it does not ask receivers to block spoofed mail.
rua=: Aggregate Reports
The rua tag tells receivers where to send aggregate DMARC reports. These reports summarize authentication results by source. They help you discover legitimate senders, unauthorized senders, alignment failures, and rollout risk.
What to check
Use a mailbox or DMARC report processing service that can handle XML reports. Raw DMARC reports can be hard to read manually, but they are extremely useful for identifying senders before moving to enforcement.
ruf=: Forensic Reports
The ruf tag requests forensic or failure reports. In practice, support for these reports is limited and privacy-sensitive. Many teams rely primarily on aggregate reports rather than forensic reports.
What to check
Do not assume ruf will produce complete failure detail. Treat it as optional, and avoid sending sensitive report traffic to unmanaged mailboxes.
pct=: Percentage Rollout
The pct tag tells receivers what percentage of failing mail should be subject to the DMARC policy. It is commonly used during rollout from monitoring to quarantine or reject.
What to check
If pct=25 and p=quarantine, the domain is asking receivers to apply quarantine to only part of failing mail. This can be useful during rollout, but it should not stay partial forever without a reason.
sp=: Subdomain Policy
The sp tag sets a policy for subdomains. If it is missing, subdomains usually inherit the main p policy. Subdomain policy matters when you send from subdomains such as mail.example.com, news.example.com, or sales.example.com.
What to check
Make sure subdomains are covered intentionally. If you use subdomains for cold outreach, product email, support, or transactional mail, confirm each mail stream can pass aligned SPF or DKIM before enforcing a strict subdomain policy.
adkim= and aspf=: Alignment Mode
The adkim tag controls DKIM alignment strictness. The aspf tag controls SPF alignment strictness. Both can be relaxed or strict. Relaxed alignment allows organizational-domain alignment. Strict alignment requires an exact domain match.
What to check
Most teams start with relaxed alignment. Strict alignment can be useful for tighter security, but it can break legitimate mail if subdomains, providers, or return-path domains are not configured carefully.
DMARC Policy Examples
Examples make DMARC easier to read. The right record depends on your domain, sending systems, report processing, and enforcement readiness. Do not copy a strict record blindly if you have not confirmed all legitimate senders pass DMARC.
Monitoring Record
v=DMARC1; p=none; rua=mailto:dmarc@example.com; pct=100This record asks receivers to send aggregate reports but does not ask them to quarantine or reject failing mail. It is useful when first discovering who sends mail for the domain.
When to use it
Use monitoring when you are setting up DMARC for the first time, mapping legitimate senders, or fixing SPF and DKIM alignment. Do not treat p=none as the final destination for a domain that needs spoofing protection.
Quarantine Rollout Record
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.comThis record asks receivers to quarantine 25% of mail that fails DMARC. It is a controlled enforcement step after reports show that legitimate senders are mostly aligned.
When to use it
Use partial quarantine when you are confident enough to begin enforcement but still want to limit the impact of unexpected failures.
Reject Enforcement Record
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; sp=reject; pct=100This record asks receivers to reject failing mail for the domain and subdomains. It is the strongest common policy and should be used only after legitimate senders are aligned.
When to use it
Use reject when reports show that legitimate mail passes DMARC and when the organization is ready to block spoofed mail that fails authentication.
Strict Alignment Record
v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:dmarc@example.comThis record requires strict SPF and DKIM alignment. Strict alignment can improve control, but it requires careful configuration of every sender and subdomain.
When to use it
Use strict alignment only when you know every legitimate mail stream authenticates with the exact domain expected. Many organizations should stay relaxed unless they have a clear reason and tested configuration.
How a DMARC Checker Helps
A DMARC checker reads your public DNS record and translates it into practical findings. Instead of staring at one long string, you can see whether the record exists, whether the policy is monitoring or enforcing, whether reports are configured, whether subdomains are covered, and whether the rollout percentage is partial.
It confirms the record location
The checker looks for a TXT record at _dmarc.yourdomain.com. If the record is published at the root domain, under www, or under the wrong subdomain, receivers may not use it.
Common location mistakes
- Publishing the record at
example.cominstead of_dmarc.example.com. - Publishing
_dmarc.example.com.example.combecause the DNS provider appended the root domain. - Checking the root domain when mail actually uses a separate organizational domain.
- Adding multiple DMARC TXT records at the same host.
It explains policy strength
A DMARC checker can show whether your policy is none, quarantine, or reject. This matters because many teams believe they are protected when they only have a monitoring policy.
Monitoring is visibility, not enforcement
p=none is useful. It gives you reports. But it does not ask receivers to block or quarantine failing mail. The long-term goal for many domains is to move toward enforcement after legitimate senders are aligned.
It reveals report destinations
If no rua tag exists, you may not receive aggregate reports. Without reports, you lose visibility into who is sending mail for your domain and whether SPF or DKIM alignment is working.
Reporting mailbox caution
DMARC reports can be noisy and XML-heavy. Use a mailbox or service designed to process them. Sending reports to a personal inbox can create clutter and missed signals.
It catches rollout mismatches
A record with p=reject and pct=10 is not full reject enforcement. A record with p=quarantine and no sp= may affect subdomains differently than the team expects. A DMARC checker makes these details visible.
Build Cleaner Authentication Workflows
What to Check Before Moving to Enforcement
Moving from p=none to p=quarantine or p=reject is a good goal for many domains, but it should not be rushed. Enforcement tells receivers to take action against failing mail. If legitimate mail still fails DMARC, enforcement can hurt your own campaigns, invoices, support messages, notifications, or sales outreach.
Check Every Legitimate Sender
List every system that sends email for the domain. This often includes Google Workspace, Microsoft 365, CRM, marketing automation, sales engagement, help desk, billing, transactional email, product notifications, monitoring systems, and legacy tools.
Sender inventory questions
- Which systems send from the root domain?
- Which systems send from subdomains?
- Which vendors sign with DKIM using your domain?
- Which systems use a custom return-path for SPF alignment?
- Which old systems still send occasional mail?
Check SPF Alignment
SPF alignment depends on the envelope sender domain, not only the visible From address. SPF itself is defined in RFC 7208, but DMARC adds the alignment requirement. A message can pass SPF for a provider return-path domain while failing DMARC alignment for your From domain.
SPF alignment question
Does the domain that passed SPF align with the visible From domain? If not, configure a custom bounce or return-path domain if your provider supports it, or rely on aligned DKIM.
Check DKIM Alignment
DKIM alignment depends on the d= signing domain in the DKIM signature. DKIM is defined in RFC 6376. For DMARC, the key question is whether the DKIM signing domain aligns with the visible From domain.
DKIM alignment question
Does at least one DKIM signature pass and align with the From domain? If DKIM passes only for a vendor domain, configure custom-domain DKIM before enforcing DMARC.
Check DMARC Reports
Aggregate reports show which sources send mail for the domain and how they authenticate. Review them before enforcement. Look for legitimate sources that still fail alignment, unknown sources, forwarding patterns, and mail streams using subdomains.
Report review questions
- Which sources pass SPF alignment?
- Which sources pass DKIM alignment?
- Which legitimate sources fail both?
- Which sources are unauthorized?
- Which subdomains appear in reports?
Check Subdomain Impact
Subdomains can carry important mail streams. If you set sp=reject, failing mail from subdomains may be rejected even if those subdomains are managed by another team or tool. Map subdomain sending before enforcing.
Subdomain question
Do all active subdomains have aligned SPF or DKIM? If not, enforce gradually or fix subdomain authentication first.
Check SPF Before Enforcing DMARC
Provider-Specific DMARC Guidance
DMARC is published in DNS, not inside a single mailbox provider. Still, provider guidance matters because Google Workspace, Microsoft 365, Yahoo, and bulk sender ecosystems all expect authenticated mail and responsible sending.
Google Workspace DMARC Checks
Google's official DMARC setup guide explains that DMARC setup happens at your domain provider and depends on SPF and DKIM being correctly set up. Google also recommends using pct during rollout so you can manage how much mail is affected by the policy.
What to check for Google Workspace
- Google Workspace DKIM is enabled for your domain.
- SPF includes Google if Google sends mail for the domain.
- Your DMARC record is published at
_dmarc. - Reports are going somewhere you actually monitor.
- Policy rollout is gradual if you are moving to enforcement.
Microsoft 365 DMARC Checks
Microsoft's official DMARC configuration guidance explains that SPF and DKIM should be configured for custom domains before DMARC is configured. This is the right order: authenticate legitimate mail first, then publish and enforce policy.
What to check for Microsoft 365
- The custom domain is verified in Microsoft 365.
- SPF includes Microsoft 365 if it sends for the domain.
- DKIM signing is enabled for the custom domain.
- DMARC aligns with your visible From domain.
- Reports show Microsoft mail passing before enforcement.
Yahoo and High-Volume Sender Checks
Yahoo's Sender Hub best practices strongly encourage senders to publish DMARC for sending domains. For bulk sending, DMARC is not just a security detail. It helps receivers understand which mail is authorized and what to do when authentication fails.
What to check for Yahoo-heavy lists
- SPF and DKIM are configured for every sending stream.
- DMARC exists and is not malformed.
- One-click unsubscribe and complaint handling are healthy.
- Reports show no large legitimate failure source.
- Sending behavior is consistent with sender best practices.
Common DMARC Checker Findings
Most DMARC checker warnings fall into a short list. The right fix depends on whether the issue is record syntax, weak policy, missing reporting, alignment failure, or rollout uncertainty.
No DMARC Record Found
The domain has no TXT record at _dmarc.example.com. Receivers cannot apply a domain-level DMARC policy or send reports based on your published instructions.
Fix
Start with a monitoring record such as v=DMARC1; p=none; rua=mailto:dmarc@example.com. Then review reports and fix SPF/DKIM alignment before enforcement.
Multiple DMARC Records Found
A domain should publish one DMARC record at the _dmarc host. Multiple records can cause receivers to ignore the policy or produce unpredictable parsing behavior.
Fix
Merge the intended tags into one record and remove duplicates. Do not keep separate DMARC records for different vendors.
Policy Is Still p=none
This means the domain is monitoring but not asking receivers to quarantine or reject failing mail. That may be correct during setup, but it is weak protection if left unchanged forever.
Fix
Review aggregate reports, fix legitimate failures, then move gradually to quarantine and eventually reject when ready.
No Aggregate Reports
If rua is missing, you may not receive visibility into authentication results. That makes rollout harder because you cannot easily see who sends mail for the domain.
Fix
Add a monitored rua=mailto: destination or use a DMARC report processing service. Make sure the mailbox or service can handle report volume.
Partial Policy With pct
A partial rollout can be intentional. It can also be forgotten. If a domain stays at pct=10 for months, enforcement is weaker than the policy name suggests.
Fix
Use pct as a rollout tool. Increase gradually as reports show that legitimate mail passes alignment.
Alignment Failures
The most important DMARC failures happen when SPF and DKIM authenticate domains that do not align with the visible From domain. This is common with third-party platforms that are not fully configured for custom-domain authentication.
Fix
Configure custom-domain DKIM, custom return-path, or both. Then send fresh tests and inspect headers for DMARC pass.
DMARC Rollout Plan
A safe DMARC rollout usually moves from visibility to partial enforcement to full enforcement. The timeline depends on domain complexity. A small company with one mail provider may move quickly. A larger organization with many vendors, subdomains, and legacy systems needs more time.
Phase 1: Publish Monitoring
Start with p=none and rua. This gives you visibility without asking receivers to quarantine or reject failing mail.
Goal
Identify every legitimate sender and every unauthorized source. Fix missing SPF, missing DKIM, custom-domain signing, and return-path alignment problems.
Phase 2: Move to Partial Quarantine
After legitimate sources pass DMARC, move to p=quarantine with a limited pct, such as 10 or 25. Continue watching reports.
Goal
Start enforcement while limiting the blast radius if a legitimate source was missed.
Phase 3: Increase Quarantine Coverage
Increase pct gradually until quarantine applies to all failing mail. Watch for unexpected failures, especially from subdomains and vendors.
Goal
Confirm that enforcement does not disrupt real mail.
Phase 4: Move to Reject
Once quarantine enforcement is stable, move to p=reject. Keep aggregate reports active so you can detect new senders or broken configurations later.
Goal
Give receivers a strong instruction to reject mail that fails DMARC.
| Phase | Example Record | What It Proves |
|---|---|---|
| Monitor | p=none |
You can see who sends mail for the domain. |
| Partial quarantine | p=quarantine; pct=25 |
Most legitimate mail is aligned, but rollout is cautious. |
| Full quarantine | p=quarantine; pct=100 |
Quarantine does not disrupt legitimate senders. |
| Reject | p=reject |
The domain is ready for strong enforcement. |
Example: Reading a DMARC Record Like a Pro
Imagine a domain publishes this record:
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=50; sp=none; adkim=r; aspf=sWhat the record says
The domain has DMARC enabled. The main policy asks receivers to quarantine failing mail, but only for 50% of messages. Aggregate reports go to dmarc@example.com. Subdomains are monitoring only because sp=none. DKIM alignment is relaxed, while SPF alignment is strict.
What a pro would notice
This is not full quarantine enforcement because pct=50. Subdomains are less protected than the root domain because sp=none. SPF alignment is stricter than DKIM alignment, so custom return-path setup matters. Reports are configured, which is good, but someone needs to read them.
What to ask next
- Why is the rollout still at 50%?
- Are all legitimate senders passing DMARC?
- Do subdomains send mail?
- Does strict SPF alignment break any providers?
- Is the report mailbox monitored by a person or parser?
The lesson
Reading a DMARC record is not only reading tags. It is understanding the operational state behind the tags: monitoring, enforcement, rollout, subdomain coverage, alignment, and reporting.
Monitor Authentication Before You Send
How to Read DMARC Reports
The DMARC record is only the beginning. Reports are where the record becomes useful. Aggregate reports show how receivers are evaluating mail that claims to use your domain. They can reveal legitimate platforms you forgot about, unauthorized spoofing attempts, SPF alignment failures, DKIM alignment failures, and subdomains that need attention before enforcement.
DMARC aggregate reports are usually XML files. They are not pleasant to read by hand, but the fields are consistent enough that a parser or DMARC reporting service can turn them into dashboards. Even if you use a tool, you should understand what the report is telling you.
Report Metadata
Report metadata identifies the organization that sent the report, the report ID, and the date range. This helps you understand which receiver produced the data and what time period it covers.
What to check
Make sure you are comparing similar time windows. A one-day report after a major campaign will look different from a quiet weekend report. Do not make enforcement decisions from one isolated report if your mail volume varies heavily.
Policy Published
The report includes the DMARC policy the receiver saw at the time it evaluated messages. This is useful because DNS changes, caching, and rollout adjustments can make reports reflect different policy states over time.
What to check
Confirm the report shows the policy you expected. If you changed from p=none to p=quarantine, reports may show both states during the transition window.
Source IP
Each record usually includes a source IP address. This is the IP that sent the message to the receiver. Source IPs help you map mail streams to providers, platforms, and possible unauthorized senders.
What to check
Group source IPs by provider where possible. If a source IP belongs to Google, Microsoft, SendGrid, Mailgun, Postmark, HubSpot, Salesforce, or another known vendor you use, check whether that vendor is passing alignment. If the source is unknown, investigate before enforcement.
Disposition
Disposition shows what the receiver did with the message based on the DMARC policy, such as none, quarantine, or reject. This can differ from final inbox placement, but it tells you how the DMARC policy affected the receiver's handling.
What to check
If you see quarantine or reject disposition for a legitimate source, pause enforcement rollout until that source is fixed. If unauthorized sources are being rejected, the policy is doing useful protective work.
SPF and DKIM Results
Reports show whether SPF and DKIM passed and whether those mechanisms aligned. This is the heart of DMARC reporting. The question is not only "did SPF pass?" or "did DKIM pass?" The question is "did SPF or DKIM pass with alignment?"
What to check
- Legitimate sources passing DKIM alignment are usually in good shape.
- Legitimate sources passing SPF but not DKIM may still be fine if SPF aligns.
- Sources passing SPF for a vendor domain but failing alignment need custom return-path setup or aligned DKIM.
- Sources passing DKIM for a vendor domain but failing alignment need custom-domain DKIM signing.
- Sources failing both SPF and DKIM should be treated as high-priority investigation items.
Count
The count field shows how many messages matched a record. This helps you prioritize. A single failure from an obscure source may be less urgent than 50,000 failures from a billing platform or CRM.
What to check
Sort by message count and business importance. Fix high-volume legitimate failures before moving to enforcement. Investigate high-volume unknown sources quickly because they may represent abuse or misconfigured infrastructure.
| Report Signal | What It Means | Action |
|---|---|---|
| Known source, aligned pass | A legitimate sender is authenticating correctly. | Document it and keep monitoring. |
| Known source, DMARC fail | A real sender is not aligned. | Fix SPF return-path or DKIM signing before enforcement. |
| Unknown source, DMARC fail | Possible spoofing, forwarding, or unmanaged sender. | Investigate source ownership and volume. |
| High count failure | A significant mail stream is failing. | Prioritize before policy changes. |
| Rejected unauthorized mail | Enforcement is blocking failing sources. | Confirm no legitimate source is affected. |
Pre-Send DMARC Checklist
Use this checklist before high-volume campaigns, cold outreach sequences, sender migrations, new domain launches, and policy changes. DMARC is easier to manage when it is part of campaign operations rather than a one-time DNS project.
DNS Record Checks
- The DMARC record is published at
_dmarc.yourdomain.com. - There is exactly one DMARC TXT record at that host.
- The record starts with
v=DMARC1. - The
p=policy is intentional. - The
rua=destination is monitored. pct=is used only for an active rollout plan.
Authentication Checks
- SPF includes every platform that sends for the domain.
- DKIM signing is enabled for the domain in every major platform.
- At least one mechanism passes DMARC alignment for each mail stream.
- Custom return-path or custom DKIM is configured for third-party senders where needed.
- Test messages show DMARC pass in real recipient headers.
Reporting Checks
- Aggregate reports are being received.
- Reports are parsed into readable source-level results.
- Known legitimate sources are identified.
- Unknown high-volume sources are investigated.
- Failure rates are stable before enforcement changes.
Campaign Launch Checks
- The campaign sends from a domain covered by DMARC.
- The campaign platform signs with aligned DKIM or sends with aligned SPF.
- Seed tests show DMARC pass in headers.
- Subdomain policy will not unexpectedly affect the campaign domain.
- Any new sending domain is monitored before high volume.
FAQ: DMARC Checker and DMARC Records
What is a DMARC checker?
A DMARC checker looks up the TXT record at _dmarc.yourdomain.com and parses the policy tags so you can see the domain policy, report destinations, subdomain policy, alignment mode, and rollout percentage.
What does p=none mean?
p=none means monitoring only. Receivers can send reports, but the domain is not asking them to quarantine or reject mail that fails DMARC.
What is the difference between quarantine and reject?
quarantine asks receivers to treat failing mail as suspicious, often placing it in spam. reject asks receivers to reject failing mail outright.
Do I need SPF and DKIM before DMARC?
Yes. DMARC depends on SPF or DKIM passing with alignment. You should configure SPF and DKIM for legitimate senders before moving to DMARC enforcement.
What is DMARC alignment?
Alignment means the domain authenticated by SPF or DKIM matches, or organizationally matches, the visible From domain depending on relaxed or strict alignment settings.
What does rua do?
rua tells receivers where to send aggregate DMARC reports. These reports help you see which sources send mail for your domain and whether they pass authentication.
Should my DMARC policy be reject?
Many domains should eventually move to p=reject, but only after reports show that legitimate mail passes DMARC. Moving too fast can block real email.
Does DMARC improve deliverability?
DMARC supports deliverability by improving authentication and trust, but it does not guarantee inbox placement. Reputation, engagement, complaints, content, list quality, and volume still matter.
Final Recommendation
Use a DMARC checker before every serious domain setup, sender migration, DNS change, and enforcement rollout. Read the record as a policy, not just a string. Confirm the record exists at _dmarc, understand the main policy, verify reports, check subdomain coverage, review pct, and make sure SPF or DKIM alignment is working for every legitimate sender.
If your domain is still at p=none, treat that as the visibility phase. Use reports to map senders and fix alignment. Then move gradually to quarantine and reject when the evidence shows you are ready. If your domain is already at enforcement, keep monitoring reports so new platforms and broken configurations do not quietly damage mail flow.
Reading DMARC like a pro means connecting the DNS tags to operational decisions: who sends, who aligns, who fails, what receivers should do, and how safely the domain can enforce policy.
