Deep links in email

Overview

Universal Links and App Links are matched against the URL the user actually tapped. Email introduces two things that change that URL, or bypass the match entirely — and neither of them is visible when you test by sending yourself a link in Messages.

If your links open your app everywhere except in email, one of the two below is almost certainly the reason.

Breakage 1: click-tracking rewrites

Most email providers — SendGrid, Mailgun, Postmark, Customer.io, Resend and others — replace every link in your message with a tracking URL on their own domain so they can count the click before redirecting.

What you put in the template:
  https://acme.linksense.net/reset?token=abc123
 
What the recipient actually taps:
  https://click.your-esp.com/ls/click?upn=Xh9...
 
The tapped domain is click.your-esp.com. That host is in no
app-site-association file your app trusts, so iOS has no app
to open — it opens a browser, which then follows the 302.

The redirect that follows does not rescue it. Universal Links do not fire on a server-side redirect: iOS evaluates the association for the URL that was tapped, and by the time your real link is reached the navigation is already happening in a browser. Android App Links behave the same way, though some browsers are more forgiving.

Breakage 2: email-client webviews

Gmail, Outlook and most mobile mail clients open links in an in-app webview rather than handing them to the system. Universal Links do not fire inside a webview, even with a clean, untracked URL and a correctly configured association file.

There is no configuration that changes this — it is how those clients work. Today an affected visitor reaches your link in the webview and is routed onward like any other web visitor, which for a user who already has your app means being offered the app store. Fixing breakage 1 is what keeps this case rare; the native mail clients on iOS and Android do hand links to the system.

Fix A: turn off click tracking

The simplest fix, and the right one for transactional mail. Every major provider supports disabling click tracking per message, per template, or per sending stream — so you can keep it on for marketing campaigns and off for password resets.

// SendGrid — disable click tracking for one message
{
  "personalizations": [{ "to": [{ "email": "user@example.com" }] }],
  "tracking_settings": {
    "click_tracking": { "enable": false, "enable_text": false }
  }
}

// Resend — click tracking is off by default; make sure it stays
// off for transactional templates in Domains -> Tracking.
 
// Postmark — use a Message Stream with link tracking disabled:
{
  "MessageStream": "outbound",
  "TrackLinks": "None"
}

You lose the provider's click count for those messages. LinkSense still records the clicks it sees — which is every click from a recipient who does not have your app installed.

Fix B: use your own tracking domain

If you need click tracking, point your provider at a tracking domain you control — for example links.acme.com — and add that host to your app's associated domains so the operating system trusts it. The tapped URL is then on a domain your app claims, and the Universal Link fires before the redirect matters.

This requires configuring the custom tracking domain with your email provider and serving an app-site-association file from it. It is more setup than Fix A, and worth it only if the provider's click data is something you actually use.

Per-provider settings

Testing it

Send yourself a real message through your real provider — not a copy-pasted link. Open it on a device with your app installed, then long-press the link and read the URL before tapping. If the host is not your LinkSense subdomain or your own tracking domain, click tracking is still rewriting it.