# DNS

DNS turns names into answers — addresses, mail destinations and text records that other systems read as policy. For a business running mail and telephony the records that matter are `MX`, several `TXT` records, and a handful of `CNAME` delegations. The number that catches people out is the TTL, because it decides how long a mistake lasts.

- **Status:** Reference
- **Audience:** both, developer
- **Channels:** email
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/technology/dns/

## The records a communications setup rests on

| Type | Answers | Where it bites |
|---|---|---|
| `MX` | Which servers accept mail for this domain, in priority order | Change it and mail moves. There is no partial state — the world converges as caches expire |
| `TXT` | Free text that other systems read as policy: SPF, DMARC, domain verification | A string is limited to 255 characters; longer values are split and rejoined, and a split in the wrong place breaks the policy |
| `CNAME` | This name is an alias for that one, often used to delegate a signing selector or a tracking host to a provider | Cannot exist at the zone apex alongside other records, which is why a bare domain cannot be a `CNAME` |
| `A` / `AAAA` | The address of a host | Straightforward, and rarely the cause of a mail problem despite being the first thing people check |
| `SRV` | Which host and port provide a named service, used by some SIP deployments | Optional in many telephony setups; the carrier states whether it wants one |
| `NS` | Which servers are authoritative for the zone | Delegating a subdomain to a provider hands them the whole subtree |

DKIM is the one that surprises people: the public key lives in a `TXT` record under a selector name, and mail providers commonly hand you a `CNAME` pointing at their own record so they can rotate the key without asking you again. Both shapes are normal.

## TTL is a commitment, not a preference

A record's time-to-live tells every resolver how long it may keep the answer. Once handed out, that answer is beyond your reach — there is no mechanism to recall it. A record with a day-long TTL that you change this morning is still being served, correctly, until tomorrow.

“Propagation” is a misleading word for this. Nothing is being pushed anywhere; caches are simply expiring at different moments, which is why a change appears to reach some people and not others.

1. Lower the TTL on the records you are about to change, and wait for at least the old TTL to pass.
   - Result: Every cache now holds a short-lived copy, so the real change will converge quickly.
2. Make the change.
   - Result: The window of inconsistency is now the short TTL rather than the long one.
3. Confirm from more than one network before raising the TTL again.
   - Result: You are checking convergence rather than your own resolver's memory.

> **Careful** Negative answers are cached too. Publishing a record with a typo, then fixing it, can leave “this name does not exist” cached for the zone's negative-caching interval — which is a different number from the record's own TTL and is often longer than people expect.

## Does Connect use DNS?

Connect publishes no DNS record on anybody's behalf and asks for no control of a customer's zone. It sends through the mailbox a workspace already owns — Gmail, Microsoft Graph or an IMAP/SMTP server — so the authentication records for that domain are the ones its mail provider already required, and they keep working unchanged.

**What Connect needs from your DNS** — Nothing new for mail. Connecting a mailbox is an authorisation step with the provider, not a zone change
**What your mail provider needs** — SPF, DKIM and a DMARC policy, as it did before Connect existed
**What a carrier or messaging provider may need** — Whatever that provider documents. Those requirements belong to it, not to Connect
**What Connect resolves at runtime** — The hostnames of the providers a workspace configured, like any client

The practical consequence is that a DNS problem in a workspace's domain shows up as a delivery or connection problem inside Connect but is not fixed inside Connect. The Phone screen's readiness and a mailbox's health verdicts are where the symptom appears; the zone is where the cause lives.

## Diagnosing in the right order

1. Query the record directly and specify which resolver you are asking. Two resolvers disagreeing is the normal state during a change, not a fault.
2. Check the TTL on the answer you got back. It tells you how long ago the cache filled and how long it will hold.
3. For a `TXT` policy, read the value exactly as published — including any split into multiple strings — rather than as your provider's form displays it.
4. Only then look at the mail path. A large share of “mail stopped” incidents are a record edited an hour earlier by somebody who no longer connects the two events.

## Questions

### Do I need to add DNS records to use Connect?

No. Connect works through a mailbox you already own and authorise, so your existing mail authentication stays exactly as it is. If your provider asked you for SPF, DKIM and DMARC records before, those remain the records that matter, and Connect adds none of its own.

### I changed a record and nothing happened. How long should I wait?

At least the previous TTL on that record, counted from the moment of the change, and longer if a resolver in between imposes its own minimum. If you did not lower the TTL beforehand, the wait is however long the old value said — there is no way to shorten it after the fact.

### Why can my bare domain not be a CNAME?

Because the apex of a zone has to carry `NS` and `SOA` records, and a `CNAME` may not coexist with other records at the same name. Providers work around it with their own record types or with an address record they keep updated; the restriction itself is in the protocol, not in your provider.

## Related

- [SPF](https://connectbyjbrh.com/docs/technology/spf/)
- [DKIM](https://connectbyjbrh.com/docs/technology/dkim/)
- [DMARC](https://connectbyjbrh.com/docs/technology/dmarc/)
- [Email deliverability](https://connectbyjbrh.com/docs/technology/deliverability/)
- [SMTP](https://connectbyjbrh.com/docs/technology/smtp/)

## What this page is based on

- https://www.rfc-editor.org/rfc/rfc1035 — Domain names, implementation and specification
- https://www.rfc-editor.org/rfc/rfc2308 — negative caching of DNS queries
- `docs-source/sources/CHANNELS.md` §1 — mailbox providers and health