Email stopped arriving after Cloudflare: what to check, in order

It is the most common incident in the whole move to Cloudflare, and it has a recognisable signature: the website is fine — better than fine, it is faster than before — and the email is dead. No visible error, no warning. Simply nothing arriving, and people writing to the company get a bounce or, worse, nothing at all.

The cause is nearly always one of the two below, and either one is repaired in half an hour.

Why it happens

When you change nameservers, the DNS zone does not move: it gets rebuilt. Cloudflare tries to read the existing one and copy it, but it can only copy what the previous provider exposes publicly, and some panels expose less than they hold.

From that moment on, the world asks Cloudflare where the company's mail lives. If Cloudflare does not have that record, the answer is "there isn't one". It is not a fault: it is an incomplete zone answering confidently.

Check 1: are the MX records there?

That is the first thing to look at, before any theory.

The DNS zone on Cloudflare must show the same MX records that existed before the switch, with the same priorities. If you use Google Workspace or Microsoft 365, those records are documented by the provider and can be copied from there. If you use your host's mail, the record points at one of their hosts and has to be recovered from the old panel, not reconstructed from memory.

Two frequent mistakes here:

• a secondary MX is missing entirely. Mail then works intermittently, which is worse than not working, because nobody can see a pattern;
• the record points at the domain instead of the mail host. It looks right and is not: mail.yourdomain.com and yourdomain.com are two different names, and the second usually leads to the website.

Check 2: the orange cloud

This is the more insidious mistake, because the zone looks correct.

In Cloudflare every record carries a cloud icon. Orange means "traffic passes through us": Cloudflare answers on behalf of your server and hides its IP address. Grey means "just answer", which is ordinary DNS.

The orange proxy is designed for web traffic. On anything else it does damage:

• the record your MX points at must be grey. If mail.yourdomain.com is orange, the world receives a Cloudflare address, which is not a mail server. No delivery;
• subdomains used by external services must be grey: webmail, control panels, integration endpoints, the record your business system sends through;
• TXT and authentication records have no cloud, but still need checking: SPF, DKIM keys and the DMARC record are TXT records, and they are exactly the ones a partial import loses.

Rule of thumb: orange only on what serves a web page. Everything else grey.

Check 3: what the import always loses

Beyond MX records and cloud icons, a rebuilt zone is nearly always missing these. Go through them one by one:

• the SPF record, without which outgoing mail starts landing in spam within hours;
• the DKIM keys, which live on unintuitive subdomains nobody remembers;
• the DMARC record, if there was one;
• verification TXT records for Google, Microsoft, Search Console and the like: their absence breaks nothing immediately, but one day a service "unverifies" itself and nobody connects the cause;
• the autodiscover record or automatic mail-client settings, without which Outlook stops configuring itself;
• CNAMEs for external services: newsletter, invoicing, shipment tracking.

How to repair it now

1. Recover the old zone. If the previous panel is still reachable, export it. If it is not, records can be queried one at a time, and public DNS history helps.
2. Compare it line by line with the current zone on Cloudflare. Not by eye: side by side.
3. Put the MX records back with their original priorities, and switch to grey everything that is not web.
4. Verify with a real send, from an outside address into the company and back out. Automated tests tell you whether a record exists; only an email tells you whether it arrives.
5. Wait for propagation, which depends on the TTLs set before the switch. If they were high it will take longer than expected — which is why they are lowered before a migration, not after.

What about mail sent while it was broken?

That depends on who sent it. A serious mail server does not throw a message away on the first failed attempt: it queues it and retries for days. So a good share of the mail arrives on its own once the records are back.

What does not come back are messages that were permanently rejected and those sent by systems that never retry — web forms, automated notifications, some invoicing platforms. For those it is worth telling your main contacts rather than hoping.

How not to get here

Moving to Cloudflare is a good idea: fast DNS, managed HTTPS, cache and protection included. The idea is not the problem, the sequence is.

The order that does no damage: export the zone, lower the TTLs a day ahead, rebuild and compare, grey out everything that is not web, change the nameservers outside working hours, and test the mail immediately afterwards, not the next day.

If the mail is down right now and you would rather somebody looked at the zone than guessed at it, that is exactly what Cloudflare setup and support is for — and if the problem turns out to run deeper than the switch, it continues on business email.