Custom Domains for Short Links: DNS, TLS and SPF

A short link like go.yourbrand.com/ab3x7 is more than cosmetics. It builds trust — people are far more likely to click a recognizable branded link than a random string from an unfamiliar domain. It also improves click-through on trust-sensitive channels like email and SMS.

But putting short links on your own domain means getting the DNS, TLS, and SPF right — especially the last one, because the subdomain you choose can silently break your email if you're not careful. This guide walks through all three.

Why a branded short domain matters

Recognition is trust. A branded short link tells the recipient "this came from yourbrand" before they click. That:

• Raises click-through — people are more comfortable clicking a known brand.
• Reduces spam-filter suspicion — some filters are wary of unknown short domains.
• Strengthens your brand — every link reinforces it.

The cost is the setup work in this guide — which is why many shortener platforms offer custom domains as a paid feature.

DNS: point the subdomain at your shortener

The first step is choosing a subdomain and pointing it at the short-link service. Common choices: go.yourbrand.com, link.yourbrand.com, lnk.yourbrand.com.

Two ways to point it:

• CNAME — point go at the shortener's provided hostname (e.g. links.yourbrandshortener.com). Good if the platform manages the IP.
• A record — point go at the platform's IP directly. Good if you want control or need a root domain.

The exact record is usually provided by your short-link platform. Verify the record propagates with a DNS lookup (/tools/dns-lookup) before relying on it.

TLS: HTTPS is non-negotiable

Short links should always be served over HTTPS. A link that shows "not secure" defeats the trust purpose and hurts click-through.

• The shortener platform usually provisions a TLS certificate for your custom domain automatically.
• You should also confirm the destination (your real site) is HTTPS, and that your links use https.

A short domain served over plain HTTP is a red flag to users and filters.

SPF: the part that breaks email

Here's the trap. If the same domain is used for both email and short links, you can accidentally break SPF.

SPF says "these servers may send email for this domain." When you use a subdomain like go.yourbrand.com for short links, and a separate yourbrand.com or mail.yourbrand.com for email, there's usually no conflict — the subdomain go. isn't involved in SPF for yourbrand.com unless you include it.

But if you use a subdomain that is in your SPF (or if you add the short-link service to your SPF for a domain you also send mail from), you can:

• Add too many include lookups (the 10-limit again — see SPF mistakes).
• Accidentally allow the shortener to be an authorized sender, or create ambiguity.

The safe pattern:

1. Use a dedicated subdomain (go.yourbrand.com) that is only for links.
2. Don't send email from that subdomain. Keep your mail on yourbrand.com or mail.yourbrand.com with their own SPF/DKIM/DMARC.
3. Don't add the shortener to your mail domain's SPF unless it actually sends email for you. Short links don't send email; they just redirect.

If the shortener does send transactional email (e.g. click notifications) from the domain, then include its sender in SPF — but keep that separate from the link-only subdomain.

DMARC and DKIM

If you're hardening your mail (see DMARC migration), keep your link subdomain out of the mail authentication path. A link-only subdomain doesn't need DKIM or SPF, and adding them creates no benefit — and risks the lookup-limit or alignment issues described above.

A practical setup

1. Choose go.yourbrand.com (dedicated, not used for mail).
2. Add the CNAME or A record the shortener provides.
3. Confirm HTTPS is provisioned.
4. Verify with /tools/dns-lookup and a link test.
5. Confirm your email domain (yourbrand.com) has its own healthy SPF/DKIM/DMARC, and that the link subdomain isn't interfering.

The takeaway

A branded short domain is worth it for trust and click-through — just set it up deliberately. Point a dedicated subdomain at your shortener with the right DNS, make sure it's HTTPS, and keep it separate from your email domain so SPF, DKIM, and DMARC stay clean. Do that and your branded links build trust without breaking your mail.

To learn more, see the custom domains setup guide and how to choose short codes.

How a custom domain changes the technical setup

Putting your short links on a domain you own changes several technical dimensions compared to a shared default domain. The DNS must be configured — a CNAME (or A as a fallback) pointing the chosen subdomain at the platform, with the TTL managed so propagation is fast. TLS must be provisioned for the custom domain so every branded link serves over HTTPS. And because the domain is now used for links that may appear in email, its mail-related posture (SPF/DMARC, and whether it sends mail) should be coherent so the domain's reputation stays clean. These are the technical requirements that the custom domains setup walks through in detail; this guide focuses on the short-link-specific implications.

The trust and deliverability payoff

The reason teams invest in a custom domain is twofold: trust and deliverability. A link on a domain the recipient recognizes earns more clicks than a link on an unknown or shared domain, because the brand name pre-loads trust — the same mechanism as branded links. And in email, a link on a domain with a clean, brand-owned reputation is scored more favorably than one on a shared domain that other senders may have abused, which protects your deliverability. Both benefits flow from owning the domain and controlling its reputation.

Operational responsibility that comes with it

A custom link domain is yours to keep healthy. That means monitoring DNS records so they do not drift, keeping the TLS certificate valid, watching that the domain is not unexpectedly hijacked or flagged, and verifying propagation before any launch that depends on it. It also means handling the transition correctly when you move from a default domain to a branded one — keeping old links working with a 301 so nothing already published breaks. This ongoing responsibility is the trade for the trust and control a custom domain provides, and it is the same "you own the asset, you maintain it" principle as the TLS health checklist.