Key findings that affect how DMARC findings are evaluated include the complete absence of a DMARC record, syntax errors, an ineffective passthrough policy, missing reporting configuration, use of unauthorized third-party reporting, and a low percentage of emails being filtered.
Messages are used to alert you to the severity of the DMARC finding. Learn more about how DMARC findings impact your grade below:
Bad Finding Messages
Passthrough policy with authenticated third party report: A DMARC policy is in place, however p=none, providing no protection for recipients of spoofed email. Authorized third-party reporting is in place.
Want to remediate this finding? Switch to p=quarantine or p=reject as soon as possible.If needed, use the pct parameter to control the enforcement rate, removing pct when confident in the deployment.
Passthrough policy with non-authed third party reporting: A DMARC policy is in place, however p=none, providing no protection for recipients of spoofed email. Third-party reporting is in place however is unauthorized. See why this is an issue.
Want to remediate this finding? Switch to p=quarantine or p=reject as soon as possible.Implement third-party reporting authorization to ensure that reporting email for this domain is received.
Passthrough policy with no reporting: A DMARC policy is in place, however p=none, providing no protection for recipients of spoofed email. No authentication statistics are being sent.
Want to remediate this finding? Switch to p=quarantine or p=reject as soon as possible.If needed, implement reporting to monitor authentication statistics and use the pct parameter to control the enforcement rate, removing pct when confident in the deployment.
Passthrough policy with self reporting: A DMARC policy is in place with self-reporting.
Want to remediate this finding? Switch to p=quarantine or p=reject as soon as possible.If needed, implement reporting to monitor authentication statistics and use the pct parameter to control the enforcement rate, removing pct when confident in the deployment.
Record does not exist: Domain has no DMARC record in place.
Want to remediate this finding? See how to set a DMARC policy and implement a DMARC policy for this domain.
Record is invalid: There is a record in place, but it has syntax errors or is otherwise misspecified.
Want to remediate this finding? Ensure there are no syntax errors in place within the DMARC record; e.g. separators are correct and that record starts with v=DMARC1 and is immediately followed by the policy tag.
Warn Finding Messages
Active policy with pct<50: There is a DMARC policy in place, however it has a percentage value less than 100, which means that some spoofed email will be delivered.
Want to remediate this finding? When setting a DMARC policy, make sure to set the policy percentage value equal to 100 (pct=100).
Fair Finding Messages
Active policy with non-authenticated third party reporting: Third-party reporting mailto links that lack corresponding authorization records for their domains will not receive reporting emails. See why using unauthorized third-party reporting is an issue.
Want to remediate this finding? Implement third party reporting authorization to ensure that authentication failure reports for this domain will be received.
Active policy with pct<100: There is a DMARC policy in place, however it has a percentage value less than 100, which means that some spoofed email will be delivered.
Want to remediate this finding? Set the policy percentage value equal to 100 (pct=100).
Good Finding Messages
Active policy with authenticated third party reporting: There is a DMARC policy in place with authorized third-party reporting.
Active policy without reporting: A policy is in place, however no reporting is being collected about authentication failures. See why not having a reporting configuration is an issue.
Best practice tip: Implement reporting to obtain authentication statistics.
Active policy with self reporting: A policy is in place with self-reporting.
Interested in learning more about mitigating DMARC risk?
- Learn how to set a DMARC policy.
- Understand how the DMARC risk vector impacts your Bitsight rating.
- Do you need a DMARC record for a parked domain? Learn more on how to evaluate and remediate Parked Domains
- Learn more about why DMARC is important to protecting your cybersecurity risk on the Bitsight blog.
- January 28, 2026: Restructured article.
- January 20, 2026: DMARC Risk Vector is recategorized from a temporarily non-graded risk vector to informational and does not affect Bitsight Security Ratings.
- April 16, 2024: Non-graded.
- March 29, 2024: Linked to API.
- March 5, 2024: Published.
Feedback
0 comments
Please sign in to leave a comment.