SenderGuard

Proof‑of‑Scan & Verify: why it builds trust

Anyone can claim “you’re compliant”. What matters is whether results can be reproduced by others. That’s what Proof‑of‑Scan provides: stable JSON, a sha256 hash, and an open Verify endpoint that re‑computes using multiple DNS resolvers.

Try it

Run an audit, then open the Verify link on the results or PDF tail page.

What’s inside the proof

  • Stable, canonical JSON (sorted keys, LF line endings, UTC timestamps)
  • sha256 over the canonical JSON
  • scanId and a Verify endpoint that re‑computes via 1.1.1.1/8.8.8.8/9.9.9.9
  • RulePack version used for scoring

How Verify works (resolver quorum)

Verify re‑computes using multiple public DNS resolvers. If at least two agree on TXT answers within timeout, we treat the recompute as authoritative. This protects against transient resolver quirks.

Tamper detection

  • Hashes mismatch → either config changed (expected) or the JSON was altered (unexpected)
  • Compare timestamps and rulepackVersion to differentiate expected drift vs tampering

API endpoints (public)

  • GET /api/scan/:id.json → canonical JSON
  • GET /api/scan/:id.proof → { scanId, sha256, scannedAt }
  • POST /api/verify { scanId } → { matched, before, after, diffs[] }

Use cases

  • Agencies: white‑label PDFs with verifiable tail pages for client delivery
  • Engineering: store JSON + sha256 in CI artifacts; re‑run Verify on release
  • Security: share proof with auditors without exposing email bodies

FAQ

What if DNS changed after the scan?

Verify will recompute “after” values. Proof still documents the “before”. That’s the point: you can prove what was true at scan time.

Can we keep proofs long‑term?

Yes. Keep JSON/sha256 longer than PDFs (e.g., 1 year). PDFs are for human consumption; JSON+hash is for verifiability.

Next steps