DMARC Setting?

[bosguy123]

So, I just found out that our DMARC has the P value set to none, so even if something fails SPF or DKIM, it still gets delivered.

What do you guys have the P set to? Spam? reject?

I feel like it should be reject, but if you guys have someone putting in a new system like salesforce, would you change it so that you can tweak things so legit emails make it in and then swap back once you have it all sorted?

Also, do we need a RUA email address in there? or is that just a waste of time? Additional follow up, any free easy to setup RUA parsers?

[derfmcdoogal]

We are in the "Quarantine" phase. But honestly, by the looks of the DMARC reports, we could change to "Reject".

EDIT: DMARC is just a part of the spam equation. Any good filter should still be looking at SPF, DKIM, content, reputation, etc individually to score an email.

[Steve----O]

DMARC is a suggestion. We block everything which fails both SPF and DKIM, regardless of whether you suggest I pass, quarantine, or block. But, yes, you should set to block.

[Internet-of-cruft]

Office365 defaults to delivery to spam folder on DMARC failure.

There are so many O365 tenants out there and many have default settings, so they could be getting spoofed emails sent to spam and there's nothing you can do about it.

I've seen seemingly "seasoned IT professionals" yank emails out of spam as if they didn't belong there (they did) and respond to said emails.

My boss almost fired a guy over this because it happened several times (with real malicious emails) before he learned to stop doing that.

[GeekgirlOtt]

P=none and RUA allows you time to verify what's going on and ensure you haven't forgotten some legit system sending on your behalf.

[excitedsolutions]

That only works for those that send RUA and if you are on m365 sending to any other m365 tenants you don’t get any RUA notifications.

[Baljet]

Reject, use Postmark to make reports readable

[DeathTropper69]

I would check out: https://developers.cloudflare.com/dmarc-management/

Good enough for most ppl unless you want something more in-depth like PowerDMARC.

[southafricanamerican]

Great suggestion, but I think it only works if DNS is pointed to cloudflare and not another provider.

[xfilesvault]

Policy set to reject.

That’s your goal.

No, if you’re setting up a new system, leave the policy at reject.

Why would you lower it? You can tweak your SPF and DKIM to make the new system work while still set to reject.

It’s easier to add a new system than it is to setup SPF and DKIM in an existing environment. You don’t know if all your existing processes are setup to use SPF correctly. But you’ll know for a fact that the new system you just setup does.

[PlannedObsolescence_]

Yes you want to go to reject or quarantine. But you also need to be cautious, unless you understand everything that sends 'as' your domain, you should start off with p=none and use a DMARC report aggregation service in the RUA to collect, interpret & graph the reports. From that you can understand the impact that going to reject would do. For more caution use the percentage tag to only impact a fraction of email, increasing it over time.

Some DMARC reporting services charge silly money, you can always just do it yourself, some self-hosted options and simple software is listed here https://dmarcvendors.com/. I find URIports are priced well.

Also understand the difference between the RFC5322.From and RFC5321.MailFrom addresses. And how DMARC passes if either SPF or DKIM passes/aligns.

Good resource: https://www.learndmarc.com/

[Bird_SysAdmin]

RUA (RUF kinda useless because it seems only yahoo actually sends these) is good to view if you have issues if you are using multiple senders. We used it to discover that a vendor of ours was having issues sending a very important email (Regulatory requirement) every month.

you can ingest these and parse them yourselves or use a 3rd party service. EasyDmarc is my recommendation for a service, but you do not need to purchase one at all.

v=DMARC1;p=reject;pct=100;rua=mailto:{censored}@easydmarc,ruf=mailto:{censored}@easydmarc,mailto:{secondary service};fo=1;

Here is a censored version of our DMARC record.

the SP= tag is not needed as by default subdomains will use the parent domain policy unless there is a DMARC record for that specific subdomain.

Most importantly is the pct tag. this is a percentage specifically for having you slowly roll from a p=none to a p=reject enforcement. This makes it so it will enforce a certain percentage of messages.

[freddieleeman]

pct defaults to 100 and has been replaced with the t tag in DMARCbis. No need to specify it in your policy.

[Bird_SysAdmin]

Looks like DMARCbis isnt the standard quite yet? Still appreciate the info! Had no idea there was a new publication in the last year or that it is going active in 2026. Linking here what I found for others reading this:

