DNS Setup

RouteSeam needs exactly one DNS record per domain. Which record depends on whether your hostname is an apex domain or a subdomain. The dashboard always shows you the correct record for the hostname you added — this page explains what you’re creating and why.

Apex domains: A record

An apex domain (also called a root or naked domain) is a domain with nothing in front of it: oldcompany.com.

For an apex domain, create an A record pointing at the RouteSeam edge IP shown in your dashboard. The product refers to this address as ROUTESEAM_IP:

Type	Name	Value
A	@	ROUTESEAM_IP (shown in the dashboard)

Most DNS providers use @ as the name for the apex. Some show it as the bare domain or an empty field — use whatever your provider’s convention for “the apex itself” is.

Subdomains: CNAME

A subdomain has a label in front of the apex: legacy.company.com, old.example.org.

For a subdomain, create a CNAME record pointing at the RouteSeam edge hostname shown in your dashboard:

Type	Name	Value
CNAME	legacy	the RouteSeam edge hostname shown in the dashboard

Enter just the subdomain label (legacy) in the name field — most providers append the apex automatically.

Why you can’t CNAME the apex

The DNS specification forbids a CNAME at the apex. An apex domain must also carry other records (SOA, NS, and usually MX for email), and a CNAME is not allowed to coexist with any other record at the same name. Most DNS providers enforce this and simply won’t let you save a CNAME for @.

That’s why apex domains use an A record pointing directly at the RouteSeam edge IP instead.

Caution

Don’t point your apex A record at an IP you found somewhere else or copy from another domain’s setup. Always use the exact value shown in your RouteSeam dashboard for that domain.

ALIAS, ANAME, and CNAME flattening

Some DNS providers offer non-standard record types that behave like a CNAME at the apex — variously called ALIAS, ANAME, or CNAME flattening. If your provider supports one of these, you can use it to point your apex at the RouteSeam edge hostname instead of the IP.

Both approaches work with RouteSeam. The plain A record to ROUTESEAM_IP is the default and works everywhere; an ALIAS/ANAME record is an acceptable alternative if your provider offers it.

TTL and propagation

TTL (time to live) controls how long resolvers cache your record before checking again. Practical guidance:

• When you first add the record, a shorter TTL (300–600 seconds, if your provider lets you choose) means RouteSeam’s Check DNS sees the change sooner.
• If the record you need to change or remove an existing record, the old value can linger in caches for up to the old TTL, even after you’ve updated it. This is the most common reason a DNS check fails right after a change.
• Full propagation is usually minutes, but providers quote up to 24–48 hours in the worst case.

RouteSeam checks your DNS automatically every few minutes in addition to the manual Check DNS button, so a record that propagates while you’re away is picked up without you doing anything.

Verify it yourself

You can confirm what the world sees with dig:

# Apex domain — expect the RouteSeam edge IP
dig +short A oldcompany.com

# Subdomain — expect the RouteSeam edge hostname
dig +short CNAME legacy.company.com

If the output matches the record RouteSeam showed you but Check DNS still fails, wait a few minutes and retry — the authoritative answer and the resolver RouteSeam queries can briefly disagree.

What happens after DNS verifies

Once the record resolves correctly, the domain moves to DNS Verified, RouteSeam provisions a Let’s Encrypt certificate automatically, and the domain becomes Active. Certificate issuance requires your DNS to be correct — a hostname that doesn’t resolve to RouteSeam can’t get a certificate.

If you’re stuck, see DNS & TLS troubleshooting, or read about the full domain lifecycle.