Domain and Hosting Migration During a Website Redesign: DNS Cutover Without Email Downtime, the 60-Day Transfer Lock, SSL, GDPR and a Launch-Day Checklist (2026)

Redesign meetings start with design and the CMS, but what breaks on launch day is usually email and the SSL certificate: no mail reaches the office, or browsers warn the next morning.

The cause is moving the site's foundations (domain, DNS, email and server), often held with different companies. One forgotten setting is enough.

This article sets out, from primary sources, what to do, in what order and by when when you move servers or domains. Redirects for changing URLs are covered in "Website Migration SEO", and whether to switch CMS in "Leaving WordPress or Staying". This article covers everything else.

Main sources for this article: ICANN's transfer and expiry policies, SIDN and JPRS rules, Google Search Central, RFC 7208, 6376 and 9989, Google, Yahoo and Microsoft sender requirements, the CA/Browser Forum, and guidance from the European Commission and the Dutch Data Protection Authority.

What you will learn	Key point
What breaks most often	Email (MX, SPF, DKIM) and SSL (Sections 1, 8, 9)
Domain transfer limits	60-day lock for gTLDs, token for .nl, 35-day code for .jp (Sections 3, 4)
When to lower TTL	A week before cutover, as Google advises (Section 6)
What to check for GDPR	Processing agreement, sub-processors, backups (Section 10)
Cancelling the old server	30+ days after cutover, once logs are quiet (Section 13)

1. A redesign moves four things

The foundations are separate contracts

A website looks like one box but has four layers: the domain (the name itself, held with a registrar), DNS (the directory that turns the name into server addresses, run by whoever hosts the nameservers), the web server (which returns pages) and the mail server (which holds the inboxes).

Even when one hosting company provides all four, moving only the server changes how the rest are handled. Cancel the host's DNS and the MX records (where mail goes) stored there disappear too.

DNS holds the destinations for both web and email, which is why most server moves go wrong there.

Decide layer by layer what changes

Decide for each layer whether it changes or stays.

Layer	Main reason to change	What it affects
Domain	Rebrand, .jp to .com or .nl	Search signals, print, email addresses
Registrar	Price, control panel, ownership clean-up	Limits on changes during transfer
DNS	Leaving the host, consolidating	Web, email and verification
Web server	Speed, PHP version, moving data into the EU	Pages, forms, SSL
Email	Moving to Microsoft 365 or Google Workspace	Mailbox content, deliverability

Changing the domain has the biggest impact; the rest can move unnoticed if done in order.

Change one thing at a time

Google's guide to site moves also assumes stages: prepare, switch, monitor. Do not move the server, change the domain and launch a new design on the same day, or you cannot tell which change caused a drop in traffic or deliverability.

2. Inventory before the move: ownership, logins, records

Who is the registrant?

First check who is listed as the domain's registrant. If it is a former agency or an individual employee, their approval is needed for transfers and renewals. SIDN advises changing the registrant to your own name or company if it is your registrar or web developer, because only the registrant can transfer the domain.

Since GDPR, WHOIS often hides individual registrant names, so check in the registrar's control panel.

List who can log in where

For the five control panels (registrar, DNS, hosting, email and Search Console), write down who can log in and whose phone holds the two-factor device. Note expiry dates, auto-renewal, contract end dates and notice periods too. If any login is missing, recover it before setting a date.

Export every DNS record

The most common failure is forgetting to copy a record to the new DNS. Besides the panel's list, record the values actually returned by tools such as dig, including records on subdomains such as autodiscover.

Record	Role	What happens if it is missed
A / AAAA	Web server IP address	The site does not load
CNAME	Aliases (www, external services)	Newsletter or booking tools stop
MX	Where mail is delivered	Mail does not arrive
TXT (SPF)	Servers allowed to send	Outgoing mail lands in spam
TXT / CNAME (DKIM)	Signing public key	Signature checks fail
TXT (DMARC)	Policy on failure	Bulk sender rules no longer met
TXT (verification)	Google, Microsoft ownership	You lose access to the console
CAA	Which CAs may issue	Certificate issuance is refused
SRV	Teams and client auto-setup	Client auto-configuration fails

