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.
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.
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.
Make the change.
Result The window of inconsistency is now the short TTL rather than the long one.
Confirm from more than one network before raising the TTL again.
Result You are checking convergence rather than your own resolver's memory.
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#
- Query the record directly and specify which resolver you are asking. Two resolvers disagreeing is the normal state during a change, not a fault.
- Check the TTL on the answer you got back. It tells you how long ago the cache filled and how long it will hold.
- For a
TXTpolicy, read the value exactly as published — including any split into multiple strings — rather than as your provider's form displays it. - 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.