# Deep Links in Email

Your deep links can be configured perfectly and still open a browser, because something between you and the recipient changed the URL.

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 is visible when you test by sending yourself a link in Messages.

A custom domain does not fix this. The email provider rewrites the link to its own domain regardless, so the fix has to happen in your provider's settings, not in LinkSense.

## 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.

```text
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 redirect.

The redirect 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 then 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.

No configuration changes this — it is how those clients work. 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.

```json
{
  "personalizations": [{ "to": [{ "email": "user@example.com" }] }],
  "tracking_settings": {
    "click_tracking": { "enable": false, "enable_text": false }
  }
}
```

You lose the provider's click count for those messages. LinkSense still records the clicks it sees — 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 worth it only if the provider's click data is something you actually use.

## Per-provider settings

| Provider | Where to turn click tracking off | Custom tracking domain |
| --- | --- | --- |
| SendGrid | `tracking_settings.click_tracking` per send, or Settings → Tracking | Yes |
| Mailgun | `o:tracking-clicks: false` per send, or Domain settings | Yes |
| Postmark | `TrackLinks: "None"`, or per Message Stream | Yes |
| Customer.io | Per-campaign link tracking toggle | Yes |
| Resend | Off by default; Domains → Tracking | Yes |
| Amazon SES | No rewriting unless a configuration set enables it | Yes |

## 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.

Test in the native mail app first. Apple Mail and the Android system mail client hand links to the OS, so they show you whether the link itself is correct. If it works there but not in Gmail, you are looking at the webview case, not a configuration problem.

See also: [Deep Links for Transactional Email](/docs/transactional-email-deep-linking).