All packsTransactional Email Deliverability CoreSolve
dmarc p=reject broke our email root domain
p=reject on day one rejects your own Workspace mail too
DMARC governs the whole domain it's published on -- jumping straight to p=reject on a root domain with other senders (Workspace, a CRM) silently rejects their mail too.
What goes wrong
Setting _dmarc.yourdomain.com straight to p=reject looks like the secure move -- reject anything that fails authentication. But DMARC governs the entire domain the record is published on, not just the new app sending mail. If Google Workspace, a CRM, or a billing tool also sends as your domain, they now get rejected by mailbox providers too, the moment this record goes live, with no staging period to notice authentication gaps first.
Why agents get it wrong
"Reject unauthenticated mail" reads as the obviously correct security posture for a new mail-sending feature, and most DMARC tutorials that focus on a single app's deliverability don't dwell on the fact that the record is domain-wide, not app-specific -- the interaction with other senders on the same root domain is a fact about DNS scope, not about the new code being written.
What Transactional Email Deliverability Core pre-decides
The pack's DMARC staging plan is pre-decided operational policy, not a code default: p=none with rua reporting for 2+ weeks, then p=quarantine ramping 25% to 100% over 2-4 weeks, then p=reject only after 2 clean weeks at full quarantine -- and the sending domain is a dedicated subdomain (mail.yourdomain.com) specifically so the whole staged rollout, including any eventual reject, can run there without ever touching the root record other senders depend on.
Source: ARCHITECTURE.md 'DNS + DMARC staging'