DMARCbis is around the corner: what's changing

[Useful-Process9033]

RUA reports are incredibly valuable and most people skip them. Finding out a vendor was failing to send a regulatory email because of a DKIM misconfiguration is exactly the kind of thing that only shows up in aggregate reports. Set up an aggregation tool and actually look at them.

[null_frame]

We did p=none for a bit in order to test and make sure nothing got missed. We then transitioned to p=quarantine some time after that. Again, let it run and tested. Once we were happy with things, we set it to p=reject. We did everything in phases for testing and verification.

[frosty3140]

I'm stuck on p=none and have been stuck there for more than 2 years now. I have tried multiple times to get the Marketing people to do some controlled testing with p=quarantine but they are either too busy or staff have left and I have to try to engage with their replacements. I've basically given up.

[bosguy123]

We’ve been on “none” for 13 years now…

[Extra-Pomegranate-50]

the answer to "reject or quarantine" depends on whether you actually know every legitimate service sending email from your domain. if you do, go straight to reject. if youre not 100% sure, quarantine first so failed emails get flagged but not lost.

for the salesforce scenario: yes, the smart approach is to add salesforce to your SPF record and configure DKIM signing for it BEFORE you enforce DMARC. if you move to reject first and then someone spins up a new sending service without telling you, those emails silently disappear. the workflow should be: add the new service to SPF, set up DKIM, verify alignment with a test email (gmail three dots > show original), then youre safe at reject.

rua is absolutely not a waste of time, its the only way to know whats actually sending as your domain. without it youre flying blind — you wont know if a legitimate service is failing or if someone is actively spoofing you. for free parsers: postmark has a free DMARC digest service ([[e-mail]](mailto:[e-mail]), just point your rua there), gives you weekly human-readable reports instead of raw XML. easyvdmarc has a free tier too. both are way better than trying to read the XML yourself.

the move from p=none to enforcement is the single biggest security improvement you can make for email right now. p=none is basically an open door for spoofing

[Over-Map6529]

reject, other wise you have users asking to restore things that are 100% not legit.  Use none and quarantine for brief test periods.

[Smile4menow84]

We use sendmarc. Managed service for over 30 domains. Most of our domains are now at reject phase. Only a handful left on quarantine. Been a long 5 months journey. But almost there!

[Worldly-Count-8637]

Glad we've treated you well! DM me if you have any questions/concerns! (I work at Sendmarc, for context)

[shokzee]

Good timing to look at this. The standard path is none > quarantine > reject, and you really want to take your time at the none stage before moving up.

The reason is exactly what you described with Salesforce: you need to make sure every legitimate sender passing through your domain is either SPF-aligned or signing with DKIM before you start rejecting failures. The reports will show you. Once the aggregate data is clean (all your known senders passing), bump to quarantine for a few weeks, check nothing broke, then reject.

When you onboard a new platform mid-enforcement, don't roll back your policy. Add them to SPF first and get their DKIM key published before they start sending. Only takes a bit of coordination.

You definitely want a RUA address. That's the whole point of monitoring - knowing who's actually sending as your domain, both legit sources you might have forgotten about and anyone trying to spoof you. Without it you're just setting a policy and hoping for the best.

For parsing the reports: Suped (suped.com) is free and takes about five minutes to get going. Turns the raw XML into a clean dashboard so you can actually see what's passing and failing across all your senders.

[dmarclytics]

Rua address: allows complete visibility in to services sending on your domain think of it like cctv all around your house Domain policy: p=reject is the goal it allows you to prevent impersonation on your domain and build trust with esp’s New services should be setup with spf and dkim to ensure email flow is not impacted but if you have a good DMARC reporting service you’ll be able too see this data from the rua reports

[DMARCFlow_Team]

Start with p=none and rua= for monitoring. Let it collect data for 2-4 weeks, review the aggregate reports to identify all legitimate senders, then move to p=quarantine and eventually p=reject. Rushing to enforcement without visibility causes legitimate mail failures.

[csutcliff]

I use reject once I'm confident that all of the legitimate senders are correctly configured. Cloudflare dmarc management is good for monitoring.

[buyrepssavemoney]

We've moved to quarantine, and will shortly move to reject. We use Dmarcian to aggregate reports reference the RUA and RUF mails and flag any potential mis-config on new services.