Email landing in spam after moving to Cloudflare: checklist to get emails back to 'Inbox'

After moving the site to a new hosting and transferring DNS to Cloudflare, transactional emails — registration confirmations, notifications, password resets — suddenly start landing in "Spam." Before the move, everything arrived in "Inbox." Sound familiar? Let's break down step-by-step why this happens and how to fix it — this is a ready-to-use checklist that can be completed in 20-30 minutes.

Why This Happens

In most cases, the reason is one: during zone import into Cloudflare, mail authentication records are moved "as they were" — along with the old host. Automatic DNS import (and AI assistants that increasingly help with migration) transfer records "one-to-one" and do not reassemble SPF for the new sender. The site works externally, but email quietly breaks — emails are sent but land in spam, and no one notices for weeks.

A classic example: the root SPF remains v=spf1 include:_spf.old-hoster.com ~all, even though emails are now actually sent by a different service — Amazon SES, Resend, SendGrid, or Postmark. The domain "allows" the old host, but not the actual sender. Gmail sees SPF: fail or softfail and sends the email to spam, even if the content is perfectly legitimate.

Step 1. Diagnose (Don't Guess)

• Send a test email to mail-tester.com — the service provides a one-time address and shows a report with a score out of 10 and a breakdown of each record.
• In Gmail, open the email → click the "⋮" menu → "Show original." Find three lines: SPF, DKIM, DMARC. All three should be PASS.

If at least one is fail / softfail — the problem is with DNS, not the email content. Continue with the checklist.

Step 2. DNS Records Checklist

Everything is corrected in Cloudflare → DNS → Records:

• SPF (domain root). Must authorize the REAL sender. For Amazon SES / Resend, it's v=spf1 include:amazonses.com ~all. ⚠️ There can only be one v=spf1 record per domain — if there are two, both become invalid. If emails are sent both via an external service and from your mailbox — combine everything into one line using include:.
• DKIM. A selector record (e.g., resend._domainkey) must be present. This is a cryptographic signature that the mail service uses to confirm that the email is genuinely from you and has not been forged.
• DMARC. _dmarc record. For a new domain, it's okay to start with p=none (monitoring only); after warming up, raise it to p=quarantine.
• MX and return-path. Must point to your sending/receiving provider, not the old host.
• PTR (reverse record, rDNS). Relevant only if you send emails from your own SMTP server — the reverse record of the IP must match the server's name.
• Remove old host's junk. A broken root MX, a stale old DKIM selector, extra include: in SPF — a common cause that is forgotten after migration.

The main rule: after ANY DNS transfer, run a mail check separately. Zone import copies records "as they were," and "as they were" is the old provider's configuration.

Step 3. If Emails HAVE Already Been Going to Spam

You've fixed the DNS, but old emails are already in "Spam," and the mail client has "remembered" the domain as suspicious. Help it reconsider its decision:

• Go to your Google Mail (Gmail), open an email from the "Spam" folder → click the "Not spam" button. This is the strongest signal at the account level: Gmail will review the sender's reputation faster and start placing its emails in "Inbox."
• Ask the first recipients to do the same — a few "Not spam" marks from real people will speed things up significantly.

Step 4. Consider the "New Domain" Factor

If the domain was registered recently, it still lacks history and reputation. Even with perfectly configured SPF, DKIM, and DMARC, some emails may still land in spam initially — and this is expected; it's no longer about DNS.

• Warm up the domain: start with small sending volumes and gradually increase, not "a thousand emails on the first day."
• Monitor complaints and unsubscribes — sharp spikes damage reputation.
• "Not spam" marks from real recipients at this stage warm up the domain the fastest.

You fix DNS once, and then reputation is built by volume and recipient behavior.

Step 5. Check the Result

• Repeat the test on mail-tester.com → aim for 10/10.
• In the email headers (Gmail → "Show original"): SPF: PASS, DKIM: PASS, DMARC: PASS.
• A test email arrives in "Inbox," not "Spam."

Conclusion

Emails going to spam after migration are almost never "magic," but rather the SPF transferred from the old host, which doesn't authorize the new sender (a common side effect of automatic and AI DNS migration to Cloudflare). The treatment algorithm: reassemble SPF for the actual sender → check DKIM, DMARC, MX → clean up old host's junk → test on mail-tester → if emails have already gone to spam, mark "Not spam" manually → for a new domain, add warm-up. Go through this checklist once — and emails will consistently return to "Inbox."