My business email has stopped arriving

Business email failing on your own domain is usually not an email problem. It is a domain or DNS problem, and it is frequently caused by work done on the website.

That connection is the useful part of this page and the part nobody expects. Mail delivery to you@yourbusiness.com.au is directed by records attached to the domain, and the website’s address is directed by records attached to the same domain. Change the second set carelessly and the first set goes with it.

The first three checks

1. Did the website stop too? If both stopped at the same moment, the domain itself is the suspect — an expiry, a registrar problem, or a wholesale DNS change. That is on an expired domain.

2. Did anything happen to the website recently? A new site, a new host, a migration, a platform change, or anyone touching DNS. If mail stopped within a day or two of website work, that is the cause until proven otherwise.

3. Can you send but not receive, or neither? Sending and receiving use different mechanisms, and which one failed narrows the cause immediately.

Symptom	Likely cause
Website fine, no mail arriving	Mail delivery records changed or removed
Website and mail both gone	Domain expired, or nameservers changed
Can receive, cannot send	Mailbox, authentication or sending policy
Mail arrives for some senders only	Sending-policy records mismatched
Mail arrives in junk everywhere	Sending-policy records missing or wrong
One mailbox affected, others fine	That mailbox, not the domain

The last row is worth checking first because it is the cheapest to eliminate and it points somewhere completely different.

Why website work breaks email

When a site moves, the records that say “the website lives here” have to change. Those records live alongside the records that say “mail for this domain goes here”. Three ways it goes wrong:

The nameservers were changed wholesale. Pointing the domain at a new host’s nameservers replaces the entire record set with that host’s defaults, which usually do not include your existing mail configuration. The site appears instantly and mail stops instantly.

The mail records were not copied. A careful migration copies every record; a hurried one copies the ones needed to make the website appear.

Mail was assumed to be part of hosting. Where mail was hosted with the old web host and the site moved, mail moves too unless somebody separated them deliberately. This is the strongest argument for keeping business email independent of website hosting, which is a decision made at setup rather than during an incident.

What to do about it

If website work just happened, go to whoever did it, tell them mail stopped at the same time, and ask specifically whether the mail delivery records were carried across. Named that precisely, it is usually fixed in minutes. Vaguely described as “our email is broken”, it is diagnosed at your expense.

If nothing changed, start with the mailbox provider. Mailboxes fill, accounts lapse, subscriptions fail to renew, and rules created years ago start filing mail somewhere unexpected.

Either way, check whether the domain is current. It takes thirty seconds and it eliminates the worst case.

The mail that was sent during the outage

This is the part with commercial consequences and it is the part that gets forgotten once mail starts flowing again.

While delivery is failing, sending systems retry for a period and then stop. Some senders get a bounce; some get nothing. When the records are fixed, mail sent during the gap does not queue up and arrive.

So once it works, do two things. Tell your regular contacts, suppliers and any platform that sends you notifications that mail over that period may not have reached you. And check anything with a deadline attached — quotes, orders, invitations, renewal notices. A missed renewal notice during an email outage is how the next incident starts.

The junk-folder version

A subtler failure: mail arrives but lands in junk for everyone, or for one large provider. That is usually the sending-policy records — the ones that let receiving systems verify that mail claiming to be from your domain really is.

These are commonly disturbed by the same migrations described above, and they are also commonly never set up at all. It is a specific, fixable, DNS-level task, and it is worth naming it as such rather than accepting “email is unreliable” as a permanent condition.

This applies to any business email, DNS, domain, records or account setup — Wix, Google Workspace, business Gmail and the rest

Whether the site runs on Wix, WordPress, Squarespace or anything else, and whether mail runs through Google Workspace, a business Gmail inbox, Microsoft 365 or a hosting provider’s own mail service, the underlying mechanism is identical: DNS records on the domain point mail and web traffic to wherever each currently lives, and disturbing one set during general troubleshooting can take out the other. A locked-down platform like Wix manages some of this inside its own dashboard rather than a separate DNS panel, which changes where you click to fix it but not the underlying cause, and any business emails already queued keep failing until the records are fixed regardless of which platform sent them.

Common issues like a locked domain account, or DNS changes made through the wrong login, both fall into the same first-three-checks framework above regardless of which email provider or website platform is involved.

What to tell the person you call

Whoever you call — the host, the mailbox provider, or whoever did the website work — the same four facts route the problem, and having them ready is the difference between a fix and an investigation.

The domain, and whether it is current. Whether the website is also affected. Whether the problem is receiving, sending, or both. And what changed in the fortnight before it started, particularly anything touching the website.

Stated that way it is usually diagnosed on the first call. Described as “our email has stopped working”, it is diagnosed at your expense over several.

Prevent the repeat

Keep a copy of your DNS records before any website work. A screenshot is enough, and it turns a diagnosis into a comparison.

Tell whoever is doing website work that mail runs on the same domain, explicitly, before they start. Not everyone asks.

Do not let the domain’s own address be the recovery address for the domain account, because a domain problem then prevents you receiving the notice about the domain problem.

Keep business email independent of website hosting, so that moving one does not move the other.

What to do next

If mail is down now, ask the two questions at the top: did the website stop too, and did anything happen to the website recently. Between them they route this correctly in under a minute. Keeping DNS and renewals monitored is a standing item in an ongoing arrangement, which is on website maintenance cost.