Domain, DNS, and the Three Records That Break Everything

Ask a room of business owners who controls their domain and you'll get a lot of uncertain answers. "The developer from before, maybe?" "It might be through the hosting?" "There's an email from GoDaddy somewhere."

That uncertainty is the single largest unmanaged risk on most small business websites — bigger than the plugin vulnerabilities everyone worries about.

Own your domain, personally

Not your agency. Not your web developer. Not an employee's personal account.

The registrar account should be in the business's name, with the business's email, and someone in the business should be able to log in today. Everything else — hosting, DNS, email — can be moved if you control the domain. Lose control of the domain and you lose all of it at once, with no technical recourse.

Check three things this week: who the registrar is, whether renewal is on auto-renew with a card that hasn't expired, and whether the contact email is one somebody still reads.

The three records

A / AAAA — where your website lives. Point it at the wrong address and the site is gone. Point it at an address you no longer control and someone else's content can appear on your domain. When you leave a host, this is the record to change, and the old host account should not be cancelled until the change has fully propagated.

MX — where your email goes. The classic disaster: a developer migrates the website, recreates DNS from scratch at the new provider, copies the web records and forgets the mail records. The site works perfectly. Email stops, silently, and it can be a day before anyone realizes inbound mail has been bouncing.

Before any DNS migration, export every existing record. All of them. Then compare afterwards.

TXT — who is allowed to send as you. SPF, DKIM, and DMARC decide whether your mail lands in an inbox or a spam folder. They also decide whether someone else can send convincing mail pretending to be you.

If your contact form emails stopped arriving after a host migration, this is nearly always why: the new server sends mail that your SPF record doesn't authorize.

The habits that prevent the bad day

• Lower TTL before a planned change, so a mistake takes minutes to undo instead of a day.
• Export the whole zone before touching anything. A text file, saved somewhere findable.
• Change one thing at a time and confirm it before the next.
• Never let the domain and the hosting be a single account you can be locked out of.
• Document it. Registrar, DNS host, who has access, and where recovery codes live. One page, kept somewhere the business owns.

Why this is worth an afternoon

Hacking is the risk everyone plans for. In practice, we see far more total outages caused by an expired domain, a lapsed card, an inaccessible registrar account after someone left the company, or a migration that dropped the MX records.

Every one of those is preventable with an hour of documentation and an auto-renewal you've verified.