Quick answer
When a strict DMARC policy quarantines or rejects mail from a legitimate platform, the policy is not too strict. The platform is unauthenticated and unaligned for your domain. A receiver checks whether SPF or DKIM produces a pass that aligns with the visible From domain (RFC 7489 §6.6.2), and if neither does, your p=quarantine or p=reject policy is applied exactly as published. The fix is to authenticate and align the sender by adding it to SPF and setting up DKIM so at least one identifier aligns. Lowering your policy is not the fix.
Why "too strict" is usually a misdiagnosis
A DMARC policy at p=quarantine or p=reject tells receivers what to do with mail claiming to be from your domain that cannot be authenticated and aligned. When a real platform like a CRM, ESP, help desk, or invoicing tool gets caught by that policy, the policy is doing its job. It found a sender that fails authentication for your domain and treated it as the published policy instructs.
DMARC passes when at least one of two paths produces an aligned pass:
- SPF alignment. SPF passes for the return-path (the envelope
MAIL FROM, theRFC5321.MailFromidentity), and that return-path domain aligns with the visibleFromdomain. - DKIM alignment. A DKIM signature verifies, and the signing domain in the
d=tag aligns with the visibleFromdomain.
Only one aligned pass is needed. A third-party platform usually sends from its own infrastructure with its own return-path and signs with its own domain, so neither identifier aligns with yours. SPF might pass for the platform's domain and DKIM might verify for the platform's domain, yet DMARC still fails because nothing aligns with the From address your recipients see. The gap is alignment, not policy strength.
How to find the blocked sender
DMARC aggregate reports are how you identify which sender is failing. When you publish a rua= tag, receivers send back periodic reports describing the mail they saw claiming to be from your domain. Each report records the identifier evaluated by SPF and its result, the identifier evaluated by DKIM and its result, and for both an indication of whether the identifier was in alignment (RFC 7489 §7.2). It also records the policy that was applied and how many messages it covered.
Read those reports and look for the rows where the disposition is quarantine or reject and both alignment columns show a failure. The SPF and DKIM identifiers on those rows tell you which sending source the unaligned mail came from. Match that source against the platforms you actually use, and you have found the legitimate sender that your policy is catching. For a field-by-field walkthrough of these reports, see how to read a DMARC aggregate report.
How to fix it without weakening policy
- Identify the platform. From the aggregate reports, confirm which legitimate service the unaligned mail belongs to. Do not start changing DNS until you know exactly which sender you are authorizing.
- Add the platform to SPF. Most platforms publish an
include:mechanism for their sending infrastructure, or ask you to set a custom return-path (a subdomain that points at them) so SPF passes for an envelope domain that aligns with yourFrom. Add theirinclude:to your single SPF record, or configure the custom return-path their setup wizard specifies. - Set up DKIM for the platform. Publish the DNS records the platform gives you so it signs your mail with a
d=value that aligns with your domain. Many platforms use CNAME delegation: you publish aCNAMEunder your own domain (for exampleselector._domainkey.yourdomain) pointing at the provider, and the provider manages the signing key behind it. SendGrid, for instance, handles "the signing of your DKIM and the authentication of your SPF withCNAMErecords" once you publish them, and Google Workspace has you publish a DKIM key for your domain so its servers sign your outgoing mail. - Confirm in the next aggregate report. After the records propagate, wait for the next report and check that the rows for that source now show an aligned pass on SPF, DKIM, or both. Alignment on either identifier is enough for DMARC to pass.
- Keep
p=where it is. You do not touch your policy. Once the sender aligns, its mail passes DMARC and is delivered, while every unaligned spoof of your domain stays blocked.
The anti-pattern is dropping to p=none or cutting pct to make the delivery problem disappear. The pct tag is a percentage of your mail stream to which the policy is applied (RFC 7489 §6.3); it is a staged-rollout lever for tightening a brand-new policy, not a repair for one blocked sender. Setting p=none or lowering pct does deliver the platform's mail again, but only by switching off enforcement for everyone. Spoofers get the same free pass as your CRM. You would be disabling protection for the whole domain to onboard one sender, which is the wrong trade. Authenticate the sender instead, and protection stays intact.
This is a different task from the staged none to quarantine to reject rollout. If you have not yet reached an enforcing policy and are working out how to get there safely, see moving DMARC from p=none to p=reject. The case here assumes your policy is already strict and you are onboarding a legitimate sender without regressing it.
What this does not prove
Relaymetry reads your published DMARC record and reports the policy it finds. A public DNS check confirms what your p=, sp=, and pct= tags say and whether a rua= address is set, but it cannot tell you which third-party platform is failing alignment, whether a specific past message passed or failed, or whether SPF and DKIM are aligned for any given sender. Those answers live in your aggregate report feed and in the headers of real delivery attempts.
Confirming your policy is strict does not confirm the fix worked. After you authenticate a platform, only the next aggregate report shows whether that source now aligns. A check of the record alone cannot see the alignment result for an individual sender, so treat the report feed as the source of truth for whether onboarding succeeded.