DMARC (Domain-based Message Authentication, Reporting and Conformance) builds on SPF and DKIM rather than replacing them. It does two things: it tells receiving mail servers what policy to apply when a message fails SPF or DKIM checks, and it gives you reporting on authentication results across your domain.
Start with monitoring, not enforcement
A DMARC record published with a "p=none" policy does not block or quarantine any mail — it only requests reporting. This is the safest starting point, because it lets you see how your mail is authenticating in the real world before you risk blocking legitimate messages.
Why domains jump straight to a strict policy and regret it
Setting a DMARC policy to "reject" before SPF and DKIM are both confirmed working across every service that sends mail on your behalf (not just Google Workspace) can cause legitimate mail — including mail from third-party tools — to be silently discarded. This is one of the more common self-inflicted delivery problems we see, and it usually happens when a business tightens DMARC policy without first checking every sending source.
Moving to enforcement
Once reporting confirms your legitimate mail sources are all authenticating cleanly, the policy can be tightened in stages — typically from monitoring, to quarantine, to reject — rather than jumping straight to full enforcement.