A DMARC policy tells receiving email systems how to handle messages that claim to come from your domain but fail DMARC. The three main policy options are:
p=none
p=quarantine
p=rejectThey are not simply "weak," "medium," and "strong" settings. Each one is appropriate at a different stage of protecting your domain. The safest approach is to start by understanding the email your business legitimately sends, then increase enforcement when the evidence supports it.
What DMARC policy controls
DMARC works with SPF and DKIM. A message passes DMARC when SPF or DKIM passes and aligns with the domain in the visible From address. For example, if a message appears to come from:
billing@yourbusiness.comDMARC checks whether the authenticated SPF or DKIM domain appropriately matches yourbusiness.com. If the message fails, the p= value in your DMARC record tells receiving systems how you want them to handle it. A record might look like:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourbusiness.comThe important part here is p=none.
p=none: learn before enforcing
p=none is the monitoring policy. It asks receiving systems to send feedback about messages that fail DMARC, but it does not ask them to quarantine or reject those messages. This is usually the right starting point for a business that has never reviewed its email authentication. Why? Because most businesses use more sending tools than they realize. You may know about your employee mailbox provider and newsletter platform, but forget about:
- A CRM sending automated follow-ups
- A help desk sending ticket replies
- An ecommerce platform sending order confirmations
- A billing tool sending invoices
- A website form tool sending notifications
- A transactional-email provider sending password resets
If you move to an enforcement policy before these legitimate senders are configured, some real business email may fail. With p=none, you can collect DMARC reports and identify the actual senders first.
What p=none does not do
It does not provide strong spoofing protection. A receiving system may still use its own filtering judgment, but your DMARC policy is not asking it to quarantine or reject messages that fail. Think of p=none as an observation period, not a final state.
p=quarantine: a cautious enforcement step
p=quarantine asks receivers to treat failing mail as suspicious. In many cases, that means a receiver may place the message in spam or junk rather than delivering it to the inbox. This can be a useful middle step when:
- You have reviewed your primary legitimate senders.
- SPF and DKIM are working for those senders.
- You are receiving DMARC reports.
- You want more protection while still watching for exceptions.
For example:
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourbusiness.comA quarantine policy can reduce the chance that an unauthenticated spoofed message reaches a recipient's inbox. But it is still not a substitute for correct SPF, DKIM, and alignment.
When quarantine can cause trouble
Suppose your marketing platform uses your domain in the visible From address but has not been configured for custom DKIM or aligned SPF. That legitimate campaign may fail DMARC. Under p=quarantine, recipients could see it in spam. This is why you should not use quarantine as a way to "test" whether everything is working. Test individual senders first, then use reports to validate the broader picture.
p=reject: the strongest instruction
p=reject asks receiving systems to reject messages that fail DMARC. For example:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourbusiness.comThis is the strongest policy because it tells receivers that mail failing DMARC should not be accepted as legitimate mail from your domain. A reject policy is valuable when you have a mature, documented sending setup and want strong protection against unauthorized use of your exact domain. But it is not a setting to turn on because it sounds more secure. A reject policy can block legitimate business email if:
- A forgotten service still sends from your domain.
- A new platform was added without domain authentication.
- A provider changed DKIM selectors or sending infrastructure.
- A forwarding or routing setup breaks a sender's authentication path.
- Someone changed DNS without understanding the impact.
The key issue: alignment
A message can pass SPF or DKIM and still fail DMARC. That is because DMARC requires alignment. For SPF, the domain evaluated by SPF—often the Return-Path or envelope-from domain—needs to align with the visible From domain. For DKIM, the domain in the signature's d= value needs to align with the visible From domain. A vendor may sign a message successfully with its own domain. That proves the vendor signed it, but it may not prove that the message is authorized to use your business domain. To see this clearly, send a real test message and inspect the headers. Look for:
spf=pass
dkim=pass
dmarc=passThen compare the visible From address with the SPF and DKIM domains shown in the header. Read DMARC alignment explained and how to check your DMARC record before changing policy.
A safe way to move from none to reject
Use a deliberate sequence.
1. Build a sender inventory
List every platform that sends email using your domain. Include marketing, support, billing, ecommerce, transactional email, website forms, and employee mailboxes.
2. Publish a valid DMARC record
If you have no record, begin with a valid p=none record and a reporting address you can monitor.
3. Review aggregate reports
DMARC aggregate reports help show source systems, message volumes, SPF/DKIM outcomes, and policy results. Classify each source as:
- Approved and passing
- Approved but failing
- Unknown
Do not authorize an unknown source simply because it appears in a report.
4. Fix approved-but-failing senders
Use each provider's official domain-authentication instructions. This may involve:
- Adding or correcting SPF authorization
- Publishing DKIM selector records
- Setting up custom-domain DKIM
- Configuring a custom return domain
- Removing a retired sender from your setup
5. Test real messages
Send test messages from every active platform. Check headers, not just inbox placement.
6. Move to quarantine
Once your legitimate senders consistently pass and align, quarantine can be a reasonable intermediate policy.
7. Continue monitoring
Do not treat enforcement as the end of the process. New vendors, DNS changes, and provider migrations can introduce a failure later.
8. Move to reject when the evidence is stable
Reject is most appropriate when you have a reliable inventory, verified senders, and continued visibility into changes.
Common DMARC policy mistakes
Moving to reject before identifying every sender
This is the biggest risk. Strong enforcement is helpful only when legitimate sources are known and configured.
Assuming DMARC reports are optional
Reports are the evidence that helps you decide whether enforcement is safe.
Leaving p=none forever without a reason
Monitoring is useful, but a business that has verified its senders may want stronger protection.
Changing several email settings at once
If you change SPF, DKIM, DMARC, and provider settings together, it becomes difficult to identify what fixed or caused a problem.
Treating DMARC as the whole security program
DMARC helps protect your domain from unauthorized email use. It does not prevent compromised accounts, invoice fraud, lookalike domains, or every phishing attempt. Use it alongside strong account security, internal verification procedures, and staff awareness.
Frequently asked questions
Is p=reject always best? It is the strongest enforcement policy, but only after legitimate senders are configured and verified. "Strong" does not help if it blocks real business mail. How long should I stay at p=none? Stay there long enough to identify and fix legitimate sending sources. The right timeframe depends on how many tools your business uses and how often it sends email. Does p=quarantine guarantee spam placement? No. DMARC asks receivers to quarantine failing mail, but each receiver applies its own handling and filtering decisions. Can a small business use DMARC? Yes. Small businesses often benefit because a domain can be spoofed regardless of company size. The key is starting with an accurate sender inventory.
The practical next step
Run a free check to see your current DMARC policy and whether the public record is visible. Then review the services that send mail for your business. Do not choose p=none, p=quarantine, or p=reject based on what sounds safest in isolation. Choose the policy your verified setup can support. Once the record is correct, monitor it. A policy that protects your domain today can be weakened by a future DNS change or a newly added sending platform. Run a free Beacon domain check →