PDF evidence: structure and verification
Evidence that can be independently verified is far more convincing than screenshots. Here’s what a high‑quality report must contain and how each piece supports a trustworthy audit trail.
Generate a sample
Download a sample report — or run an audit and create a branded PDF for your organization.
Design goals
- Reproducibility: third parties can recompute and match hashes
- Actionability: Top 3 fixes with concrete steps, not vague tips
- Portability: shareable without exposing email bodies
- Brandability: agencies can white‑label for hand‑off
Must‑have sections
- Header: domain, time‑stamp (UTC), rulepack version
- Five badges: SPF/DKIM/DMARC/Alignment/One‑Click with pass/fail state
- Overall score and Top 3 actionable suggestions
- DNS & header excerpts: SPF/DMARC TXT, AR excerpts for context
- Proof section:
scanId,sha256, and a Verify URL - Branding (optional): logo/company/footer for agency delivery
White‑label & distribution
- Inject logo/company/brand color/footer; keep content identical for auditability
- Distribute via signed 24h links; re‑issue on demand from dashboard
Why the proof block matters
The proof block allows any third party to fetch the canonical JSON, re‑compute scores from multiple DNS resolvers, and compare sha256. That means “don’t trust us — trust the math”.
Retention & privacy
- PDFs are signed for 24h links; store the file for 30–90 days depending on policy
- No email bodies are saved; headers only;
.emlis deleted after parsing
FAQ
Can someone forge a PDF?
They cannot forge a PDF that matches the server‑side canonical JSON’s sha256. Verify recomputes from DNS, not from the PDF.
What if a vendor changes ranges?
Re‑run the audit and generate a fresh report. The proof clearly shows the rulepack version and scan time.