Each shows up on launch day or the next, so compare the new DNS line by line.

List everything that sends mail

Form auto-replies, order confirmations, newsletters, invoicing tools and booking systems also send mail in your domain's name. Each needs to be covered in SPF and DKIM, and missing one means only that service's mail stops arriving.

3. Domain transfers: auth codes and the 60-day lock

What a transfer changes

A domain transfer is a change of registrar. Neither the domain name nor the site changes. For gTLDs such as .com, transfers follow ICANN's Transfer Policy.

Item	Rule (ICANN Transfer Policy)
Auth code (AuthInfo)	A unique code per domain from the losing registrar
Deadline for the code	Within 5 calendar days if you cannot generate it
Losing registrar approval	Approved if not denied within 5 calendar days
Effect on expiry	Adds one year (total term up to 10 years)
When transfer can be denied	Within 60 days of registration or of a prior transfer
Lock after registrant change	60 days unless you opted out beforehand

The last two rows affect timing: right after registration or a registrant change, you may be unable to move the domain for 60 days.

Order of registrant change and transfer

ICANN's policy says that after a Change of Registrant, the registrar imposes a 60-day transfer lock, unless the registrant opted out before the change. The policy also advises completing any planned transfer before changing the registrant.

So to take over a domain held by a former agency and move it, transfer first, then change the registrant. While the registrant is someone else, though, the transfer needs their approval.

The policy is under review

ICANN is reviewing the Transfer Policy. The GNSO working group's recommendations, including shortening the post-transfer lock to 30 days and removing the 60-day lock after a registrant change, were sent to the ICANN Board in April 2025 with a proposed implementation window of about 18 months. As of 31 October 2026, we could not confirm an effective date for the new rules in official documents. Check the actual periods with your registrar before transferring.

Does DNS stop during a transfer?

Nameserver settings are usually carried over. However, if you use the losing registrar's free DNS, it may stop working when the transfer completes, so move DNS elsewhere before the transfer.

4. How .nl, .jp, .com and .eu rules differ

Four top-level domains side by side

Sites aimed at both Japan and Europe often hold several of .com, .nl, .jp and .eu.

Item	.com (gTLD)	.nl	.jp (general-use)	.eu
Registry	Verisign (ICANN rules)	SIDN	JPRS	EURid
Who can register	Anyone	Anyone, via a registrar	Address in Japan	EU/EEA citizens, residents, organisations
Transfer credential	AuthInfo code	Token	AuthCode	Transfer code
Code timing	Provided within 5 days	Provided within 5 days	Valid 35 days from the day after issue	Ask your registrar
Completion	Up to about 5 days	Immediate once in order	A few days	Ask your registrar

The same word, "transfer", hides different waiting times and code rules, and .jp and .eu have geographic eligibility rules.

Points to note by registry

For .nl, the losing registrar must provide the token within five days, and if it does not, the new registrar can contact SIDN. If you use DNSSEC (signed DNS responses), SIDN advises choosing a new registrar that supports it. For .jp, all applications go through JPRS-accredited registrars, and any registrar-change lock must be removed first. A co.jp domain is for companies registered in Japan, generally one per organisation. A company registered only in the Netherlands needs an address in Japan to register a new .jp. For .eu, the conditions in Regulation (EU) 2019/517 must be met throughout the registration term.

5. Missed renewals and expired domains

Renewals lapse around moves

The old agency's contract ends, and so does the auto-renewal on its card; reminders go to someone who has left. How long the previous registrant alone can recover a lapsed name differs by registry.

After these periods, anyone can register the name. JPRS warns that cancelled domains can be taken by third parties, and links to the old site or mail sent to old addresses can then be misused.

What happens before and after expiry

For gTLDs, ICANN's Expired Registration Recovery Policy (ERRP) sets the rules. Here it is alongside .nl and .jp.

