You parted ways with the agency that built your website years ago. The new team needs access to the domain and nobody has the login; the registration still shows the old agency, and renewal reminders go to someone who left three years ago. It's more common than you'd think, and it surfaces at the worst moment: the day the domain expires or incoming email stops.
This guide treats your domain, hosting and business email as one piece of infrastructure: who each asset should belong to, where it is managed, how to choose hosting and why your messages land in spam. The goal is simple: whoever runs your site next, the keys stay with the business.
Who actually owns your domain?
A domain has two layers of ownership. The first is the registrant: the person or organisation recorded by the registrar and the registry as the holder. The second is the account that manages it, meaning whoever holds the password, the transfer code and the renewal button.
Both should belong to your company. If the registrant field shows your agency or an employee, your brand name belongs to someone else on paper. If the account sits in an agency's reseller panel, every DNS change depends on them, and even a friendly handover means weeks of emails.
Agencies usually bundle client domains for convenience. That can be fine, provided your company is the registrant and the contract lets you move the domain to your own account whenever you ask.
- Put the company's legal name in the registrant field, not a person's.
- Open the registrar account with a role address such as domains@ or it@, never a personal mailbox.
- Turn on two-factor authentication and give at least two people access.
- Pay with a company card. A personal card disappears the day its owner leaves.
Your registrar and your DNS host are not the same thing
The registrar you bought the domain from and the place its DNS records live are often the same, but needn't be. The domain might be registered at one company, its nameservers at Cloudflare, the website with a hosting provider and the email with Microsoft. Four places, four logins, four separate risks.
DNS is your domain's address book: A and AAAA records point to the web server, MX records to the mail service, and TXT records carry SPF, DKIM, DMARC and verification codes. Someone who doesn't know why each record exists can take down both the website and email with one well-meant change.
The classic accident: a new host asks you to point the nameservers at them, and the new zone contains only the website record. The MX and DKIM records stayed behind, so incoming email stops. Outgoing mail still works, so nobody notices until a customer rings two days later asking why nobody replied.
- Before changing nameservers, export the full zone file and keep it in the company archive.
- Lower the TTL on critical records a day or two before a move so changes propagate faster.
- Note which service each TXT record belongs to, delete the ones nobody uses, and after any move test the site, incoming and outgoing email separately.
Renewals, transfer locks and country domains
Don't leave renewal to chance
A domain is a fixed-term registration, not a one-off purchase. Switch on auto-renew, put the card's expiry date in a calendar and, for your main brand domain, renew several years ahead. Reminders go to the account's email address; if that address is wrong, so is the reminder.
An expired domain usually isn't deleted straight away: there is a grace period, then a pricier and fiddlier redemption period, with timings that vary by extension. Automated services snap up valuable names the moment they drop. Keeping your domain is always easier than getting it back.
Transfer locks and auth codes
For .com and most generic extensions, your registrar applies a transfer lock (shown in technical records as clientTransferProhibited). While it is on, the domain can't move to another registrar. To transfer, you remove the lock and request an authorisation code, often called the EPP or auth code, which is shown in the account or sent to its email address. Control of the account is control of the transfer.
Keep the lock on except during a transfer you started yourself. If your business runs on one domain, ask whether a registry lock is available; it requires manual verification before critical changes.
Country domains have their own rules
Country-code domains follow their own registry's rules. A .uk domain, run by Nominet, doesn't use auth codes: you move it by changing its IPS tag to the new registrar's. A .eu domain can only be held by citizens, residents or organisations established in the EU or EEA, which caught out UK businesses after Brexit. Check each registry's eligibility rules before relying on a local domain.
Secure the .com, your home country domain and any market where you actively trade. If someone registered your name in bad faith, .com and other generic domains fall under ICANN's UDRP and .uk has Nominet's Dispute Resolution Service; whether your case is strong enough is one for your legal adviser.
Hosting types: shared, VPS, managed and cloud
The real question when choosing hosting is what your site does and who will look after the server. A five-page company site and a shop handling thousands of orders a day do not have the same needs.
Shared hosting
You share a server, its IP address and often its email reputation with hundreds of other sites. For a low-traffic brochure site that is enough. The catch: if a neighbour is compromised or starts sending spam, you feel it too.
VPS
A virtual private server gives you your own CPU, memory and disk, and makes updates, the firewall and backups your job. An unmanaged VPS someone set up and forgot is a server sitting unpatched online for years. If nobody will maintain it, it is the wrong choice.
Managed hosting
The provider handles maintenance, updates, backups and usually caching and malware scanning. For a business running WordPress or a similar CMS without technical staff, this is often the most sensible balance, at the cost of some control over server settings.
Cloud
AWS, Google Cloud and Microsoft Azure scale as you use them; platforms such as Vercel and Netlify deploy modern framework sites across a global network. They are powerful, but settings are many and billing follows usage. Make sure whoever builds the set-up also configures budget alerts and access permissions.
Whatever you choose, get answers to these questions in writing before you sign:
- Where is the data centre, and how close is it to your customers?
- Who takes backups, how often, where are they stored, and when was a restore last tested?
- What are the support hours and channels, and what happens if the uptime commitment (SLA) is missed?
- If you leave, in what format and how quickly can you get your files and database?
SSL, CDN and backups: automated, and on your account
SSL (strictly, TLS) is no longer up for debate: every page should load over HTTPS. The real issue is renewal. Under a ballot the CA/Browser Forum adopted in 2025, the maximum lifetime of public certificates is shrinking in stages: 200 days since 15 March 2026, falling to 47 days in 2029. Manual yearly renewal is over; it has to be automatic.
Let's Encrypt and most hosting panels already handle this through the ACME protocol. Check that the automation actually works, that failure alerts reach a real person, and that www and every subdomain are covered.
A CDN (content delivery network) serves images and static files from servers close to each visitor and filters some malicious traffic before it reaches you. For a business selling across borders, the speed difference is noticeable. Note that moving to a service like Cloudflare usually means moving your nameservers too: your DNS now lives in that account, and that account belongs in your inventory.
Our one rule on backups: your host's backups are not your backups. They sit on the same infrastructure and disappear with it if the account is suspended or the provider goes under. The familiar 3-2-1 approach is a good starting point: three copies, on two different types of storage, with one kept somewhere else.
- Back up files and database automatically, separately.
- Keep at least one copy in storage that is independent of your hosting provider.
- Test a real restore at least once a year. An untested backup is an assumption.
- Business email platforms protect their infrastructure, but they don't keep a deleted user's mailbox forever. Set retention and offboarding rules deliberately.
Business email: Google Workspace or Microsoft 365?
Mailboxes bundled with hosting look tempting, but spam filtering is weak, storage limited, your reputation tied to every other site on the server, and changing host means moving email too. Beyond a handful of staff, keep email separate from the website.
Choosing between Google Workspace and Microsoft 365 is about habits more than technology. A team that works in the browser and likes Gmail will settle into Workspace; if finance lives in desktop Excel and Teams runs the working day, 365 creates less friction. Both are dependable; the wrong choice is the one your team won't use.
Skipped steps during set-up come back to bite you. The minimum checklist:
- Verify the domain with the provider using a TXT record.
- Replace the MX records with the provider's values and remove the old ones.
- Create a single SPF record, or add the provider to the existing one.
- Generate a DKIM key and publish it in DNS. In Google Workspace this lives in the Admin console under Apps, Google Workspace, Gmail, Authenticate email; Google recommends a 2048-bit key. In Microsoft 365 it sits in the email authentication settings of the Defender portal.
- Publish a DMARC record in monitoring mode (p=none) with an address to receive reports.
- Write down an offboarding procedure: suspend the account and transfer its data rather than deleting it.
SPF, DKIM, DMARC and the Gmail and Yahoo sender rules
These three records prove to the receiving server that a message really came from you. SPF lists the servers allowed to send on behalf of your domain. A domain can have only one SPF record, and it may trigger no more than 10 DNS lookups; adding a second SPF record for each new tool is the most common and least visible mistake. A typical Google Workspace record reads v=spf1 include:_spf.google.com ~all, while Microsoft 365 uses include:spf.protection.outlook.com.
DKIM adds a digital signature tied to your domain to every message, and each service that sends as you (business email, newsletter tool, invoicing system) needs its own key. DMARC sits on top of both. It requires the domain in the visible From address to match the domain verified by SPF or DKIM, known as alignment, and tells receivers what to do with messages that fail: monitor (p=none), send to spam (p=quarantine) or reject (p=reject).
Start in monitoring mode and read the reports for a few weeks. They reveal forgotten senders: an old CRM, a survey tool, the bookkeeper's invoicing software. Once everything aligns, tighten the policy step by step.
The rules in force since February 2024
Gmail and Yahoo tightened their sender requirements in February 2024. According to Google's guidelines, anyone sending to personal Gmail accounts must use SPF or DKIM, have valid forward and reverse DNS (PTR) records, send over TLS and keep the spam complaint rate below 0.3%. Bulk senders, meaning those sending 5,000 or more messages a day, need SPF, DKIM and DMARC; the DMARC policy can be p=none, but the From domain must align with SPF or DKIM. Marketing email must support one-click unsubscribe as well as a visible unsubscribe link, and Google expects requests to be processed within two days.
Two details get missed. The 5,000 threshold counts your primary domain and its subdomains together, and once a domain qualifies as a bulk sender it stays one. And the rules have teeth: from November 2025, Google began rejecting non-compliant traffic, temporarily and permanently. Microsoft brought in similar requirements in May 2025 for domains sending more than 5,000 messages a day to Outlook.com, Hotmail and Live addresses. Google advises keeping the spam rate under 0.1% and never reaching 0.3%.
Why your web server shouldn't send your email
If contact form notifications arrive only sometimes or keep landing in spam, the problem is almost certainly how the form sends them. Many sites send straight from the web server using PHP's mail() function or WordPress's defaults. They come from a server outside your SPF record, carry no DKIM signature and fail DMARC.
Worse, some forms use the visitor's address as the sender; a message claiming to be from [email protected] but sent from your server fails Gmail's DMARC policy. On shared hosting you may also inherit a blocklisting caused by someone else's spam.
The fix is to send form notifications and transactional email such as order confirmations through a service built for the job. Amazon SES, Postmark, Mailgun, SendGrid and Brevo are common options. The site connects over authenticated SMTP or an API, the service signs messages with DKIM on behalf of your domain, and you get delivery logs and bounce reports.
- Use a subdomain such as notify.yourcompany.com for transactional mail, so a reputation problem with marketing can't hold up order confirmations.
- Always send from an address on your own domain, and put the visitor's address in the Reply-To field.
- Store form submissions in the site's admin area or database as well, so an enquiry isn't lost if an email is delayed.
- Send yourself a test submission, open it in Gmail and choose Show original. You should see PASS next to SPF, DKIM and DMARC.
Where to start
Start with an inventory. For each row below, record whose name the account is in and where the credentials live. Every empty cell is a door you will one day be locked out of.
| Asset | Whose name it should be in | Where to keep it |
|---|---|---|
| Domain (registrant) | The company's legal name | Registrar; invoices in the company archive |
| Registrar account | Company role address, at least two admins | Password manager, with recovery codes |
| DNS hosting (e.g. Cloudflare) | Company account; agency gets its own user | Password manager; exported zone file in the archive |
| Hosting or cloud account | The company, billed to a company card | Password manager; contract and SLA in the archive |
| Business email admin | The company, at least two super admins | Password manager; recovery codes stored offline |
| Transactional email service | Company account | API keys in the password manager, not in the site's code |
| Backups | Storage the company controls | A second location independent of the host |
| Search Console and Analytics | Company as owner, agency as user | Ownership held by the company account |
- Check the registrant in your registrar's control panel and have it corrected if it isn't the company.
- Move every login into the company password manager and turn on two-factor authentication.
- Export your DNS zone and clear out records nobody can explain.
- Confirm auto-renew and the transfer lock are on.
- Check you have a single SPF record and DKIM on every sending service, then start DMARC in monitoring mode.
- Connect your site's forms to a transactional email service, and test-restore one of your backups.
When AYTE Digital builds a new site or takes over an existing set-up, we draw up this inventory with you, bring the accounts under your company's name and test DNS and email authentication before handing over. If you ever move to another team, you won't have to hunt for a single key.
