How To Test Email Links Before A Campaign Goes Live

A broken email link is more than an embarrassing landing-page error. It can waste an expensive send, misattribute campaign revenue, leave a subscriber unable to manage their preferences or create the impression that a legitimate message is unsafe. The awkward cases are rarely a simple typo in a button URL. They happen when a link passes a preview test but fails after click tracking, recipient-level personalisation, security scanning, consent controls or a redirect added by the mailbox provider.

The useful question is therefore not “does this URL open?” It is: does each recipient-facing link complete the intended journey, through the actual email delivery and tracking path, without causing an unwanted action?

That requires a test send, rather than relying solely on a browser preview or an email-platform link checker. The final message a subscriber receives may contain rewritten tracking URLs; Microsoft 365 security policies, for example, can wrap and scan links at the time of click. Microsoft’s Safe Links documentation explains that URLs may be rewritten and checked again when the user clicks them. Test the route that people will actually use.

Start with a link inventory, not a visual scan

Before sending a proof, make a simple inventory of every distinct link and its intended purpose. This avoids the common mistake of checking the hero button while missing a text link inside a conditional content block, a linked logo, an image map, a social icon, a legal footer or the plain-text version.

Give each item an owner and an expected final destination. That sounds administrative, but it makes approval meaningful. “All links checked” is vague; “the footer preferences link resolves to the UK preference centre for a UK test profile” can be verified.

Build the inventory from the final assembled HTML and plain-text content, rather than from a copy document. Templates often contain fallback links, duplicated modules and conditionals that are invisible in one preview. If the platform rewrites links only at send time, also capture the received message source so that you can compare the authored URL with the click-tracked URL.

Test the full redirect path

A marketing link commonly travels through more than one service: email client, tracking domain, redirect service, consent or localisation layer, web analytics, then the destination. Any hop can fail. A landing page returning 200 OK does not prove the email link is sound if the tracking hostname has an expired certificate, the redirect drops a parameter or a geo-routing rule sends the subscriber elsewhere.

For each web link, record:

• the URL in the received email, including the tracking wrapper where present;
• the first HTTP response and every redirect;
• the final URL, page title and visible offer;
• whether HTTPS remains in use throughout;
• the response code, load behaviour and any error or login state;
• the campaign parameters as they arrive at the analytics or landing-page layer.

A short, purposeful redirect is normal. Long chains add delay and create more places for parameters to be lost. Google’s technical guidance on redirects advises sending users directly to the final destination where possible and keeping redirect chains low; it notes that not every user agent supports long chains equally well. Google’s redirect guidance is written for site moves, but the operational lesson applies neatly to email tracking too.

Check the final destination, not merely the final status code. A valid response can still show an out-of-stock product, an incorrect country, a generic home page, a cookie wall that obscures the offer, an app-download interstitial or an error message rendered inside an otherwise successful page.

Keep automated checks safe

Automated URL checking is useful for ordinary campaign links, but it needs guardrails. Do not blindly follow URLs that create accounts, confirm an order, reset a password, redeem credit, alter a booking or unsubscribe a real person. Use dedicated test accounts and test data, and label high-risk links in the inventory so they receive a controlled manual check.

Also treat unsubscribe endpoints with care. Security products and mailbox systems can request URLs as part of inspection. The one-click unsubscribe standard exists in part because mail software may fetch header URLs; it uses a separate user-consented POST mechanism to distinguish an actual one-click request from an ordinary retrieval. RFC 8058 sets out that design. A test harness that simply visits every URL should not accidentally remove a subscriber from a list.

Send proofs through the same infrastructure as the campaign

A platform preview is useful for content review, but it cannot prove the final tracking, authentication headers or mailbox-provider treatment. Send proofs through the same sending domain, click-tracking domain, template assembly process and routing configuration intended for the live campaign. If production sending is deliberately separated from test traffic, use a controlled pre-production route that still reproduces link rewriting and recipient substitution.

Deliver the proof to seed accounts at the mailbox providers that matter most to your audience. At a minimum, open the message in a webmail interface and on a mobile device. If a meaningful portion of your list uses Microsoft 365, test there as well as in Outlook, because organisational Safe Links policies can affect what the recipient clicks. A link that works in an isolated browser can behave differently once Microsoft’s security layer wraps it.

Use a clean browser session for at least one test. Existing cookies, a logged-in administrator account or a previously accepted consent choice can conceal problems that a normal recipient will see. Then repeat key journeys while signed in, where the campaign genuinely expects a customer session. The two experiences answer different questions.

Test personalisation and query parameters as data, not just text

Personalised links fail when a merge field is blank, encoded twice, truncated or inserted into the wrong part of a URL. They also fail when the recipient data contains characters that happen to have a special meaning in a URL, such as an ampersand, plus sign, hash or percent symbol.