Stage	gTLD (ERRP)	.nl (SIDN)	.jp (JPRS)
Notices before expiry	At least two, about 1 month and 1 week before	Depends on registrar	Depends on registrar
Right after expiry	Another notice if not renewed within 5 days	—	Expiry is end of month, 1 year after registration
Site and email	DNS interrupted for the last 8 renewable days	Resolution stops on cancellation	Suspended on cancellation
Recovery window	30 days after deletion (RGP)	40-day quarantine	1st–20th of next month
Recovery cost	Often above normal renewal	Depends on registrar	Fee required (varies)

The ERRP's eight-day interruption exists to get the registrant's attention. If your site suddenly goes down, check the expiry date first.

Settings that prevent lapses

Turn on auto-renewal with a company card or invoice billing, set the registrant contact to a shared address (for example domains@), and assign someone to check a month before expiry.

6. DNS: lower the TTL first, then switch nameservers

What TTL is

TTL (Time To Live) tells caches how many seconds they may remember a DNS answer, as defined in RFC 1035. With a TTL of 86,400 seconds (one day), visitors may be sent to the old server for up to a day after a change. The change that lowers the TTL also takes until the old TTL expires to spread, so if you lower a one-day TTL, wait at least a day before switching.

Google's advice and practical values

For server moves without URL changes, Google advises lowering the TTL to "a conservative low value (for example, a few hours)" at least a week before the move. In practice, teams lower it to 300 to 3,600 seconds a week ahead, keep it short for two or three days after cutover, then restore the normal value (3,600 to 86,400 seconds) once stable. These are working values, not rules.

Start earlier if the old TTL is long or mailboxes are large.

Changing records is not the same as changing nameservers

A move can be done by rewriting only the A record's IP or by changing the nameservers themselves.

Method	What changes	How fast it spreads	Main risk
Rewrite records	Individual A, AAAA, MX values	That record's TTL	Low (only changed lines)
Change nameservers	NS registered at the registrar	Parent zone TTL (up to about 2 days for .com)	Every record you missed disappears

A nameserver change depends on the parent zone's TTL (.com or .nl), which you cannot shorten. If the DNS provider is changing too, load every record into the new DNS and check it before switching nameservers. Then switch the web server separately by rewriting the A record, keeping the two changes apart.

If you use DNSSEC

With DNSSEC enabled, changing nameservers requires the DS record at the parent (a fingerprint of the key) to match the new DNS's signing key. If they do not match, validating resolvers cannot resolve the name, and both site and email stop.

If both providers support handing over keys, use that. If not, remove the DS record before the switch to disable DNSSEC temporarily, then re-enable it with the new key afterwards.

7. Email: the order that avoids downtime

Switching MX and migrating mailboxes are separate jobs

Moving email involves switching MX (where new mail goes) and migrating mailboxes (copying past mail). The first is one DNS line, the second takes hours to days depending on size. IMAP migrations into Microsoft 365 and Google Workspace both move mail and folders, not calendars or contacts.

Method	What moves	Scale	Notes
Microsoft 365 IMAP migration	Mail and folders	Tens to hundreds of accounts	Move calendars and contacts separately
Microsoft 365 cutover migration	Full Exchange mailboxes	Up to 2,000 (150 recommended)	Only from Exchange
Google Workspace data migration	Mail and folders	Up to 100 accounts per run	Delta imports possible

The IMAP scale is a rule of thumb; the other figures come from the vendors' documentation.

Order: copy, switch MX, then catch up

1. Create accounts in the new service and verify domain ownership (TXT record)
2. Copy past mail from the old server (initial migration)
3. Switch the MX record to the new service
4. Wait for the TTL plus a margin, then import the delta that reached the old server
5. Update mail apps and phones to the new server

Between steps 3 and 4, mail can arrive at either server, so keep the old server receiving and catch up with the delta. Cancel the old server first and that mail is lost.

Do not forget mail sent by the web server

Form auto-replies are often sent from the web server, so the sending IP changes with the move. If SPF does not include the new server, only the auto-replies land in spam. Google requires reverse DNS (PTR) for all senders, which you often cannot fix on shared hosting, so sending through your mail service's SMTP is more reliable.

