QA the announcement email like a release
Release notes, product announcements and onboarding updates are usually written by product people, not email specialists — and they are dense with docs deep-links that move and app links that must never be machine-clicked. SendProofs checks the delivered test file and refuses to open anything it recognizes as a sign-in.
The moment this matters
The feature shipped. Now the announcement goes to the whole user base — often the largest audience the company ever emails at once. The message was drafted days earlier, by a PMM or a founder squeezing it between launch tasks, and it deep-links into the docs: a setup guide, a migration note, the changelog entry. Docs sites restructure constantly; the URL that worked when the notes were drafted can be a 404 by send morning.
The usual QA is somebody clicking through a test send in a signed-in browser during the last hour. That routine has two flaws: it leaves no record, and a signed-in session hides problems a recipient would hit. It also cannot be delegated to a naive link-clicking script, because announcement emails carry exactly the links a machine must not touch — sign-in, verification, account actions.
Who owns the decision
The PMM pressing send — or, at an earlier stage, the founder doing the PMM's job for the afternoon. Engineering owns the docs site, marketing owns the message, and the dead deep-link lives in the gap between the two. Whoever approves the send answers for it, and that person is rarely a full-time email operator with a hardened checklist. What they need is evidence they can read in two minutes and hand to the docs owner without translation.
The release-announcement workflow
-
Send the real test
After the final copy and link edits, trigger a test send of the announcement from your email platform to your own inbox.
-
Save the delivered file
Download the message as a .eml file — the workflow works with an email saved from Gmail, Outlook or Apple Mail. The delivered file carries the rewritten, tracked links your users will actually receive, not the draft's originals.
-
Upload it
SendProofs extracts every unique link and image and classifies each URL before any request is made: links recognized as sign-in, verification or account-action destinations are marked Protected and never requested.
-
Read the evidence like a build log
Each checked destination gets a recorded status, redirect chain and timing. A docs deep-link that returns 404 reads like a failing test: specific, reproducible, assignable. How redirect evidence is recorded.
-
Fix, resend, recheck — then review Protected links by hand
Repoint the moved docs URL in your platform, send a fresh test and upload it again. As the last manual step, open the Protected app links yourself in a signed-out window. Reviewing sensitive links safely.
The evidence handoff
The report turns "I think the docs link is broken?" into a handoff the docs owner can act on directly: the final URL, the HTTP status, the hops through the click-tracking domain and the timestamp of the check. Engineers respond to that the way they respond to a failing check on a pull request, because it is shaped like one.
The Protected list is the handoff in the other direction — from the machine back to you. Sign-in and account links appear in the report marked "Not opened", so the pre-send review covers them deliberately instead of assuming somebody clicked them. How protected actions work.
Sample scenario: a changelog test after a docs migration
| Resource | State | Evidence |
|---|---|---|
| campaign.example/docs/setup/notifications | Broken | 404 at final destination — deep-link lost in a docs restructure; repoint, then recheck |
| campaign.example/changelog/2026-08?utm_source=email&utm_campaign=aug-notes | Healthy | 200 after 2 redirects · 287 ms |
| app.campaign.example/login?next=%5BREDACTED%5D | Protected | Not opened — review manually |
Sample data. The "Open dashboard" button pointed at a sign-in URL, so the link was classified Protected at upload and never requested; the likely tracking pixel among the images got the same treatment. Full sample run: 12 unique resources — 9 Healthy, 1 Broken, 2 Protected; 10 checks consumed; outcome Failed until the docs deep-link was repointed and a fresh test rechecked.
Limitations and non-goals
- SendProofs never opens links it recognizes as sign-in, verification or account actions — which also means it cannot tell you what is behind them. Dashboard, billing and settings destinations stay yours to review by hand.
- Recognition is pattern-based on English keywords in URLs and link text. It catches the common shapes, but treat the Protected list as an assist to your review, not a replacement for it.
- No rendering QA — how the announcement looks in any email client is not checked, and no screenshots are produced.
- No prediction of whether the message reaches recipients or which folder it lands in — destinations, redirects and tracking are the whole scope.
- The workflow is file-based: save the delivered test and upload it. Nothing connects to your sending platform, and nothing is ever sent on your behalf.
- A Healthy docs link is evidence that the public destination answered at check time — not proof the page's content matches the release.
Put the next announcement through a check
Free workspace — 100 resource checks each month, no card at signup.