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

Update, 19 September 2026: every Maxinodes plan now includes mailboxes on your own domain. This article has been updated to match.

• 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
• Where your mailboxes go
  • Moving mailboxes in the right order
  • What to weigh
• 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 mail provider gives you the exact values for all of this, and they're specific to your account, so repeating them here would help nobody. For the mailboxes that come with our hosting, we put these records on our nameservers for you; if your DNS stays somewhere else, the values to add are in the Help Center.

Where your mailboxes go#

Your mailboxes need a home after the move, and there are three sensible ones. The choice decides how the move goes, so it's worth making before you order.

The mailboxes that come with your hosting. Every Maxinodes plan includes mailboxes on your own domain, on our servers in the Netherlands: IMAP and POP3 for your mail apps, webmail in the browser, and spam filtered into a Junk folder. They share your plan's storage with the site, and the number each plan includes is on the pricing page. Moving your existing mail into them is part of the free migration on every plan. From another cPanel host the mailboxes come across with the rest of the account in one transfer, passwords, forwarders and filters included. From anywhere else we create the mailboxes here and copy the mail over IMAP, which needs each mailbox's password, or a reset.

Professional Email: Microsoft 365 or Google Workspace. This is the upgrade for what a mailbox alone doesn't do: shared calendars, Teams, shared drives, compliance tooling, or mail that shouldn't share a server with your website. Buy the seats through us and the email side is ours: we create the account, set up the mailboxes, move your existing mail across, and put SPF, DKIM and DMARC on the new zone. That goes with the seats rather than with your hosting plan — they're separate products, so it holds whether your hosting is Self-Managed, Managed, or not with us at all. Doing the work means we hold an ordinary administrator account on your tenant, which you can remove at any time.

A provider you already have. 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. If your domain's mail already runs at Microsoft, Google or another outside provider when we set up your hosting, its records are copied onto our nameservers, so the mail stays where it is. 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.

Moving mailboxes in the right order#

Mail can't be staged the way a website can: there is no private copy of your inbox that already receives tomorrow's messages. What you can control is the order.

1. Create the mailboxes at the new place first, and test them. Sign in to each one and send a message out.
2. Copy the mail across while the old mailboxes still answer.
3. Switch the MX record, or the nameservers if the MX moves with them.
4. Copy again, to catch whatever reached the old place during the switch.
5. Keep the old mailboxes for a week before you cancel the old hosting.

The trap sits in step 3. If your old host ran your mail and its MX record points at a name inside your own domain, such as mail.yourcompany.com, switching to our nameservers sends incoming mail to us as soon as the change takes effect, so the mailboxes here have to exist before you switch. If the MX points at a name of the old host's own, the mail stays with the old host after the switch, and stops the day that hosting is cancelled. Tell us before you switch nameservers or cancel the old hosting: we check which case yours is, and move the mailboxes and the mail with you, free.

One limit to plan around: an IMAP copy carries mail and folders. Contacts and calendars don't come with it, and we don't move them separately either — export them yourself while the old account still opens. Migrating the website and its mailboxes is free on every plan.

What to weigh#

Where the mail lives changes three things.

The first is what happens when the hosting stops. Mailboxes in your hosting account share its fate. If an invoice goes unpaid long enough for the account to be suspended, the site goes offline, mailbox logins are locked and nothing can be sent. Incoming mail isn't refused straight away: it's held and retried for about four days, then returned to the senders. Pay within that window and everything is released with nothing lost. Cancelling the hosting ends the mailboxes too: on the cancellation date the account is suspended the same way, and 14 days later it's deleted with all its mail. Within those 14 days you can still ask us to restore it, or to send you a copy; after that it's gone, so move or export the mail before the date. Mailboxes in a Microsoft 365 or Google Workspace account registered to you don't depend on the hosting at all.

The second is space. Our mailboxes share your plan's storage with the site, and a sales inbox that has collected years of attachments takes a real share of it. If inboxes that size are normal in your company, Microsoft 365 or Google Workspace is the better home for them.

The third 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.

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

The mailboxes that come with your hosting cost nothing extra: they're part of the plan. A charge per person per month only starts if you choose Microsoft 365 or Google Workspace.

That charge comes on top of whatever the hosting costs; our own plan prices are on the pricing page. Business Standard, where the desktop Office apps and Teams live, runs about three and a half times the price of Microsoft's mail-only plan. Microsoft and Google set those prices and move them (Microsoft last did on 1 July 2026), so current figures are on our email page rather than here.

Update, 17 September 2026: the paragraph above used to compare four mailboxes with the price of our cheapest Self-Managed plan. Our pricing has changed: a 12 or 24-month plan can now start at a discounted price for its first term, once per customer on a new order, and then renews at the renewal price shown when you order, so a single comparison no longer fits every term. We took our figure out rather than print a new one. The next paragraph now says what the money-back guarantee refunds, in the same words as our terms.

The safety net is thinner, too. Our 30-day money-back guarantee refunds what you paid for the first term of a first hosting order. Microsoft 365 and Google Workspace seats (Managed Email, in our terms) 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 you choose Microsoft 365 or Google Workspace and 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. The mailboxes that come with our hosting are stored on our servers in the Netherlands and backed up with the rest of the account to storage in the EU. Mail sent from them, like mail your website sends, leaves through a relay run by MailChannels, a Canadian company whose relay servers are in the United States; it's listed on our subprocessors page. We went into why that's worth asking any provider in how to tell if your web host is GDPR-compliant.

Whichever home you choose, the mailboxes buy 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.