Proofpoint DMARC checker: what the compliance check actually includes

Proofpoint's current DMARC Compliance Check is a form-led assessment, not an anonymous checker that immediately displays a result after you enter a domain. Proofpoint says the engagement includes a 15-minute kickoff call, a one-page assessment with SPF, DKIM, DMARC pass ratings and policy status, and a follow-up call. Use a public DNS lookup when you need the published record now; use message and aggregate-report evidence for pass-rate or sender-coverage decisions.

Quick takeaways

• Proofpoint's current official page describes a scheduled assessment with two calls.
• The promised one-page report includes SPF, DKIM, and DMARC pass ratings plus DMARC policy status.
• A public checker can read a DMARC DNS record immediately but cannot calculate traffic pass rates.
• Do not change policy from a vendor status label alone; identify legitimate senders and alignment first.
• Ask what data window, domains, sources, and assumptions support every reported percentage.

Is Proofpoint's DMARC check an instant tool?

No. The official Proofpoint Email DMARC Compliance Check describes this sequence: submit the form, join a 15-minute kickoff call, receive a one-page assessment, and discuss it during a follow-up call.

That is materially different from a public DNS lookup. The assessment may combine public records with data and interpretation collected during the engagement. The public page does not promise an immediate, anonymous result screen.

What can each path establish?

Proofpoint compliance assessment
  documented output: one-page SPF, DKIM, DMARC pass ratings and policy status
  requires: form and scheduled engagement
  ask: data window, domains, sources, exclusions, and calculation method

Public DMARC lookup
  output: record, policy, tags, and syntax visible in DNS now
  requires: domain only
  cannot show: historical message pass rates or complete sender coverage

Delivered-message headers
  output: SPF, DKIM, and DMARC result for one message path
  requires: a real message
  cannot show: every sender

DMARC aggregate reports
  output: receiver-reported authentication and alignment by source over time
  requires: a reporting address and collected XML
  cannot replace: owner confirmation before policy changes

The distinction matters because DMARC evaluates message authentication and identifier alignment, while the policy itself lives in public DNS. RFC 9989 defines the current mechanism; a one-time record lookup and a traffic assessment answer different questions.

Source: Original Palisade evidence diagram based on the Proofpoint DMARC Compliance Check and RFC 9989. Open the full-size diagram.

What should you ask before acting on the assessment?

Ask which domains and subdomains were included, the dates covered, which receivers supplied data, how SPF and DKIM pass rates were calculated, and whether percentages measure authentication or DMARC-aligned authentication.

Request the source inventory behind any failure rate. A source IP or provider name without a business owner is not enough to decide whether it is legitimate. Ask how forwarding, mailing lists, parked domains, and third-party senders were treated.

Finally, ask what evidence supports the recommended policy. A move to p=quarantine or p=reject should be tied to known senders, tested alignment, change ownership, and rollback criteria.

What should you prepare for the assessment?

Bring a domain and subdomain inventory, the current DMARC records, a list of known sending services, recent aggregate reports if available, and sample headers from important production paths. Mark domains that do not send mail and identify the policy you are working toward. This gives the kickoff a concrete scope and makes it easier to notice a missing source or domain.

Assign an owner for DNS, each major sender, and the policy decision. Note any seasonal or low-volume systems that may not appear in a short data window. If a third party manages part of the mail flow, record who can change its SPF return path, DKIM signing domain, or selector. An assessment can identify evidence, but it cannot supply business ownership for an unknown source.

Write down the decision criteria before seeing the report. At minimum, require the data window, included domains, source inventory, alignment method, exclusions, and the evidence behind each recommended action. Also define the rollback condition and approval path for any DNS change. That turns the one-page result into an input to change control instead of a standalone authorization.

How do you compare the assessment with your own evidence?

Start with the raw DMARC record and confirm the policy and report destinations independently. For each pass-rate or failure claim, trace the supporting sources in aggregate reports and compare sample headers from the same sending path. Differences may come from the reporting window, receiver coverage, forwarding, source grouping, or a distinction between authentication pass and aligned DMARC pass.

Document unresolved differences rather than averaging incompatible percentages. Ask Proofpoint which definition and dataset produced the number, then decide whether the same evidence supports the proposed policy for your domain. A report is most useful when another operator can reproduce the path from a recommendation back to DNS, message, or aggregate-report evidence.

Source: Original Palisade evidence-trace diagram based on the Proofpoint DMARC Compliance Check and the evidence model in RFC 9989. Open the full-size recommendation trace.

How can you verify the public record immediately?

Run the domain through the Palisade DMARC checker. It can show the record, policy, report destinations, and common syntax issues that public DNS exposes. It cannot produce Proofpoint's one-page assessment, calculate SPF or DKIM pass rates, inspect private traffic, or evaluate Proofpoint as a service.

Then send a production message and inspect its headers. For fleet-wide evidence, collect and analyze DMARC aggregate reports, whose current format is defined in RFC 9990. If you need to compare ongoing platforms, use the DMARC analyzer shortlist with requirements defined before vendor calls.

What should happen after a warning?

Treat the warning as a question to investigate, not permission to paste a generic record. If DNS is malformed, repair the exact syntax error and recheck. If a pass rate is low, map failures to senders and determine whether SPF or DKIM can align. If the policy is monitoring-only, establish coverage before enforcement.

Revalidate in four layers: public DNS, sender configuration, a delivered message, and aggregate reports. A green result at one layer does not clear the others.

Check the public record before the assessment call

Use the DMARC checker when the immediate question is what receivers can resolve from DNS. Bring that result, a sender inventory, sample message headers, and recent aggregate-report findings to any assessment conversation.

The lookup cannot calculate private pass rates, reproduce Proofpoint recommendations, inspect a Proofpoint tenant, or decide whether a contract fits your organization.

Sources and further reading

• Proofpoint: Email DMARC Compliance Check
• Proofpoint: DMARC policy and common failure causes
• RFC 9989: current DMARC protocol
• RFC 9990: aggregate reporting