The website works, email works, so nobody asks about the domain. It was bought twelve years ago by the agency that built your first website, or by an IT person who left three years ago. Renewal reminders go to an address nobody reads, and payment is taken from a card that expires in six months.
This post lets you establish in one hour whether your company actually controls its domain. After reading it you can decide whether regaining access to the account is enough, or whether the domain should move to a registrar under a company account.
Three things you need to control
In practice a domain is three separate layers. Each can belong to someone different, and each can stop you.
- Registrant. The legal holder of the domain in the registry. For Polish .pl domains the registry is run by NASK, the national registry operator, and the registrant should be your company with its tax ID, not a private person and not an agency.
- Registrar account. The panel where you renew the domain, change DNS servers and retrieve the authinfo code needed to transfer it. What matters: login, password, MFA, notification address and payment card.
- DNS zone. The list of records that route traffic: MX for email, SPF and DKIM records, autodiscover for Microsoft 365, the website address, sometimes verification records for Google or invoicing systems. The zone may sit with the registrar, with your web host or in Cloudflare.
The most common mistake we see: the registrant is a web agency or a private person, and the registrar account was opened with their email. While the relationship is good, nothing happens. The problem surfaces in a dispute over an invoice, when you change website providers, or when an employee leaves.
How to check it in one hour
You need no vendor and no tool beyond a browser.
- Open the WHOIS lookup at dns.pl (for .pl domains) and enter your domain. You will see the registrar, the registration date and the date until which the billing period is paid.
- Find out who has a login to that registrar's panel. Log in yourself. Check the registrant data, the notification email, the payment method and whether renewal is automatic.
- Check where the DNS zone is hosted. The registrar panel shows the name servers (NS). If they point to your web host or Cloudflare, find out who has access to that account.
- Export or copy all zone records into one file. This is your backup for the day something has to be moved.
If step 2 shows that nobody in the company has a login, don't panic. The registrant is entitled to the authinfo code from the registrar. If the registrar does not hand it over, NASK accepts complaints and in exceptional cases provides the code itself (source: NASK, registrant rights). There is also a procedure in which NASK passes the code directly to a new registrar at the registrant's request (source: NASK, change of registrar). This only works if your company is the registrant.
You can check SPF, DKIM and DMARC records at the same time. If they are missing or nobody knows who set them up, we cover that separately in our post on SPF, DKIM and DMARC for business.
Two examples from our projects
Where it worked. A Polish accounting firm, 18 people, email in Microsoft 365. The .pl domain had been registered by the agency that built the website in 2015, and the agency was the registrant. The firm was changing website providers, so we used the occasion to move the domain to a registrar under the firm's own account. Scope: obtaining the authinfo code, changing registrar, changing registrant, copying the DNS zone 1:1 (22 records, including MX, autodiscover and DKIM for Microsoft 365), MFA on the account and two notification addresses.
The work took about 6 hours, roughly PLN 1,500–2,000 (about EUR 350–470), plus a domain fee at the new registrar of around PLN 100 (about EUR 25) a year. It took 2 calendar weeks because the agency did not reply about the code for 9 working days. Email did not stop for a single hour. What we would do differently: copy the DNS zone before the first email to the agency, not after, because for a week we did not know whether a record might disappear.
Where it went wrong. A building materials wholesaler, 35 people, running Comarch Optima (a Polish ERP) and Microsoft 365. A former IT person renewed the domain automatically from their company card. The card expired, reminders went to their old address, and the domain went into blocked status. For 3 working days email did not accept messages, and customers received delivery failure notices. Some orders came in by phone, some went to competitors.
Unblocking took a few hours once it was clear who had access. Finding that out took two days. In total about 40 working hours on the company's and IT provider's side, not counting lost sales. The lesson: renewal on a company card, two notification addresses in the company domain, and a calendar reminder 60 days before the end of the billing period. What happens to a .pl domain after its billing period ends is described in the domain life cycle on dns.pl.
This situation is a typical symptom of a broader problem: knowledge of a critical access sits with one person outside the company. If you are changing IT providers, the domain should be the first item on the list in your handoff from the previous IT vendor.
What can go wrong, and when not to move
Transferring the domain is not always necessary. If your company is the registrant, and the agency or provider renews on time and gives you panel access, it is often enough to add your account, enable MFA and change the notification address. Moving for the sake of moving is risk without gain.
The most common failure during a transfer is a lost DNS zone. The new registrar starts with an empty zone or default records, and the MX or autodiscover record disappears. Result: email stops arriving, and DNS changes take several hours to spread across the internet, so the fix is not instant either. So: copy the records first, transfer second, then compare record by record.
The second trap: transferring on a Friday afternoon or during month-end close. Plan it for a Tuesday or Wednesday morning, when someone can watch email for a day.
Typical costs and timelines:
- On your own, when you have access to both accounts: PLN 0 beyond the domain fee, 2–4 hours of work, 1–5 working days for the registrar change itself.
- With an IT provider, when the code has to be recovered from an agency: usually PLN 1,000–3,000 (about EUR 230–700) and 1–3 weeks, mostly spent waiting for the other side.
- A dispute where the registrant is an agency or a private person: depends on their goodwill or on a lawyer. Every week of delay works against you.
For .pl domains NASK offers a service called .pl Registry Lock. Among other things, it blocks changes of registrant and transfers to another registrar, even with the authinfo code (source: NASK, .pl Registry Lock FAQ). NASK charges nothing for it, but registrars have their own price lists. It makes sense when sales run through an online shop and an hour without the domain costs real money. For a 12-person service company, MFA on the registrar account and a correct registrant are usually enough, and the lock only slows down future changes.
What to do this week
- Look up your domain in WHOIS and write down the registrar and the end date of the billing period.
- Log in to the registrar panel and confirm that the registrant is your company with its tax ID.
- Change the notification address to two addresses in the company domain, for example the owner's and accounting's, and enable MFA.
- Export the DNS zone to a file and store it where you keep your IT documentation.
- Put a reminder in the calendar 60 days before the end of the billing period, with a named owner.
- If the registrant is an agency or a private person, send a request today for the authinfo code and a change of registrant.
The domain is the one IT asset without which email, website and service logins all stop at once. Checking who controls it takes an hour.