What “changes hands” means here
Picture a small company where the office manager renews the domain one year, a contractor updates DNS the next, and a new hire gets an email seat from whoever still has the registrar password. Six months later, nobody can say who approved the last owner-email change, which ticket covered the seat that was added for a temporary bookkeeper, or how to roll the change back if it was wrong. The domain still resolves. The mailbox still works. The paper trail does not.
That scene is an illustration, not a TwoQM client. This article is an ops log for when registrar ownership, DNS, hosting-panel admin roles, or email mailbox seats change hands. It is not a website login inventory (what accounts exist) and not staff offboarding alone (who to remove when someone leaves). MFA for hosting, domain, and email admin, and domain auto-renew and lock, are DIFFERENT angles too—how you authenticate, and renewal/lock settings. This one asks: when access or ownership moves, what do you write down?
Treat each of these as a logged event, even when the same person keeps doing the work:
Registrar / domain ownership: owner contact email, account holder, or transfer between registrars.
DNS control: who can edit records, or a move of the zone to a new DNS host.
Hosting panel: admin users added, removed, or role-changed in the control panel.
Email seats and mailboxes: seats added or removed, mailbox ownership reassigned, aliases pointed at a new person, or admin role on the mail tenant changed.
Humans perform the registrar, DNS, hosting, and mail actions. Software records who asked, who approved, what changed, when, and how to undo it.
Fields every change-log entry should carry
Keep the form short enough that people will fill it in:
Requested by: name and role.
Approved by: a different named person when your policy requires dual control; otherwise the owner you designate.
System: registrar, DNS host, hosting panel, or email tenant—use the names on your written list, not slang.
What changed: owner email, seat added/removed, admin role granted/revoked, mailbox reassigned, DNS host moved—copy the exact values before and after when you can.
When: date and time the change was completed (not only when it was requested).
Ticket or reference: internal ticket ID, registrar order number, or provider confirmation.
Rollback note: one sentence on how to reverse the change, or “no rollback; document only,” with who said so.
Append-only lines beat overwritten cells. If someone corrects a mistake, add a new line that points at the earlier entry.
An original walk-through (not a measured result)
Here is an original example, not a measured result. A Valley retailer adds one email seat for a seasonal hire and later moves the domain’s owner contact to the operations lead:
Operations requests the seat; the owner approves in writing on the same day.
The person with hosting and mail access creates the seat, copies the provider confirmation into the log, and notes the mailbox address and the person it is assigned to.
Weeks later, the owner contact on the registrar changes. A second log line records the old and new owner emails, who approved, and the registrar confirmation number.
When the seasonal hire leaves, offboarding removes the seat—and a third log line ties that removal to the earlier add, so the trail stays connected.
The login inventory still lists which panels exist. MFA still covers how admins sign in. Offboarding still covers the leave checklist. The change log is the chronology of moves between those moments.
Roles and hard stops
Name who may request a change, who may approve it, and who may click the button at the registrar or host. Those three roles can be the same person in a tiny shop, but write that down so it is a decision, not an accident. Hosting, domains, and managed hosting work only stays coherent when the people who hold those panels also leave a trail.
Software never changes DNS, seats, or registrar settings on its own. It stores the request, reminds the approver, and keeps the audit lines. Business automation can notify the named approver when a request is waiting; it should not apply the change.
Where AI helps, and where it stops
AI can draft a change-log entry from a ticket note, suggest a rollback sentence for a person to edit, or prepare a short Spanish summary of open access-change requests for bilingual owners. It never submits registrar or DNS changes, never adds or removes email seats, never grants admin roles, and never marks a change complete without a named person confirming the provider action.
Where to start this week
List every place domain, DNS, hosting, or email access can move. For the next change—however small—fill the fields above before anyone leaves the panel. Keep the log where the people who hold the passwords can reach it, with access limited to the roles you named.
If you want that change log next to your hosting and domain setup, TwoQM can scope the fields, roles, and reminders around the panels you already use. Pricing explains how business apps, systems, and custom software are scoped. TwoQM builds tooling and can manage hosting with you; it does not silently rewrite your DNS or seats, and no log replaces careful human clicks at the registrar.