Domain desk · Churches & Congregations
Web hosting for churches — The name outlasts every volunteer who has ever managed it
Most congregations that lose their website do not lose it to a hacker or a bill — they lose it because the only person who knew the registrar login moved to another parish.
The short answer
A congregation's domain fails at handover, not at the technology. Register it to the church as an organisation, point the administrative contact at an office or role-based mailbox that survives a change of volunteer, keep auto-renew on behind a church card, and record where the name is held somewhere the next person will find it.
Hosting & Domains keeps the registrant and administrative contacts, the transfer lock, auto-renew and the whole zone in one panel, with two-factor login available on the account and the auth code released on request.
By the Hosting & Domains team · Reviewed 24 August 2026
24/7
Answering, any hour
1-click
Install, one click
Free
Certificates included
Daily
Copies, every day
Most visits to a church website are somebody checking when the service starts. Everything else on the site matters far less than that one fact being right and the address being reachable.
The address is the fragile part. It was registered by a volunteer, with a personal card, against a personal email, and nobody wrote down where. Two rotations later the church is paying a bill nobody can log in to change.
What follows is the handover arrangement, and then the small number of DNS and mail details a congregation actually has to get right.
The commonest way a congregation loses its address
It is never dramatic. A volunteer registers the name on a personal card against a personal email address. Years later the card expires, auto-renew fails, every warning bounces into an unread inbox, and the first human sign of trouble is the site going dark — or a stranger writing to ask what the name is worth to you.
Prevent it with paperwork rather than technology. The church as registrant, a role-based mailbox as the administrative contact, a church card behind auto-renew, and a note in the church's own records saying which registrar holds the name and where the login lives. That note is the single most valuable thing in this article.
Who can actually move the name
Two things control a domain. The transfer lock stops a move completing without the auth code; the registrar account can lift that lock, request the code and repoint the nameservers. So the account matters more than the lock, and one login can redirect the website and the mail together.
Give each volunteer who needs access their own login rather than sharing one, turn on two-factor authentication, and keep the administrative email address current. When somebody hands over, you remove their login instead of changing a password everybody knows.
Service times, caching and the week the clocks change
The service time should live in exactly one place on the site rather than repeated across six pages, because repeated facts are what go stale. That is content discipline, not DNS. What DNS controls is different and worth knowing: TTL decides how long resolvers may keep reusing a cached answer about your name, which matters only when you change where the name points.
So if the site is moving to a new host, lower the TTL on the records involved a week beforehand, make the change, verify it from a connection outside the church wi-fi, then raise it back. Do that in an ordinary week — not the week of a carol service.
Giving mail that reaches the inbox
A donation receipt is a financial message sent on the church's behalf by a giving platform, which means your domain has to authorise it. List the platform's sending service in your SPF record, switch on DKIM signing, and publish a DMARC policy so a receiving filter knows what to do with anything that fails.
Inbound follows the MX records, and those must name hostnames rather than an IP address or a CNAME. Get that wrong and most messages arrive while a handful never do — which for a congregation means a pastoral email that appears to have been ignored.
The other names the church holds. There is usually more than one: the hall hire name, the school name, the magazine name, the one bought for a festival nobody now remembers. Bring them into one account so every expiry date is in one list, then decide which carries a site and which forwards home with a 301 and a certificate of its own.
Review that list once a year. Names bought for projects that never happened renew quietly forever, and dropping a few speculative ones usually pays for the one the church will actually use.
A name that survives a handover
Registrant and administrative contacts, individual logins, two-factor authentication, the transfer lock, auto-renew and every DNS record sit in one panel, so a handover is a change of user rather than a shared password.
DNS is answered by redundant nameservers in our London datacentre, and the platform itself runs from a London facility with redundant power, cooling and several upstream carriers.
- Church as registrant, role mailbox as contact
- Individual logins, with two-factor available
- Every name's expiry date in one list
- Free certificates, issued and reissued for you
Why Hosting & Domains
Standard on every plan
Ownership that survives rotation
The church as registrant and a role-based mailbox as administrative contact, so no volunteer's departure takes the name with them.
Handover without shared passwords
Individual logins with two-factor available, so somebody leaving means removing an account rather than telling everybody a new password.
One list of expiry dates
Every name the church holds in one account, with term end and auto-renew status visible for each.
Giving mail that is trusted
SPF, DKIM and DMARC beside the MX records, so a donation receipt is authorised rather than filtered.
Timing you control
TTL editable per record, so a move to a new host is a window you chose rather than a week of uncertainty.
Free to leave whenever
Unlock the name and the auth code appears at once, with the registry's 60-day rule the only clock involved.
Quick Start
Order placed to site online
- 1
Write down where the name lives
Which registrar holds it, what the expiry date is, and who is listed as registrant and administrative contact. Put that note in the church's own records.
- 2
Correct the contacts, then the access
Church as registrant, role-based mailbox as administrative contact, a church card behind auto-renew, individual logins with two-factor on.
- 3
Check the two mail paths
MX to hostnames for what arrives, SPF and DKIM for what the giving platform sends. Test both with real messages in an ordinary week.
Built In
Fitted to every plan
- Registrant and administrative contacts editable by you
- Individual logins, with two-factor authentication available
- Every name's expiry date visible in one account
- Transfer lock and auto-renew as switches you control
- MX priorities plus SPF, DKIM and DMARC on one screen
- TTL editable per record, so a move can be timed
- 301 forwarding with a certificate on the forwarding name
- Free SSL issued once the name points here, and reissued for you
- cPanel, the panel most of the industry already runs
- Support staffed every hour, first reply aimed at 2 hours
Frequently Asked
Questions we field again and again
Nobody knows where our domain is registered. Where do we start?
With a WHOIS lookup on the name. It will tell you which registrar administers it, when the term ends, and who is listed as registrant and administrative contact. Write all three down in the church's own records. Then work out who can log in: if that is a former volunteer, a transfer into a church-held account is the fix — unlock, take the auth code, start it here, approve both confirmation emails.
What is the safest way to hand the website over to a new volunteer?
By adding and removing individual logins rather than passing round a shared password. Give each volunteer their own account with only the access they need, turn on two-factor authentication, and keep the registrant as the church and the administrative contact as a role-based mailbox. Then a handover is an administrative change, not a trust exercise, and nothing depends on anybody remembering to change a password.
Do donation receipts need anything set up in DNS?
Yes, if a giving platform sends them on the church's behalf. That platform has to be listed in your SPF record and signing with DKIM, with a DMARC policy published so a receiving filter knows what to do with a message that fails. Without those TXT records a receipt claiming to come from your domain has nothing behind it, and filters treat it accordingly.
We are moving the site to a new host. When should the DNS change happen?
In an ordinary week, never in the week of a major service. Lower the TTL on the records you intend to change several days beforehand so cached answers expire quickly, make the change, verify it from a connection outside the church wi-fi, then raise the TTL back. Edits here go live within minutes, but a resolver holding a long-TTL answer will keep serving the old one regardless.
Keep reading
VPS Hosting — Arranged for Churches & Faith Groups
A virtual server behind the name, with its DNS managed in the same panel.
Web Hosting
cPanel hosting behind the name, with the certificate, the migration and year one included.
Changing provider? Work through this checklist beforehand.
A straightforward running order for a migration your visitors never spot: which files travel first, how to bring the mail across without dropping a single message, the right moment to repoint DNS, and the two errors that sit behind almost every outage we get called in to fix.
Write down where the name lives.
Church as registrant, a role mailbox as contact, individual logins, and every expiry date in one list.
View VPS Hosting — Arranged for Churches & Faith Groups plans