Your Website Moves in an Afternoon. Your Email Is the Part That Breaks.

• What DMARC actually checks
• The senders you forgot are the ones that break
• Publishing the DKIM records is not turning DKIM on
• We had to do this on our own domain first
• Forwarding is where mail comes apart
• The fortnight before you move
• The mailboxes themselves don't come with you
• What it costs, and what it doesn't cover

Three weeks after the move, a customer mentions in passing that they never got the invoice. You go and check. It went out, and it arrived — into their junk folder, filed there by a rule nobody can see, and going by the dates it has been happening since the day you switched.

That is what an email problem looks like after a host move. A broken site announces itself within the hour; mail just stops landing where it used to.

The website side of a move gets a rehearsal. We build your site on a private staging address, you click around it yourself, you choose the hour it goes live, and both copies keep serving while DNS catches up. That sequence is written up separately. Email works differently, because the only realistic test involves other people's messages arriving in real time.

One part of a move is also strictly one-way. Files and databases you can download tonight and restore anywhere. Mail history comes out over IMAP, from mailboxes that are still running and still accepting their passwords, so it comes out while the old account is alive or it stays where it is. Nine years of correspondence with your accountant, gone with the panel.

So the mail goes first, before anyone touches the website.

What DMARC actually checks#

Almost everything that goes wrong here comes out of one misunderstanding.

Three records do the work. SPF lists the servers allowed to send for your domain. DKIM signs each message, and that signature gets checked against a public key you publish in DNS. DMARC sits on top and tells the receiving server what to do when the other two fail.

Here's the bit that catches people. DMARC tests whether SPF and DKIM passed for your domain: whether the domain SPF checked, and the domain named inside the DKIM signature, match the domain in the From: line your recipient sees. That match is called alignment, and it's the whole test.

So a message can sail through SPF and fail DMARC anyway. Your newsletter platform sends from its own servers under its own SPF record, so SPF passes — for the newsletter platform. The From: line says your company. Nothing lines up. With the policy at p=none the message goes out regardless, and nobody hears about it for years.

The job before a move, then, is working out what sends mail as you, and whether each of those things can align.

The senders you forgot are the ones that break#

Everyone configures the mailbox provider. It's the obvious one, it comes with instructions, and it's rarely the culprit. The trouble is the other four or five systems with your domain in the From: line, and there are always more of those than people expect: the invoicing tool, a contact form plugin or two, whatever sends the newsletter, the booking widget on the appointments page, some trial account a colleague opened two years ago and left running.

All of it works today, because nothing is enforcing alignment yet.

Publishing the DKIM records is not turning DKIM on#

We got this wrong on our own domain for a while, having read the documentation twice.

Microsoft 365 hands you two CNAME records during setup, and nearly every guide stops there. Ours did too, until we rewrote it. Until you go back into the admin centre and switch custom-domain signing on, Exchange Online carries on signing your mail with its own tenant domain instead of yours. The signature is real and it verifies; it just says d=yourcompany.onmicrosoft.com, which is a Microsoft domain rather than one of yours, so it fails alignment. What you end up with is a domain that looks properly configured and is passing DMARC on SPF alone.

The switch sits on the same admin screen that handed you the two records. Ours is on now, and checking yours takes about a minute.

We had to do this on our own domain first#

Since this is asking you to go and look at your own domain, it's fair to say what ours looked like. At one point: nothing. No _dmarc record on the main domain, none on the subdomains. We had been running perfectly respectable mail for months on SPF and DKIM, missing the record that ties either of them to the address a recipient actually reads.

So we did the thing we're recommending here. Published a monitoring-only policy with a reporting address, then read what came back before changing anything else.

Those reports are the point of the exercise. They surface senders you had forgotten about, and that list resists being written from memory; we couldn't manage it, and we built the place. Tighten the policy once the reports stop producing new names.

Forwarding is where mail comes apart#

The instinct during a move is to forward the old address into the new mailbox for a few months, just in case. It's a reasonable instinct, and it fails SPF on every message that comes through.

When a server forwards a message it rewrites the envelope and leaves the From: header alone. SPF then gets checked against the forwarding server, which sits outside the original sender's SPF record, so a perfectly legitimate message fails. DKIM survives a forward when the signature is intact, which is where that DKIM switch suddenly matters.

Automatic forwarding to external addresses is off by default on Microsoft 365 now, and switching it on takes a deliberate policy change. If somebody in the company has been quietly routing everything to a personal address, better to find that out before the move.

