Folderly Flash Send-readiness test
Have Folderly fix this

Audit an existing DMARC record

Audit DMARC by checking the record, the aligned identity on a real message, report flow and the policy's fit for this domain. A syntactically valid TXT record is only the first of those four checks.

Why mailbox providers enforce this

Gmail and Yahoo require bulk senders to publish DMARC and pass alignment, but both accept p=none as the minimum policy. RFC 9989 defines monitoring and enforcement more precisely, removes the historic pct tag, and warns that p=reject can disrupt legitimate indirect mail for general-purpose domains. DMARC validates use of the From domain; it does not guarantee inbox placement or force every receiver to apply the requested disposition.

Primary sources for this guidance

How to fix it

  1. Inspect a representative received message. Confirm that SPF or DKIM passes and that at least one authenticated domain aligns with the visible From domain under the published aspf or adkim mode.
  2. Query _dmarc.yourdomain and keep one valid DMARC1 TXT record. Check p, sp, np, rua, ruf, adkim, aspf and t only when each tag expresses an intentional policy.
  3. Treat pct as historic under RFC 9989. Some older receivers and tools may still interpret it, so remove it through a reviewed compatibility change rather than relying on it for percentage rollout.
  4. Verify that aggregate reports arrive and are parsed. If a rua destination is on another domain, confirm the external reporting authorization required by the current reporting specification.
  5. Inventory every legitimate sender in the reports and remediate any stream that does not pass aligned SPF or DKIM. Prefer a durable aligned DKIM signature for mail that may be forwarded.
  6. Choose policy for the domain's actual use: p=none for observation, p=quarantine for enforcement with review, and p=reject only when authorized streams and indirect-flow risks are understood.
  7. Review subdomain and non-existent-domain handling with sp and np. Active mailstreams may need explicit records; unused names can usually take a stricter policy.
  8. Retest a fresh production-path message after DNS propagation, then keep monitoring reports and receiver outcomes. A DMARC pass proves aligned identity for that message, not future placement.

Limitations

This audit checks published policy and the identities visible on the tested message. It cannot inventory an entire sending estate from one email, prove that every receiver honors the requested policy, or guarantee inbox placement.

Next action Send a fresh message through the production mail path after DNS is observable. Use Flash to verify message-level alignment and the current policy, then compare the result with aggregate-report coverage before enforcing.
Run a free test →

FAQ

Does Gmail require p=reject?
No. Gmail's bulk-sender requirement accepts a valid DMARC record with p=none, provided the direct message passes alignment. A stricter policy is an anti-spoofing decision, not an inbox guarantee.
Should I still use pct for a gradual rollout?
Do not design a new rollout around pct. RFC 9989 marks it historic and replaces only the old testing behavior with t. Because receiver adoption is mixed, change a legacy pct record deliberately and monitor real outcomes.

Related

Content record Owner: Folderly Flash content operations Reviewed: 2026-08-11 Maintenance trigger: Review when the IETF updates DMARC or its reporting RFCs, Gmail or Yahoo changes sender requirements, or Flash changes the dmarc_policy subcheck.
Want a deliverability engineer to fix this for you? Hand it to Folderly →