DMARC Policy: None vs Quarantine vs Reject

DMARC policy is the switch that decides whether fake mail using your domain gets logged, shoved into spam, or rejected at the door. Get it wrong and you can block your own invoices, support replies, and forwarded mail. Get it right and spoofing gets a lot harder. If you want the bigger email setup picture first, start with business email and then come back here.

Most teams don’t fail because DMARC is complicated. They fail because they skip the boring part. They publish a record, leave p=none forever, and call it done. Or they jump straight to p=reject before every sender is aligned. That’s how legit mail disappears.

This guide gets to the answer fast: use p=none to find every real sender, move to p=quarantine once DKIM is aligned, then move to p=reject when failures are only spoofing and obvious junk. That is the safest path for almost every domain.

What is a DMARC policy?

A DMARC policy tells receiving servers what to do when a message using your domain fails DMARC. The three options are none, quarantine, and reject. The right DMARC policy depends on one thing: whether every legitimate sender for your domain already passes alignment.

DMARC only triggers when the message fails authentication at the domain level. In plain English, the receiver looks at SPF and DKIM, then checks whether either one aligns with the visible From domain.

If SPF aligns, DMARC passes.

If DKIM aligns, DMARC passes.

If both fail or are unaligned, the DMARC policy fires.

Which DMARC policy should you choose first?

Start with p=none unless you are absolutely certain every sender already has aligned SPF or DKIM. A DMARC policy should start in monitoring mode because you need real traffic data before you enforce anything.

Here is the safe starting record:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

This mode does not protect you from spoofing by itself. It gives you visibility. That matters because most domains have more senders than the owner thinks they do.

Typical surprise senders look like this:

1. Accounting software sending invoices.
2. HR or recruiting tools sending offer letters.
3. CRM or marketing platforms sending campaigns.
4. Help desk tools sending replies as your main domain.
5. User-level forwarding rules that break SPF on the next hop.

If you skip the monitoring phase, your DMARC policy becomes a blunt instrument. The failures won’t be theoretical. They’ll be real messages from real workflows.

For bulk senders, publishing a DMARC record is already part of modern sender requirements. Google’s sender guidance ties compliance to domain authentication and alignment behavior, especially once volume grows. The standard itself is defined in RFC 7489.

How long should a DMARC policy stay on none?

Keep your DMARC policy on none for at least two to four weeks. That window gives you enough time to catch weekly, monthly, and edge-case mail flows before you enforce anything.

Three days is not enough. It misses monthly invoices. It misses quarterly board updates. It misses the weird old app that only sends password resets when someone leaves for vacation and forgets their login.

A good monitoring window covers:

1. Regular business mail.
2. Marketing sends.
3. Billing cycles.
4. Support escalations.
5. Forwarded mail.
6. Third-party automations.

During this phase, review aggregate reports and sort failures into two buckets: legitimate systems you need to fix, and spoofing you want blocked later. That’s the whole job.

Example: your newsletter platform signs mail with its own domain, not yours. SPF may pass for the platform, but DKIM is unaligned. DMARC still fails. Your next step is not “turn on reject.” Your next step is “fix alignment.”

If you are setting up domains inside TrekMail, the DNS workflow is already structured around this. The platform shows required records, verifies them live, and flags problems before the domain goes active. See adding a domain and required DNS records.

Why does DMARC policy break when forwarding is involved?

Forwarding breaks SPF because the forwarder sends from its own server, not yours. A strict DMARC policy survives forwarding only when DKIM stays valid and aligned. That is why DKIM, not SPF, is usually the anchor for a safe DMARC policy.

This is the trap that catches otherwise competent admins.

Email has more than one sender identity. The user sees the From address. The server uses an envelope sender for bounce handling. SPF checks the envelope path and sending IP. DMARC then asks whether that SPF result aligns with the visible From domain.

When mail is forwarded, the sending IP changes. Your original SPF authorization often no longer applies. DKIM can survive because the signature travels with the message body and headers, assuming the forwarder does not mangle the content too much.

That is why these two statements can both be true:

1. SPF fails after forwarding.
2. DMARC still passes because DKIM aligns.

If forwarded mail matters to your business, your DMARC policy should not move to enforcement until aligned DKIM is working for every legitimate sender. If you forward mail into Gmail, read forward domain email to gmail. If you are troubleshooting forwarding failures in general, use email forwarding.

ARC exists to preserve authentication context across intermediaries and mailing lists, but it is not a substitute for doing your own alignment work. The protocol is documented in RFC 8617.

When should you move a DMARC policy to quarantine?

Move your DMARC policy to quarantine once your reports show that legitimate senders pass through aligned SPF or DKIM. Quarantine is the safety stage: failures usually land in spam instead of vanishing outright.

The record looks like this:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com

This is the scream test. If you missed one real sender, users usually notice because the message lands in junk instead of disappearing at SMTP time.

That gives you a recovery path:

1. A user reports missing mail.
2. You inspect the sender and alignment.
3. You fix SPF, DKIM, or both.
4. You re-test before moving to reject.

