When an office server dies, the first questions are usually about files, printers, and the line-of-business app that only runs on that box. The quieter problem shows up a day or two later, when someone needs to change a DNS record, renew the domain, or prove who controls the mailbox that still receives vendor invoices. DNS and email do not live on the closet server the way a file share does, but the office often treated them as if they did. The result is a set of accounts, invoices, and MX records that nobody can name an owner for until something breaks.
Ownership here is not a philosophical question. It is a short list of logins, billing relationships, and edit rights. If those are split across a former IT person, a registrar invoice on a personal credit card, and a Microsoft 365 tenant nobody documented, the server retirement becomes a scavenger hunt. The hunt usually starts under time pressure, which is the wrong time to discover that the only person who knew the GoDaddy password left two years ago.
What "owns" actually means
Start by separating the pieces that get casually called "the domain." The registrar is who you pay to keep the name registered. The DNS host is where the zone lives and where A, CNAME, MX, TXT, and SPF records get edited. The email system is where mailboxes, aliases, and distribution lists live. Those three can be the same vendor, and they often are not. A common office pattern is a domain registered at one company, DNS hosted somewhere else (or still pointing at an old name server), and mail on Microsoft 365 or Google Workspace. The closet server may still be answering internal DNS for the LAN even while public DNS lives elsewhere.
For each piece, ownership means a named person who can log in, a billing method the business controls, and a written recovery path if that person is unavailable. "IT knows" is not ownership. "It is on the shared password sheet" is not ownership if the sheet is a spreadsheet on the server you are about to turn off. Ownership is a name, an email address that is not going away with the migration, and a second person who can get in if the first is on vacation during cutover week.
Email ownership is especially easy to misread. Controlling the Microsoft 365 or Google Workspace admin console is not the same as controlling the DNS records that make mail deliver. SPF, DKIM, and DMARC live in DNS. If you can add a user but cannot edit TXT records, you do not fully own mail delivery. If you can edit DNS but cannot reset the tenant admin, you do not fully own the mailboxes. Offices that migrate off a local Exchange box sometimes move mailboxes to the cloud and leave the old server's IP in SPF for months. Outbound mail keeps working until a provider tightens checks, and then the office learns that nobody knows who can edit the zone.
How the closet server got tangled in
The office server rarely "owns" public DNS in a clean sense. What it often owns is habit. Someone set the firewall or DHCP to hand out the server as the internal DNS resolver. Someone pointed a few public records at the server's public IP for VPN, remote desktop, or an old webmail hostname. Someone ran a SMTP relay or a scan-to-email path that authenticated against a local account. Those ties survive in configs long after the people who built them have moved on.
When the server dies or gets decommissioned, those ties surface as failures that look like email or "the internet" rather than like a retired box. A printer that scanned to email through the server stops. An SPF record that still authorizes the old public IP starts failing soft, then hard. An internal hostname that staff typed for years stops resolving because it only ever lived in the server's DNS zone. None of these are mysteries once you map them. They feel mysterious on a Monday morning when the only person with registrar access is unreachable.
The fix before retirement is a written map, not a verbal assurance. List the registrar login and where the renewal invoice goes. List the DNS host and who can edit records. List every public hostname that still points at the office IP, and decide whether each one gets retired, moved, or rewritten. List the mail platform admin accounts, including break-glass accounts that are not tied to a single employee. List the SPF, DKIM, and DMARC records as they stand today, and who will update them when the last on-prem relay goes away. Put that map somewhere that does not depend on the server you are retiring.
Assign owners before cutover day
Treat DNS and email as their own cutover workstream with two named owners: a primary and a backup. The primary does not have to be technical. They have to be able to reach the technical person and approve changes. The backup exists because cutovers happen when people are sick, traveling, or already buried in file-share tickets. Put both names in the migration plan next to the registrar, DNS host, and mail tenant, with the exact URLs for the consoles and the billing contacts.
Do the access test before you need it. Log into the registrar and confirm you can unlock the domain and change name servers. Log into the DNS host and make a harmless TXT record, then remove it. Confirm you can add a DKIM record if the mail vendor asks for one during the migration window. Confirm that domain renewal is on a company card or a company account, not a personal card that will decline after someone leaves. If any of those tests fail, stop treating the domain as "handled" and fix access as a prerequisite, not as a follow-up task.
When the closet server finally goes dark, public DNS and cloud mail should already be independent of it. That means no remaining MX or SPF dependency on the old IP, no staff workflow that still resolves only through the local DNS zone, and no invoice that only arrives in a mailbox nobody monitors. If something still depends on the server after the power cord is pulled, that dependency was never really owned. It was only tolerated.
Offices that get this right barely notice DNS and email on cutover day, which is the point. The work happened earlier, on a quiet afternoon, when someone sat down and wrote down who pays for the name, who edits the zone, and who can reset the mail admin. That short document outlasts the server. It is also the document you will wish you had written the first time a renewal fails and the only recovery email still points at an address on a box that no longer exists.