Delegate access lets you invite a developer or agency into your registrar account to work on your products without giving them your password, your payment methods, or the ability to transfer your domain away. It exists because the alternative — sharing the login — is how businesses lose control of their domains.
The mechanics take about two minutes and the registrar’s own help pages cover them adequately. What is worth more attention is the decision underneath: which access someone actually needs, what they can still do with it, and the arrangement that keeps you in control when the working relationship ends.
Table of contents
- What delegation actually is
- Grant the least that works
- Why sharing the password is genuinely dangerous
- The handover checklist
- Reviewing access periodically
- How this fits the rest of the stack
- FAQ
What delegation actually is
Most large registrars offer some version of it, under names like delegate access, account access or user permissions. The shape is consistent: you invite someone by the email on their own account at the same registrar, they accept, and they can then operate on your products while signed in as themselves.
What that buys you over sharing a password:
- They never learn your credentials, so your account is not compromised the moment their laptop is.
- Actions are attributable. The audit trail shows who did what, which matters when something changes and nobody remembers changing it.
- Access is revocable in one click, without a password reset that breaks everyone else.
- Permission is scoped. Delegates typically cannot see or change payment methods, account passwords or security settings.
- Your two-factor authentication stays yours, rather than being a shared secret passed around a team.
The permission levels vary by registrar but usually come in roughly three grades: read-only, manage products, and full access. The middle one covers what a developer actually needs — DNS records, product settings, renewals — without exposing billing.
The person you invite generally needs their own account at that registrar. That is not an obstacle; accounts are free and it is what makes the attribution work.
Grant the least that works
Match the level to the actual task, which is usually smaller than the request.
- Someone pointing a site at new hosting needs DNS record management. That is it. They do not need billing, and they do not need the ability to initiate a transfer.
- An agency managing a site long-term needs product management, so they can handle renewals and configuration. Still not billing.
- Someone doing a one-off migration often needs nothing at all — you can make the two record changes yourself while they watch, and it takes five minutes.
- Full account access is for a business partner or a trusted internal administrator, not for a contractor.
The default instinct on both sides is to over-grant, because it is faster than working out what is needed. It is worth the extra two minutes, because the cost is asymmetric — over-granting is invisible until the day it matters.
One thing to check specifically: whether the permission level you are granting includes the ability to unlock the domain or approve a transfer. That is the one capability you almost never want to delegate, because it is the one that is irreversible.
Why sharing the password is genuinely dangerous
Worth spelling out because it is still the most common arrangement in small businesses.
If a developer has your registrar login, they can transfer your domain to another account. Not maliciously, necessarily — a well-meaning agency consolidating client domains into their own account is a common and entirely sincere version of this, and it ends the same way when the relationship does.
Once a domain has moved into someone else’s account, recovering it is a dispute rather than a support ticket. It can take weeks, it may require paying whatever is asked, and in the meantime your website and your email both belong to someone you are arguing with.
The other password-sharing failures are more mundane and just as damaging: the credential ends up in a chat log or a shared document, it never gets rotated after the contractor leaves, and your two-factor authentication either gets disabled to make sharing possible or is tied to a phone number belonging to someone who no longer works with you.
The rule that avoids all of it: the business owns the registrar account, in the business’s name, with the business’s payment method and the business’s two-factor device. Everyone else gets delegated access. This is true regardless of how much you trust the person — it is about what happens later rather than about them.
The handover checklist
When an agency or developer already holds your domain and you want it back, or when a relationship is ending.
- Establish where the domain actually is. A public WHOIS lookup shows the registrar, which is often not the company you have been paying.
- Create your own account at that registrar, in the business’s name.
- Ask for a transfer into your account, or for the authorisation code to move it to a registrar of your choosing. Both are normal requests.
- Check the domain lock status — a transfer will not proceed while it is locked.
- Confirm the registrant contact email is one you control, since that is where the transfer approval goes.
- Move DNS before or with the domain, and note the full record set first so nothing is lost.
- Revoke their delegate access once you hold the account.
Do this while the relationship is good. Every part of it is a routine request between people who are getting along, and a slow painful negotiation between people who are not.
Note also that a domain cannot normally be transferred between registrars within 60 days of registration or a previous transfer. That is an ICANN rule rather than a registrar being difficult, and it is worth knowing before you promise a timeline.
Reviewing access periodically
- Audit the delegate list twice a year. Contractors finish, agencies get replaced, and access outlives both by default.
- Remove access when a project ends, as part of finishing the project rather than as a separate task nobody owns.
- Keep the account email on a domain you control but separate from the one at risk — a recovery address on the same domain is useless the day the domain breaks.
- Two-factor on the registrar account, always, on a device the business controls rather than one person’s phone.
- Note who has access, somewhere findable. For a small business this is a line in a document, and it is the difference between a five-minute audit and an afternoon of guessing.
The registrar account is the single most important credential a small business has online. Losing the website is an inconvenience; losing the domain takes the website and the email at once, and the recovery is somebody else’s decision.
How this fits the rest of the stack
The domain and the hosting are two separate things to hold, and the split matters most at the moment a working relationship ends. The RunxBuild hosting calculator covers the hosting side — service, database, storage and bandwidth — so the numbers are yours to see rather than bundled into a retainer. RunxBuild deploys from your own GitHub repository with the custom domain and certificate handled at deploy, which keeps the code, the domain and the hosting account each in your name rather than a contractor’s.
Useful related references:
- Squarespace vs GoDaddy Website Builder: Design Ceiling vs Speed to Live
- Terraform try(): Safe Access for Values That Might Not Be There
- How to Prevent Direct Access in WordPress: The ABSPATH Guard and Beyond
- Custom domains and certificates on RunxBuild
FAQ
What is delegate access at a registrar?
An invitation that lets someone operate on your domains and products while signed in as themselves, without learning your password or seeing your payment methods. Actions are attributable, permission is scoped, and access can be revoked in one click without a password reset.
What can a delegate do to my domain?
It depends on the level granted — typically read-only, product management, or full access. Product management covers DNS records, settings and renewals without exposing billing. Check specifically whether the level you grant allows unlocking the domain or approving a transfer, since that is the irreversible capability.
Why should I not just share my registrar password?
Because anyone with the login can transfer your domain to another account, and once it has moved recovery is a dispute rather than a support ticket. The common version is not malicious — an agency consolidating client domains into its own account — and it ends the same way when the relationship does.
How do I get my domain back from a web developer?
Look up the registrar with a public WHOIS query, create your own account there in the business’s name, and ask for a transfer into it or for the authorisation code. Check the domain lock status and confirm the registrant email is one you control. Do this while the relationship is still good.
How often should I review who has access to my domains?
Twice a year, and always at the end of a project as part of finishing it. Contractors move on and agencies get replaced, but delegated access outlives both by default. Keep the registrar account’s recovery email on a different domain from the one it protects.