In short and in plain language
This article is about who owns your website. A domain is the address of your website on the internet.
Domain, hosting, website and email often run on separate contracts. Hosting means a provider puts your website online. Each part can be lost on its own.
What matters is who is listed as the domain holder. That person decides about the address. For a move, the holder's details should be correct.
Keep a list of all logins. It is a small step to prepare for an emergency.
With us, the domain and the logins are in your business's name.
The website address is printed on every van, every invoice and every trade directory entry. Who actually owns it is a question most businesses cannot answer on the spot. 94 percent of German trade businesses run a website of their own (Bitkom), and a good share of those addresses were set up years ago by someone who is no longer around: a nephew, the first provider, an agency that no longer exists in that form. Around 17.7 million .de domains were registered at the end of 2025 (DENIC), and every single one has exactly one holder named in the contract with the registry. As long as everything runs, nobody notices. It becomes visible on the day something has to be moved, switched or rebuilt.
Key takeaways
- A website consists of five layers with five separate contracts: domain, DNS, hosting, the site with its content system, and email. They can sit with different providers and they can be lost one by one.
- What decides everything is the domain holder: the holder is DENIC's contracting party and therefore the party with substantive entitlement to the domain (DENIC, translated from the German original). Whoever is named there controls the address.
- A move runs on the AuthInfo code: 8 to 16 characters long, normally expiring after 30 days (DENIC). An active provider passes it to the domain holder; otherwise it goes by registered post to the stored holder address (DENIC) - so those holder details have to be right.
- If the provider drops out, deadlines apply: TRANSIT gives the holder one month (DENIC), a DISPUTE entry initially runs for one year (DENIC), and the redemption grace period runs until a randomly determined moment on the 31st day after the registration was terminated (DENIC).
- 81 percent of trade businesses have not established structured emergency management (Bitkom). A maintained list of accounts and contracts is the smallest step that measurably changes that state.
Five layers you can lose one by one
To the business, the website is one thing: the page carrying services, references and the phone number. Technically it is five building blocks that need have nothing to do with one another. The domain is the address. The DNS zone says where that address points. Hosting is the space the files sit on. The site with its content system is what the customer sees. And email hangs on the same address while often being delivered by an entirely different provider. Each of these layers has its own contract, its own invoice and its own login.
In practice they rarely all sit in one place. A common picture: the domain is registered in the name of the acquaintance who helped out in 2011. Hosting runs through an agency that bills for it. Email sits with a third provider because the mailbox existed beforehand. As long as the invoices are paid and the site is reachable, this spread causes no work. It only becomes a problem when one layer has to be moved and a login is needed that the business does not have.
Anyone having a website built for their trade business should therefore treat the five layers not as a technical detail but as five lines in a list. In our experience that list takes half an hour to write and saves weeks later. The overview below shows what hangs on each layer and how to tell that it sits in your own house.
| Layer | What hangs on it | How you can tell it belongs to you |
|---|---|---|
| Domain | The address itself, the holder record, every inbound link from outside | Your business appears as domain holder with its full company name and street address in the domain data |
| DNS zone | Where the address points: website, mailbox, verification records for outgoing mail | You have a login that lets you change records without calling anyone |
| Hosting | Storage, database, the certificate for the encrypted connection, backups | The hosting contract is in the name of the business and the invoice arrives at the business address |
| Website and content system | Content, images, templates, legal texts, user accounts | At least two people in the business have their own account with administrative rights |
| Mailboxes and forwarding rules on the same address | You can create a new mailbox without asking the website provider |
The right-hand column is the actual test. Not who built it, but who can change it. A business that can answer all five lines without outside help holds its website. One open line does not mean anything is broken, but the next change will be slower and more expensive than it needs to be.
The holder decides about the address
For .de domains there is one clear role that everything hangs on. The registry maintains a contract, and that contract has exactly one counterparty. Everything else - the provider through which the domain is administered, the agency that built the site, the service company that issues the invoice - hangs off that single role without replacing it.
The domain holder is DENIC's contracting party and thereby the party with substantive entitlement to the domain.
The practical rest follows from that sentence. The holder record must carry a street address, an email address and a telephone number; a post office box does not suffice (DENIC). These are exactly the details that post is sent to when something has to be decided. If they are out of date - an old business address, the box of a departed employee, a mail address at the former provider - the entitlement still exists, but it does not reach the business.
Just as important is what the registry expressly does not do: it is at no point obliged to check whether the holder's data are correct or complete (DENIC). So there is no body that notices on its own that an acquaintance's name still sits on your business domain. Anyone who wants to know has to look.
Where to check the holder in five minutes
The legal notice says nothing about the holder
A widespread misunderstanding: our business is named in the legal notice, so the domain must be ours. The two have nothing to do with each other. The legal notice fulfils an information duty towards users. The service provider has to keep the name and the address at which they are established, and for legal entities additionally the legal form and the authorised representative, permanently available, easily recognisable and directly accessible (Section 5 DDG). That is information about who operates the service, not a statement about the contract with the registry.
The two roles can diverge without anyone having done anything wrong. An everyday example: the business operates the site and is correctly named in the legal notice. The domain holder, however, is still the agency that created the account in 2015. The statutory duty is met, but in practice the business has no access to the address. The reverse also happens: the business is the holder, while the legal notice still shows the legal form it had before it was converted.
Anyone wanting to work cleanly checks both entries separately and writes down the result:
- Domain holder: full company name including legal form, current street address, a mail address that someone in the business reads, a phone number where someone picks up.
- Legal notice: name and address of the business, for legal entities additionally the legal form and the authorised representative (Section 5 DDG), plus the further details that apply to your trade.
- Administering provider: the company through whose account the domain is technically managed - a third piece of information, and as a rule neither of the first two.
- Invoice recipient: whoever receives the annual invoice for the domain is not necessarily the holder. Check both.
These four lines belong in the same file as the trade registration and the craft register entry. In Germany, 1,038,126 businesses are currently entered in the craft registers and in the register of trades similar to crafts (ZDH) - and for most of them the website is by now the first point of contact with new customers. An address in that role should not be documented worse than a company van.
Changing provider: AuthInfo, 30 days, registered post
Moving a .de domain from one provider to another runs on a password, the AuthInfo. The new provider needs it to trigger the change. Two figures matter in practice: the AuthInfo has to be between 8 and 16 characters long (DENIC), and as a rule the code expires automatically after 30 days and then has to be requested again (DENIC). A move that gets stuck between a holiday and a building site therefore starts over. For domains in the TRANSIT state, covered further below, the registry names an exception: there an AuthInfo generated by the registry stays valid until that period ends (DENIC).
The route to the AuthInfo normally runs through the current provider. If that provider is no longer active or does not respond, there is a direct route: the new provider applies for the AuthInfo directly at the registry, which sends it by registered post to the address stored in the domain data (DENIC). That closes the circle back to the previous section - the letter goes to the stored address, not to the correct one. Anyone still carrying the old workshop there is waiting for post that arrives somewhere else.
- Before the move, check that holder data and postal address are correct. A change costs nothing and usually takes minutes.
- Only request the AuthInfo once the new provider is ready to start - as a rule the 30-day period runs from issue, not from need (DENIC).
- Respect the length and character rules: between 8 and 16 characters (DENIC). Over-long self-chosen passwords are rejected.
- Write down the DNS records before switching, especially the records for outgoing mail. They are easily forgotten in a move and take email down with them.
- Do not start a move on a Friday afternoon. A transfer whose follow-up questions are only answered on Monday leaves an open state for three days.
A transfer is a procedure, not a token of goodwill
When the provider drops out: TRANSIT, DISPUTE, redemption
Providers give up their business, agencies close, sole traders retire. For the case where a domain is left without an administering company, there is a dedicated state. The domain stays in place but is temporarily held directly by the registry, and the holder is written to. The holder has one month to decide on a change of provider (DENIC). In this state an exception applies to the AuthInfo: a code generated by the registry stays valid until the period ends, so the 30-day rule does not apply here (DENIC).
Here too everything depends on being reachable: contact details held by the registry have to be current, otherwise the TRANSIT letter cannot be delivered (DENIC). Same address, same cause, same consequence. The three most important special cases at a glance:
| Situation | What happens | Deadline |
|---|---|---|
| TRANSIT | The domain is temporarily held directly by the registry because no provider administers it any more. The holder is written to and chooses a new provider. | one month to decide (DENIC) |
| DISPUTE | A third party asserts rights to the domain. A domain carrying a DISPUTE entry can still be used by its holder, but cannot be transferred to a third party (DENIC). | initially one year, extendable (DENIC) |
| Redemption grace period | The registration has ended but the domain is not yet free. It is kept for the last registered holder and can be recovered. | until a randomly determined moment on the 31st day (DENIC) |
| Direct contract with the registry | The holder has the domain held without an intermediate provider. This is meant as a bridge, not as a permanent arrangement. | domain administration for one year: 79.00 euros (DENIC) |
The direct contract costs more than administration through a provider, but it works without that provider's involvement: 79.00 euros for one year of domain administration, with all prices including statutory VAT (DENIC). For a business whose phone number has sat under that address for twelve years, this is a manageable amount - provided somebody notices the situation in time. That is exactly what ongoing website maintenance is for, keeping deadlines and availability in view.
The silent failure is the expensive one
The access list: one document, two people
The practical core of this topic is unspectacular: a document saying which layer sits where, whose name the contract is in and who inside the business holds the login. It replaces neither a password manager nor a backup, but it answers the question that gets asked first in an emergency. In our experience it is written on handover day, because all the details are on the table anyway.
The separation matters: the list names the location, the contracting party and the responsible person. The passwords themselves do not belong in the same file but in a store that two people can reach. A single head is a point of failure, and a note in a desk drawer is not administration. A list can look like this:
{
"domain": "sample-heating.invalid",
"holderPerDomainData": "Sample Heating Ltd, business address",
"holderMailAddress": "office@sample-heating.invalid",
"administeringProvider": "Provider A, customer number 000-000",
"renewalDate": "2027-03-14",
"dnsManagedAt": "Provider A, access with owner and office manager",
"hostingContract": "Provider B, invoice to the business address",
"contentSystem": "two accounts with administrative rights",
"mailboxes": 4,
"backupHeldBy": "Provider B, daily, restore test outstanding",
"listCheckedOn": "2026-09-01"
}The last field is the most important one. An access list untouched for two years describes a business that no longer exists in that form: staff have changed, a provider was swapped, a mailbox was added. One fixed date per year, for instance together with the review of the legal texts, keeps it usable.
Spread logins across two heads
The owner and a second person in the office each have their own account with administrative rights - no shared login, no collective address that nobody reads. If one person is unavailable, the business can still act.
One business address for all accounts
Domain, hosting and content system should be tied to a mail address belonging to the business, not to an employee's private mailbox. Otherwise deadline notices leave the building with the person.
File contracts and invoices
Every layer comes with a document: contract number, provider, term, notice period. Filing that means you can answer within an hour, during any change, what has to be cancelled and what stays.
Backups including a restore test
A backup without a restore test is an assumption. Have it demonstrated once that a state really can be restored, and note the date in the same list.
If you are still deciding whether to build the site yourself or have it built, the trade-off is covered in the article on a website builder or an agency. For this topic the same rule applies either way: the holder question is settled before the first draft, not after it.
Email hangs on the same address
The underrated layer is email. Mailboxes on the business domain look like a by-product of the website, but they carry quotes, order confirmations and invoices. Technically they hang on the same DNS records as the site. Anyone moving the address while thinking only about the page may switch off the inbox along with it.
On top of that come the verification records by which receiving servers recognise that a message from your address really comes from your sending service. If they are missing after a move, quotes land in the customer's spam folder without anyone receiving an error message. That is the classic silent failure: the business only sees that fewer people get in touch.
- Before any move, draw up a list of mailboxes and forwarding rules - including the addresses that only forward and are therefore easily overlooked.
- Write down all DNS records for outgoing mail and check each one individually after the move, rather than just opening the website.
- After the change, send a test message to a mailbox outside the business and look in its spam folder, not only in the inbox.
- Delete old mailboxes only once the new state has run steadily for several days. An empty inbox cannot be reconstructed.
- Check the recipient of the website's form: enquiries often run to an address nobody had on the list during the move.
If you are working on your contact routes anyway, it is worth looking at the structure of the site: the article on separate service pages instead of one combined page shows how enquiries arrive more precisely. And where consent comes into play, the article on the cookie banner in a trade business helps sort out what is actually required.
Passwords and the case nobody plans for
Logins are only as robust as the passwords behind them and the question of who can reach them in an emergency. The figures are uncomfortably clear: 71 percent of the companies surveyed attach great importance to IT security (Bitkom), but only 15 percent of the companies surveyed have clearly defined processes and measures in place for the event of a cyberattack (Bitkom). 81 percent have not so far established structured emergency management (Bitkom). Between aspiration and preparation there is a wide gap.
For a trade business the way out of that gap need not be large. It consists of a list, two people and a reliable password standard. The German Federal Office for Information Security names two workable patterns:
- A short and complex password should be at least eight characters long and consist of four different character types: upper and lower case letters, digits and special characters (BSI, translated from the German original).
- A long and less complex password should be at least 25 characters long (BSI, translated from the German original) - a memorable sequence of words is often the better choice in practice.
- One password per login. A password used in five places turns a single incident into five.
- Where a second confirmation step is offered, it should be switched on - especially for domain and hosting accounts, because the address itself hangs on them.
The second part is organisational. Who inside the business can reach the password store? What happens if that person is away for two weeks? And where is the access list when the office computer is itself the problem? A printed copy in a safe is unfashionable and has rescued more businesses than any declaration of intent.
Take stock
Walk through all five layers and write down where they sit and who holds the login. Open points are noted as open, not guessed. For a small business this stocktake usually takes under an hour.
Put the holder record straight
Is the business correctly recorded as domain holder, with its full company name, current street address and a mail address that is read? If not, this is the first and most important step, because every further procedure hangs on it.
Spread logins across two heads
For each layer at least two people with their own account, passwords in the shared store, second confirmation step switched on. Shared collective accounts get dissolved in the process, not documented.
Set a date for the review
One fixed annual date on which the list, the holder data and the legal texts are looked at together. Tying that date to the domain renewal saves a second calendar entry.
Walk through all five layers and write down where they sit and who holds the login. Open points are noted as open, not guessed. For a small business this stocktake usually takes under an hour.
Is the business correctly recorded as domain holder, with its full company name, current street address and a mail address that is read? If not, this is the first and most important step, because every further procedure hangs on it.
For each layer at least two people with their own account, passwords in the shared store, second confirmation step switched on. Shared collective accounts get dissolved in the process, not documented.
One fixed annual date on which the list, the holder data and the legal texts are looked at together. Tying that date to the domain renewal saves a second calendar entry.
For handover and relaunch: the address first
A relaunch is the moment when all five layers are touched at once. That is exactly why it is also the moment when missing logins surface. Reversing the order and settling the address question before the first draft costs half a day at the start and saves weeks at the end. How a change runs without visibility collapsing is set out in the article on a relaunch without losing visibility.
The same applies in miniature at handover. A finished website is only handed over once the roles, not just the files, have been transferred. What falls due afterwards is described in the article on maintaining the site after handover. The list below is the short version of what belongs on the handover day checklist:
- The domain holder is the business, with company name, legal form, street address, phone number and a mail address belonging to the business.
- Access to DNS administration exists and has been opened together once - not merely promised.
- The hosting contract is in the name of the business, the invoice goes to the business address, the notice period is written down.
- Two accounts with administrative rights exist in the content system, and both have been tested.
- Mailboxes, forwarding rules and the recipient address of the contact form are listed and checked.
- The access list is filled in, it carries the date of the last review, and two people know where it is kept.
If you work through the list and get stuck in two places, that is the normal case and no cause for concern. Both usually clear up with one mail to the previous provider and a look at the domain data. If you would like support with that, have a look at our range of services, compare prices and terms, or have a trade website built with the address question settled from the start.
Sources for this article
Related Articles
When the Enquiry Lands in Spam: Form Emails Explained
Enquiry emails vanish when sender and domain do not match. What SPF, DKIM and DMARC check, how to run the delivery test and what belongs in maintenance.
Website backups: what is saved and how it comes back
Files, database, configuration and mailboxes: what belongs in a backup of a trade website, how often it runs and how you can tell that it will really come back.
Who maintains the website once the project ends
What falls due after handover: updates, backups, availability, legal texts, content. What the business can do and who owns the domain, content and logins.