8. SPF, DKIM, DMARC and sender requirements

What the three do

Mechanism	Standard	What it checks	What breaks in a move
SPF	RFC 7208	Is the sending IP on the domain's list?	New server IP not added
DKIM	RFC 6376	Does the signature verify with the public key?	Public key record not copied
DMARC	RFC 9989 (May 2026)	Do SPF/DKIM results align with From?	Reports still go to an old address

All three live in DNS TXT records (DKIM sometimes as CNAME), so they move with DNS.

Two SPF traps

Under RFC 7208, more than one SPF record makes evaluation fail (permerror). Following a new mail service's instructions to add a record, and ending up with two, is a common mistake. The other trap is the limit of 10 DNS lookups (include and similar). Adding services eventually exceeds it, so use the move to remove includes you no longer use.

DMARC became a standard in May 2026

DMARC long lived in an informational document (RFC 7489) but became a Standards Track RFC 9989 in May 2026. Existing v=DMARC1 records keep working. The pct tag, which applied a policy to a share of mail, was removed, and finding the organisational domain moved from the Public Suffix List to a "DNS Tree Walk". If you use pct, set your policy assuming it will be ignored.

Google, Yahoo and Microsoft requirements

Since 2024, major mailbox providers have required sender authentication.

Requirement	Gmail (from Feb 2024)	Yahoo	Outlook.com (from May 2025)
All senders	SPF or DKIM, PTR, TLS	SPF or DKIM, PTR	—
Bulk threshold	Over 5,000 a day	Bulk senders	Over 5,000 a day
Bulk authentication	SPF, DKIM, DMARC (p=none OK)	SPF, DKIM, DMARC (p=none OK)	SPF, DKIM, DMARC (p=none OK)
Spam rate	Under 0.3% (aim for 0.1%)	Under 0.3%	—
Unsubscribe	One-click	Easy unsubscribe	—

Microsoft first said non-compliant bulk mail would go to Junk, but an update on 29 April 2025 changed this to rejection. Even below 5,000 a day, setting up all three is the safe choice. Google requires DKIM keys of at least 1,024 bits and recommends 2,048.

9. SSL certificates: shrinking lifetimes and the cutover gap

Lifetimes are getting shorter

Under CA/Browser Forum Ballot SC-081, the maximum lifetime of publicly trusted SSL/TLS certificates is falling in stages.

Issued from	Maximum lifetime	Domain validation reuse
15 March 2026	200 days	200 days
15 March 2027	100 days	100 days
15 March 2029	47 days	10 days

Let's Encrypt has announced that its default certificates move to 64 days on 10 February 2027 and 45 days on 16 February 2028. Replacing certificates by hand once a year is no longer workable. Automatic renewal (ACME) on the new server belongs on your selection criteria.

The certificate gap at cutover

The HTTP-01 check common with Let's Encrypt cannot issue until the domain points to the new server, so browsers may warn right after cutover. To avoid that, issue the certificate before cutover with DNS-01, which validates through a TXT record. If CAA records restrict which CAs may issue, add the new server's CA or issuance will be refused.

10. Choosing a server: EU data location, GDPR and PHP

The host is a processor

When form submissions or order history sit on the server, the hosting company is a processor under GDPR. The Dutch Data Protection Authority (Autoriteit Persoonsgegevens, AP) lists a provider hosting a customer's website as a processor. Article 28 GDPR requires a contract covering the subject, duration and purpose of processing, and the AP says that without a processing agreement (verwerkersovereenkomst) both parties are in breach. Get and read the standard agreement before signing up.

Can the server be outside the EU?

Hosting outside the EU is not prohibited in itself. Data can go to countries with an adequacy decision (Japan since 2019) and to US companies in the EU-US Data Privacy Framework (adequacy decision of 10 July 2023). Elsewhere you need safeguards such as Standard Contractual Clauses (SCCs).

