Guide

How to prove the email you sent is the email that was approved

Every regulated email program has the same weak joint. The QA pass happens, the approval happens, and then the email keeps moving: a developer hotfixes a link, someone swaps a tracking pixel, the send platform rewraps URLs. When compliance later asks “is what went out what we approved?”, the honest answer at most shops is a screenshot, an email thread, and a shrug. Approval was an event, not a property of the file.

Bind the approval to the bytes

The fix is old cryptography applied to a new joint: at the moment of sign-off, compute a SHA-256 hash of each approved email’s exact HTML. The hash is a fingerprint of the bytes. Change one character anywhere, even inside an invisible attribute, and the fingerprint changes completely. Record the fingerprints with the approval and you’ve turned “we approved it” into something checkable forever.

To verify later, hash the file you’re holding and compare. Same fingerprint, same bytes, same email. Different fingerprint: something changed after approval, and no amount of “it looks the same” overrides that.

What a real approval record needs

• The fingerprint (SHA-256) of every approved email in the round
• What was checked, and what was knowingly waived, at approval time
• Who requested and who approved, with timestamps
• A way for someone who wasn’t in the room to verify a file against it
• Revocation: if approval is withdrawn, the record must say so

How SendLint automates this

In SendLint, approval is earned, not clicked: a round can only be approved when it passes the client’s compliance policy (unresolved failures block, waivers are recorded). The approval then mints a certificate, with an id like SL-2026-XR7QM, that freezes the SHA-256 of every approved email, the check counts, the waivers, and who approved. Three things make it useful beyond the QA team:

• A public verify page. Anyone holding the certificate id can open it, paste the final HTML, and get a byte-for-byte verdict. The hashing runs in their browser; the file never uploads.
• A pre-send API gate. A send pipeline can hash the outgoing HTML and ask the API whether that exact file is on a standing certificate. Changed bytes, superseded approval, or a revoked round all come back as “don’t send” with the reason.
• Supersession, not deletion. A new approval replaces the old certificate and says so. History stays inspectable.

The pipeline gate in one request

Wire that into the last step before the send (Salesforce Marketing Cloud can do it with an SSJS activity; any CI system can do it with two lines) and “the wrong version went out” stops being a category of incident.