# Maximize deliverability for Supabase Auth emails

> Five steps to land Supabase authentication emails — verifications, magic links, password resets — in the inbox when sending through MailBlastr: custom domain, a dedicated subdomain, no tracking, link-scanner handling, and DMARC.

Authentication emails — email verifications, magic links, password resets — are some of the most time-sensitive mail you'll ever send: if they hit spam, users can't sign in. If you wire up [Supabase Auth](https://supabase.com/docs/guides/auth) to send through MailBlastr (from your own verified domain), the five steps below give those messages the best possible chance at the inbox.

## 1. Set up a custom domain on Supabase

By default Supabase generates a `supabase.co` domain for your project and uses it for the links inside your auth emails (verify email, reset password). Before going live, configure a **custom domain**. The point is to **align the domain in your `from` address with the domain in the links** — for something as sensitive as verification and magic links, telling the inbox provider that the message origin and the link destinations share a domain is a meaningful trust signal.

That changes your links from a generated host like:

```text
https://039357829384.supabase.co/auth/v1/{code}
```

to something on your own domain:

```text
https://auth.example.com/auth/v1/{code}
```

Supabase has a guide for [setting up a custom domain](https://supabase.com/docs/guides/platform/custom-domains).

## 2. Use a dedicated subdomain for auth

Send authentication mail from a **subdomain** (for example `auth.example.com`) rather than your root domain. This isolates the reputation of your auth sending from your root domain, and — just as importantly — it **signals your intent** to the inbox provider: mail from `auth.example.com` is clearly authentication mail, not marketing, so it's judged by the standards that apply to wanted, transactional messages.

> **Note:** If you'd rather not have a subdomain just for auth, use one subdomain for all your transactional mail (e.g. `notifications.example.com`). Either way, add the subdomain in MailBlastr and verify it — see [Add a domain](https://www.mailblastr.com/docs/add-a-domain) and [subdomain vs. root domain](https://www.mailblastr.com/docs/kb/subdomain-vs-root).

## 3. Disable link and open tracking

Open and click tracking are useful for marketing, but for transactional and auth mail they can **hurt deliverability**. Open tracking embeds a 1x1 pixel; click tracking rewrites your links to pass through a tracking host first. Both can look suspicious to inbox providers, and — critically — link rewriting is [known to corrupt single-use verification links](https://supabase.com/docs/guides/platform/going-into-prod), breaking sign-in for your users.

Turn tracking off for the sending domain you use for auth. See [Domain tracking](https://www.mailblastr.com/docs/domains/tracking).

> **Note:** Keeping auth mail tracking-free means the magic link the user clicks is the exact link you generated — no rewrite layer that can mangle a single-use token.

## 4. Prepare for link scanners

Some inbox providers and enterprise security systems run a `GET` request against every link in a message **before** the user ever sees it. Because Supabase Auth links are **single-use**, a scanner can silently consume the token and leave the user with a dead link.

To work around this, alter the email template so the magic link points to a **landing page you control** instead of the raw auth URL. That page shows a *Sign in* button; clicking it redirects to the real magic-link URL. The scanner's `GET` hits your harmless landing page, and the token is only spent when the human clicks.

## 5. Set up DMARC

Deliverability is built on trust, and authentication is its foundation. **DMARC** tells the inbox provider that you are who you say you are: it ties your SPF and DKIM results together and states what should happen if they fail. Publishing a DMARC record signals that you're a legitimate sender whose mail belongs in the inbox.

MailBlastr generates SPF and DKIM when you verify a domain; you publish the DMARC record yourself. Start at `p=none` to monitor, then tighten once your reports are clean. See the [DMARC setup guide](https://www.mailblastr.com/docs/domains/dmarc).

> **Note:** Send your Supabase auth mail through MailBlastr the same way as any other transactional message — via the SDK (`mb.emails.send(...)`) in Node.js, or `POST ${BASE}/emails` with your `mb_` API key from any other runtime. The five steps here are about the **domain** and **template** around that call, not the call itself.