DMARC set to p=none enforces nothing

A DMARC record can exist without asking mail providers to enforce it. That distinction matters if your company sends invoices, password resets or customer updates: a green “record found” result is not the same thing as a policy against unauthenticated use of your domain.

In our September population scan, 36.6% of 1,054 US B2B SaaS companies with 5 to 50 employees (386 companies) published DMARC at p=none. That is a useful configuration to investigate. It is not evidence that those companies have been impersonated, nor that their mail administrators have abandoned the work.

A monitoring policy is not an enforcement policy

DMARC evaluates whether a message has an SPF pass or a DKIM pass aligned with its visible From domain. Either aligned pass can satisfy DMARC; both are not required. The domain owner publishes a policy for messages that fail.

With p=none, the owner expresses no preference for special handling based on that failure. It does not mean “deliver the message.” Receiving providers still apply their own filtering. Quarantine and reject express stronger policies, but the receiver ultimately decides how to handle the message. The current DMARC specification defines those distinctions.

Reporting is a separate part of the configuration. A rua destination requests aggregate reports; setting p=none alone does not arrange for reports to arrive. A monitoring policy can therefore be a sensible starting point, but the record itself does not tell us whether anyone is receiving or reviewing useful feedback.

The gap between setup and follow-through

Consider a hypothetical SaaS business that sends account email through its application, invoices through a billing service and campaigns through a marketing platform. Someone adds a DMARC record during setup. Later, a different team adds another mail provider. The record still exists, so a simple presence check continues to look reassuring.

The question is not just “Do we have DMARC?” It is whether the company knows its legitimate sending services, whether those services authenticate correctly, and whether the published policy matches the intended result. An attacker can forge a From address; whether a forged message reaches an inbox depends on authentication and the receiver’s controls. Our DNS observation does not test that delivery outcome.

Start with our free domain check. If it flags one or two checks, helping you fix them is on us; broader findings are a reason to talk. We confirm legitimate mail services before recommending DNS changes. For a wider view of the public-facing footprint, an External Security Posture Assessment is the next conversation.

What to actually do about it this week

• Inspect the actual policy. Look up the TXT record at _dmarc.yourdomain.com. Record presence alone is not enough; read the policy and reporting settings.
• Identify every legitimate sender. Include your application, billing, marketing and support services. Confirm who owns each integration before changing records.
• Review authentication and reporting. Check alignment for those legitimate mail streams and make sure reporting is configured and actually being reviewed.
• Plan enforcement with that evidence. Resolve legitimate failures first, assess effects on forwarding and mailing lists, then make and monitor a deliberate policy change. Do not copy a stricter record into production just to improve a score.

Methodology: This finding comes from OrangeStealth’s passive, public-data-only September refresh, generated 2026-09-04: N = 1,054 US B2B SaaS companies with 5 to 50 employees. The published result is anonymized and k-anonymised, with no company named. These are point-in-time external observations, not inbox-delivery tests, proof of exploitation, or a representative estimate for every startup.