What to check	Where	Why
Processing agreement	Terms, DPA	Article 28 GDPR obligation
Data centre location	Contract, control panel	Whether transfer safeguards are needed
Sub-processor list	DPA annex	Where CDN, backup and support sit
Backup location	Specifications	Copies can sit outside the EU
Deletion on exit	Terms	No personal data left on the old host
Incident contact	SLA	Meeting the 72-hour breach report

Backups and sub-processors are most often overlooked.

Check the PHP version

For WordPress and Laravel sites, the new server's PHP version decides whether the move works. Official support periods:

Version	Active support	Security fixes
PHP 8.2	Ended 31 Dec 2024	Until 31 Dec 2026
PHP 8.3	Ended 31 Dec 2025	Until 31 Dec 2027
PHP 8.4	Until 31 Dec 2026	Until 31 Dec 2028
PHP 8.5	Until 31 Dec 2027	Until 31 Dec 2029

PHP 8.1 and earlier no longer get security fixes. Upgrading from an old version can break plugins, so test on a staging environment with the same version as the new server. PHP 8.2 ends in two months, so avoid it on a new host.

11. Launch-day steps

Four stages on the day

Split the day into four stages: freeze, final sync, DNS switch and checks. Just before, back up the old server's files and database to a location separate from both servers.

Before step 3, write down how to roll back (which records revert to which values).

Hour-by-hour runbook

The table is an example. If you have users in both Japan and Europe, pick a quiet time in both time zones.

Time (example)	Task	What to check
2 hours before	Announce the freeze on CMS edits and orders	Did the team get the message?
1 hour before	Final sync of DB and uploads	Counts and latest posts match
0 min	Point A (and AAAA) to the new server	Both servers serve correct content
0 min	Change MX now or on another day	Can the new service receive?
+30 min	Check from several networks and devices	Certificate, forms, images, login
+2 hours	Submit forms, check auto-replies	Not landing in spam
Next morning	Error logs, Search Console	No rise in 5xx or 404

For a Japanese–English site, test forms in both languages and check that auto-replies reach Japanese mobile carrier addresses.

12. Search Console: when to use Change of Address

Not for server-only moves

The Change of Address tool is for moving to a different domain or subdomain. Do not use it for HTTPS, www changes, path-only changes or hosting changes without URL changes.

Type of move	Change of Address	Main tasks
Server only (same URLs)	No	TTL, move verification files, watch crawling
HTTP to HTTPS	No	301 redirects, canonical
www to non-www	No	Redirects and canonical
New domain	Yes	301 redirects, verify both properties
New subdomain	Yes (per domain property)	As above

Building redirects when URLs change is covered in "Website Migration SEO".

Requirements when the domain changes

You must be an owner of both old and new properties with the same Google account. Once submitted, Google prioritises crawling the new site and forwards signals for 180 days. Keep redirects for at least 180 days and keep the old domain registered for at least one year.

What to watch in a server-only move

For moves without URL changes, Google says crawling drops temporarily right after the move and recovers over a few days. Put the Search Console verification file or meta tag on the new server too, and make sure robots.txt and firewalls do not block Googlebot.

13. When to cancel the old server and contracts

Cancel once traffic has gone

Google advises keeping the old setup until its logs show traffic has reached zero. Some resolvers ignore TTL, and old configurations may point at the IP directly.

Contract	When to cancel	Check first
Old web server	30+ days after cutover	Access logs, backups, personal data deleted
Old mail server	30+ days after MX switch	Delta imported, inbound mail stopped
Old DNS	A few days after nameserver change	New DNS answers every record
Old domain (if changed)	Keep at least one year	Redirects and traffic
Old registrar (if transferred)	After transfer completes	Auto-renew charges stopped

"30 days" is a rule of thumb. Hosting contracts have notice periods, so work backwards from the cancellation deadline when setting the cutover date.

Delete personal data before cancelling

The old server still holds personal data from enquiries and orders. Processing agreements require deletion or return at the end of the contract, so ask for deletion before cancelling and get confirmation.

14. Cost and effort ranges

Ranges by size