The fortnight before you move#

None of it is hard. It just has to happen in order.

1. Start with the mail, not the site. While the old mailboxes still answer you have options.
2. Inventory every sender. Walk the table above, on paper. Anything that emails a customer with your domain in the From: line goes on the list.
3. Fix whatever can't align before you publish any policy at all.
4. Publish p=none with a reporting address, and actually read the reports.
5. Then tighten, once they've been boring for a fortnight.
6. Clear up after yourself at the old place. A DKIM key published for a mail server you no longer run is a working signing credential whose private half you no longer control. Retiring it takes one record.

Your provider gives you the exact values for all of this. Ours are in the help centre, and repeating them here would help nobody; they're specific to your account.

The mailboxes themselves don't come with you#

Better to know this before you order than after. We don't host mailboxes. There's no webmail on our servers and no mail accounts in cPanel, on any plan; the "Add Professional Email" line in our store buys you a seat at Microsoft or Google, not a mailbox on our node.

So if your mail currently lives on the old hosting account, which is how most shared hosts do it, it can't come across as it is. It has to be re-homed somewhere, and working out where is part of your move whether or not you buy anything from us.

Somewhere doesn't have to mean somewhere we sell. Bring-your-own email is welcome: point MX, SPF, DKIM and DMARC at whoever you like in the client area DNS manager, leave the website records with us, and the two sets stay out of each other's way. Buying Microsoft 365 or Google Workspace direct works the same way, and so does buying it through somebody else — the mailboxes land in an account registered to you either way. Going through us gets you one invoice and someone to ask. It gets you the same mailbox.

Two things change once the mail stops living on the web server.

The first is that it stops sharing a fate with the site. An unpaid invoice or an acceptable-use hold suspends a hosting account, and where the mailboxes are bundled in, they go down with it. Getting the site back is a billing problem you sort out in an afternoon. Mail that was refused while everything was down is somebody else's bounce notice by then, and mail a customer gave up on resending is simply lost.

It stops sharing the disk quota too. Ten gigabytes is a normal entry-plan allowance, ours included, and a few years of a sales inbox full of attachments will find the edges of it.

The second shows up later. Mailboxes sitting in a Microsoft 365 or Google Workspace account registered to you, rather than to your host, stay put when you change hosts. The day itself still needs work, because routing lives in DNS and every record above has to be rebuilt correctly on the new nameservers. But that's DNS work once per move instead of a mailbox migration once per move.

On Managed plans we do the email side with you: the mailboxes, the IMAP copy, and SPF, DKIM and DMARC on the new zone. An IMAP migration copies mail and folders; contacts and calendars are a separate job, and worth asking about specifically wherever you buy. Doing that work means we hold delegated administrative access to your Microsoft or Google account, and you can take it away whenever you want. On Self-Managed the email side is yours. The site migration is free either way.

What it costs, and what it doesn't cover#

There's a bill attached to all this. Mail that arrived free with the hosting turns into a charge per person per month.

At the cheapest that's about €3.50 a seat ex-VAT on annual billing, so four people comes to €14 a month, against €3.49 for our cheapest Self-Managed plan on the same cycle. Business Standard, where the desktop Office apps and Teams live, runs about three and a half times the mail-only figure. Those are August 2026 rates and they're a snapshot rather than a standing promise: Microsoft moved them on 1 July and will move them again. Current figures are on the business email page.

The safety net is thinner, too. Our 30-day money-back guarantee covers the recurring fee on a first hosting order. Resold mailboxes are non-refundable from the moment they're provisioned, and they sit outside our SLA and outside our commitment to keep encrypted backups in the EU/EEA. That's in the terms, and it's worth ten minutes before you order.

If the mailboxes need to stay in the EU, say so at the start, because the region generally has to be chosen while the account is being created. If you already have mailboxes somewhere, go and check where they actually ended up rather than assuming Europe was the default. We went into why that's worth asking any provider in how to tell if your web host is GDPR-compliant.

A managed platform buys you exactly one thing here: a sender that can align, signing with a key published on your domain and showing up in your SPF record. Your invoicing tool still sends from wherever it has always sent from, and so do the forms, the newsletter and the helpdesk.

So do the mail first. Inventory the senders, fix whatever can't align, publish p=none, and give the reports a fortnight. Book the website cutover after that.

Not sure which of your senders would fall over the day you tighten the policy? Send us your domain and we'll tell you what we find. You don't have to be a customer to ask.