URI syntax reserves characters including ?, &, =, # and % for structural use. Data that would conflict with that structure must be percent-encoded. RFC 3986 also warns against encoding or decoding the same string more than once, which is a frequent cause of corrupted tracking and signed links.

Create a small but deliberate test matrix. It should include a normal record, a record with a blank optional field, a record with spaces and punctuation, a record with non-ASCII characters, and each audience or locale that changes the destination. For account links, include a user who is logged in and one who is not. For product links, include a product that is in stock and any relevant edge case such as a discontinued SKU or a market where the item is unavailable.

Do not hand-concatenate recipient data into URLs if the sending or web platform offers a proper URL-parameter builder. The distinction matters: a plus sign can be interpreted as a space in form-style query parsing, and feeding already encoded data into an encoder can turn a valid percent sign into %25. MDN’s URLSearchParams reference gives practical examples of these encoding behaviours.

Verify attribution without contaminating reporting

Check that the intended campaign, medium and content parameters reach the landing page and are captured by the analytics implementation. Use an unmistakable internal test campaign value, such as utm_campaign=spring_launch_proof, rather than the live value. This makes test clicks easy to filter from reporting and helps identify whether a parameter disappeared at the email platform, tracker, redirect service or website.

Be careful with personal data in query strings. A customer’s email address, account number or other sensitive identifier can leak into browser history, logs, analytics systems and referrer data. Prefer a short-lived, opaque token where recipient-specific recognition is needed, and confirm that an invalid or expired token fails safely rather than exposing another person’s information.

Check the links that protect subscriber choice

The preference and unsubscribe route deserves a separate, documented test. It is both a subscriber-experience issue and a delivery-reputation issue. A visible unsubscribe link should be easy to find in the rendered message and should lead to the list or preference option promised by the copy. It should not require the person to remember a password just to stop marketing they no longer want.

For promotional and subscribed messages sent at bulk volumes to personal Gmail accounts, Google’s sender guidelines require one-click unsubscribe support as well as a clearly visible body link. Google specifies that one-click unsubscribe is implemented through the relevant List-Unsubscribe headers, rather than treating a body-link form as a substitute. Google’s sender guidelines and its implementation FAQ are the appropriate reference points for the current requirements.

Test these as two distinct mechanisms:

• The body link: click it in the rendered email, verify the correct preference or unsubscribe journey, and confirm the chosen preference takes effect for the test address.
• The message headers: inspect the raw received message for the List-Unsubscribe and List-Unsubscribe-Post headers, then make a controlled POST request for a dedicated test recipient where appropriate. Do not assume that a visible footer link proves header-level one-click functionality.

Where headers are signed by DKIM, validate the received message rather than only the platform configuration. RFC 8058 requires the relevant headers to be covered by a valid DKIM signature for its one-click mechanism. A header added, changed or omitted later in the pipeline may not behave as expected.

Look for security and trust problems in tracking redirects

Recipients are rightly cautious when a button labelled with your brand reveals an unfamiliar domain on hover. A dedicated, authenticated tracking subdomain can make the relationship clearer, but it must be technically sound: valid HTTPS, a recognisable hostname and predictable redirection to the brand’s destination.

Review any tracker that accepts a destination URL as a parameter. If it will redirect to arbitrary external addresses, it can become an open redirect. This is both a security concern and a phishing risk, because a seemingly trusted domain can be used to send people elsewhere. OWASP’s guidance on unvalidated redirects recommends validating destinations rather than redirecting to untrusted input. In practice, use an allowlist of approved destination hosts and reject malformed or unexpected targets.

Check that error handling is safe as well. If the offer has ended, the subscriber should see a clear replacement or explanation; they should not be silently redirected to an unrelated page. If a signed link is expired, show an understandable route to recover, such as signing in or requesting a new link, without exposing token details.

A sensible release decision

Before approving the campaign, confirm that every unique link in the final HTML and plain-text message has an owner, an expected outcome and a recorded result. Resolve critical failures before launch: broken primary CTAs, incorrect destinations, tracking failures, unsafe redirects, missing parameters and any unsubscribe or preference journey that does not work.

For larger programmes, retain the link inventory and proof results with the campaign record. Reusing a tested template does not eliminate the need to test again: new products, changed landing pages, expired redirects, altered tracking settings and a small edit to a merge field can all change the result. The scope can be lighter for a routine send, but it should still include the actual links and the actual sending path.

If recurring link faults sit alongside inbox-placement or reputation problems, link testing should form part of a wider sending review. Email Foundry’s deliverability audits can examine sending infrastructure and rendered-message behaviour alongside relevant authentication and provider-level signals. That is most useful when the symptom is broader than one incorrect URL and the team needs evidence about where the delivery or recipient journey is breaking down.

The goal is not an elaborate ceremony around every hyperlink. It is a repeatable way to establish that a subscriber can safely reach the promised destination, make the intended choice and leave the campaign path whenever they wish.