There is no public benchmark for server and domain migration work on its own. The figures below are working estimates, not statistics. They use Dutch hourly rates (freelance web developer €73, agency average €106, excluding VAT) and 1 euro = 175.97 yen (European Central Bank reference rate, 22 October 2026). The rate sources are in "Website Redesign Cost and How to Read a Quote".

Scope	Effort	In euros	In yen (approx.)
Site only, email stays	4–10 hours	€292–€1,060	¥50,000–¥190,000
Site plus up to 10 mailboxes	10–24 hours	€730–€2,544	¥130,000–¥450,000
New domain, multilingual or e-commerce	24–60 hours	€1,752–€6,360	¥310,000–¥1.12 million

Effort covers the inventory, staging tests, cutover and 30 days of monitoring; service fees are extra. Large mailboxes or DNSSEC push toward the upper end.

What to check in a quote

If a quote says only "server migration", check whether it includes the DNS inventory, mailbox migration, SPF, DKIM and DMARC, the certificate method, cancelling the old server with data deletion, and how long post-launch monitoring lasts.

15. Common failures

Failures on launch day

Failures that appear on the day or the next are almost always missed DNS records or certificates.

Failure	Cause	Prevention
No mail reaches the office	MX lost in a nameserver change	Copy and compare every record
Form replies land in spam	New server not in SPF	List senders, send via SMTP
Browser warning	No certificate, CAA mismatch	Pre-issue with DNS-01, check CAA
Some people still see the old site	TTL not lowered	Lower TTL a week ahead
Site and mail both down	DNSSEC DS and key mismatch	Remove DS first or hand over keys

Four of these five are prevented by the inventory in Section 2 and the TTL step in Section 6.

Failures weeks to a year later

Later failures include an expired domain paid by the former agency, a 60-day lock after a registrant change, a missing verification TXT and old-server bills after a missed notice deadline. All happen in the "last 10%", so use the checklist to the end.

16. Cases (fictional examples)

These examples combine common situations. They are not real companies.

Case A: a Japanese manufacturer, domain held by the old agency

A Japanese parts maker (30 staff) found that its .com was still registered to the agency that set it up 10 years ago. It transferred first to a registrar of its choice, then changed the registrant to avoid the 60-day lock, and launched the server move and new design three weeks apart.

Case B: a Japanese-owned service firm in the Netherlands, consolidating email

A Japanese-owned service firm near The Hague (8 staff) planned to move to Microsoft 365 and change servers at the same time. Because forms, invoicing and the newsletter also send mail, it merged SPF into one record, enabled DKIM for each service, started DMARC at p=none, and switched MX in a different week.

Case C: an EU web shop, PHP version and backups

An online shop selling Japanese food in the EU (300 orders a month) was moving from PHP 8.1 to a PHP 8.4 server, without knowing if its payment plugin was compatible.

Case	Main issue	Order chosen	Effort
A: Manufacturer	Ownership and transfer	Transfer → registrant → server → design	10–24 hours
B: Service firm	Email consolidation	DNS → email → server	10–24 hours
C: EU web shop	PHP and order data	Staging → order freeze → cutover	24–60 hours

In Case C, the team ran payments end to end on staging with the same version, paused orders for an hour for the final sync, and asked for the old server's personal data to be deleted 30 days later.

17. Before-and-after checklist

Two weeks before

• Checked the registrant, expiry, auto-renewal and payment method
• Can log in to registrar, DNS, hosting, email and Search Console
• Exported every old DNS record (including subdomains, TXT, CNAME)
• Listed every service that sends mail in the domain's name
• Checked the new host's processing agreement, data location and backup location
• Tested on staging with the new server's PHP version

One week to one day before

• Lowered the TTL (more than the old TTL in advance)
• Loaded every record into the new DNS and compared line by line
• Merged SPF into one record with the new server, 10 lookups or fewer
• Pre-issued the certificate or decided how to issue it; checked CAA
• Decided how to handle DNSSEC (key handover or temporary DS removal)
• Wrote the rollback plan

Cutover to 30 days after