Some teams ramp with pct=25 or pct=50. You can do that, but most small and mid-sized setups don’t need the extra complexity. A partial DMARC policy creates a fuzzy state where some failures are enforced and some are not. If your discovery work was solid, go straight to quarantine at 100%.

If your sending stack lives inside TrekMail paid plans, Managed SMTP helps here because messages are signed correctly for your domain. TrekMail’s spam guidance explicitly calls out the expected case where SPF fails but DKIM passes on forwarded mail. See my emails go to spam.

When should you move a DMARC policy to reject?

Move your DMARC policy to reject when failures in your reports are no longer legitimate business systems. Reject is full enforcement. It is the only DMARC policy that actually tells receivers to block failing mail instead of accepting it.

The record is simple:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com

This is the end state most serious domains want.

Why?

1. It stops direct domain spoofing much more effectively.
2. It reduces the blast radius for phishing and business email compromise.
3. It signals to large receivers that you operate a disciplined domain.
4. It is the standard target if you want strong brand protection.

Google documents rejection and rate-limit behavior for unauthenticated and unaligned mail in its sender FAQ, including DMARC-related errors such as 4.7.31 and alignment issues like 4.7.32. In hard-fail cases you will also commonly see Gmail bounces mentioning 5.7.26 and your domain’s DMARC policy. See Google’s email sender guidelines FAQ.

One warning: reject is not forgiving. If finance still sends from an old SaaS tool with broken DKIM, those invoices are gone. Not late. Gone.

What DMARC policy record should you publish in DNS?

Your DMARC policy record belongs at _dmarc.yourdomain.com as a TXT record. The value can be short, but the consequences are not. Publish only one DMARC policy record per domain.

Basic examples:

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
_dmarc.example.com  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
_dmarc.example.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

If you use TrekMail, the required DNS baseline for a new domain typically includes MX, SPF, DKIM, and DMARC together. The docs show the expected pattern:

@                MX   10 mail.trekmail.net.
@                TXT  "v=spf1 include:spf.trekmail.net -all"
dkim._domainkey  TXT  "<unique value from dashboard>"
_dmarc           TXT  "v=DMARC1; p=quarantine;"

Do not publish two SPF records. Do not guess at DKIM values. Do not leave old MX records around and hope for the best. If you are bringing your own outbound provider, TrekMail supports that too, but alignment is still your job. See custom SMTP (BYO).

What are the common DMARC policy mistakes?

The most common DMARC policy mistakes are leaving p=none forever, enforcing too early, relying on SPF alone, and forgetting subdomains. None of these are rare. All of them break production mail.

Watch for these:

1. Leaving the DMARC policy on none for months. That gives you reports, not protection.
2. Skipping DKIM alignment because SPF “looks green.” Forwarding will expose that fast.
3. Forgetting subdomain behavior. Use sp= if you need a different subdomain policy.
4. Ignoring SPF lookup limits. More than 10 DNS lookups can trigger PermError.
5. Trusting a platform that sends as your domain without verifying how it signs mail.

A useful subdomain example looks like this:

v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@yourdomain.com

That lets you keep a strict DMARC policy on the root while testing a subdomain separately.

How TrekMail helps you reach a safe DMARC policy

TrekMail gives you the DNS and sending foundation to get to an enforced DMARC policy without stitching together five admin panels. The old way is per-user pricing, scattered DNS, and mystery senders. The new way is one multi-domain dashboard, pooled storage, and a standards-first mail stack.

For small teams, TrekMail’s paid plans start at $3.50/month on Starter and include Managed SMTP. For operators who want full control, the Nano plan is always free and supports BYO SMTP. TrekMail is IMAP only, supports custom domains, catch-all, mailbox forwarding, migration, and API access.

That matters for DMARC because the hardest part is not publishing the TXT record. It is controlling the systems allowed to send as your domain.

With TrekMail, you can:

1. Manage many domains from one place.
2. Verify required DNS records before going live.
3. Use Managed SMTP on paid plans or bring SES/SendGrid on Nano.
4. Keep mailbox hosting separate from outbound provider choice.
5. Migrate old mail in with built-in IMAP migration instead of rebuilding from scratch.

If you are still in setup mode, set up email on my domain covers the full domain workflow. If you are running several brands or client domains, multi domain email hosting shows the operational model.

Final answer: the best DMARC policy path for most domains

The best DMARC policy path is simple: start with none, fix alignment, move to quarantine, then end at reject. A DMARC policy is not a checkbox. It is an enforcement ladder, and each rung exists for a reason.

If you want the short version, here it is:

1. Use p=none for 2 to 4 weeks.
2. Fix every legitimate sender to align with SPF or, better, DKIM.
3. Move to p=quarantine for soft enforcement.
4. Move to p=reject once remaining failures are just spoofing and garbage.

That is how you keep real mail flowing while shutting down fake mail using your domain. If you want to do it without per-user pricing and without juggling separate mailbox hosting, forwarding, and migration tools, start with TrekMail’s docs or compare plans at https://trekmail.net/pricing.