• Froze edits, synced, then switched A and MX
• Checked pages, forms, auto-replies and login from several networks
• Checked Search Console ownership and crawling
• Restored the TTL two to three days later
• Cancelled the old server after logs went quiet, and requested data deletion

Summary

• The foundations are four layers: domain, DNS, email and server. Change one at a time, and on a different day from the design launch
• First bring domain ownership and logins back in-house. For gTLDs, a registrant change triggers a 60-day lock, so transfer first
• .nl transfers immediately with a token; .jp uses a 35-day AuthCode and needs an address in Japan; .eu requires an EU/EEA link
• Lower the TTL a week ahead, and copy and compare every record before changing nameservers
• Switching MX and migrating mailboxes are separate jobs. SPF: one record, 10 lookups; DMARC is RFC 9989 since May 2026
• Certificate lifetimes fall from 200 to 100 and then 47 days. Assume automatic renewal and pre-issuance
• Choose hosting by processing agreement, location and backups, and cancel the old server after 30+ days, once traffic has gone and data is deleted

Sources

Domains (ICANN, SIDN, JPRS, EURid)

• Transfer Policy — ICANN: AuthInfo deadlines
• Transfer Policy Review — GNSO: review recommendations sent to the Board
• Expired Registration Recovery Policy — ICANN: notices before and after expiry
• Transferring your domain name — SIDN: token
• FAQ — SIDN: why the registrant should be your own company
• Undoing the cancellation of a domain name — SIDN: 40-day quarantine
• Change of registrar (in Japanese) — JPRS: 35-day AuthCode
• Domain types and eligibility (in Japanese) — JPRS: general-use JP and co.jp eligibility
• JP domain lifecycle (in Japanese) — JPRS: expiry, suspension, restoration
• Notes on cancelling a domain (in Japanese) — JPRS: risk of third-party registration
• Who can register a .eu domain name? — EURid: .eu eligibility

DNS and email standards, sender requirements

• RFC 1035: Domain Names — IETF: TTL definition
• RFC 7208: SPF — IETF: one record
• RFC 6376: DKIM — IETF: signing
• RFC 9989: DMARC — IETF: standardised May 2026
• Email sender guidelines — Google Workspace Admin Help: all senders and over 5,000 a day
• Sender Best Practices — Yahoo: bulk sender requirements
• Outlook's New Requirements for High-Volume Senders — Microsoft Tech Community: requirements from May 2025 and the switch to rejection

Mailbox migration

• Ways to migrate multiple email accounts to Microsoft 365 — Microsoft Learn: IMAP, cutover and staged migration
• Cutover migration to Exchange Online — Microsoft Learn: up to 2,000, 150 recommended
• Migrate from IMAP servers to Google Workspace — Google Workspace Admin Help: IMAP migration scope
• Import email from an IMAP account — Google Workspace Admin Help: 100 accounts per run

SSL certificates

• Ballot SC081v3 — CA/Browser Forum: 200, 100 and 47 days
• Decreasing Certificate Lifetimes to 45 Days — Let's Encrypt: 64 and 45-day timeline

Google Search

• Site moves without URL changes — Google Search Central: lower TTL a week ahead
• Site moves with URL changes — Google Search Central: stages of a move
• Change of Address tool — Search Console Help: when it applies

Hosting and GDPR

• Supported Versions — PHP: support periods
• Adequacy decisions — European Commission: countries with adequacy
• EU-US data transfers — European Commission: Data Privacy Framework (10 July 2023)
• Verwerkers (processors, in Dutch) — Autoriteit Persoonsgegevens: processing agreement duties
• Processor or controller example list (in Dutch) — Autoriteit Persoonsgegevens: hosting providers are processors

All sources were checked on 31 October 2026. Rules, requirements and screen names change, so check the latest documents and your registrar's and host's guidance before you start. The timings in Figures 1, 3 and 4, the TTL values in Section 6, the 30 days in Section 13, the effort in Section 14 and the cases in Section 16 are DevNJ's working framework, not rules or statistics.