You moved your email, it works for most people, and then a client says your messages bounce or land in spam. After a switch this almost always comes down to the records that prove the mail is yours. Check these five in order; the first two cover most cases.
1. Your SPF record still names the old host
SPF is the TXT record that lists who may send for your domain. After a move it often still lists only the old provider, or there are now two SPF records, one old and one new. Two SPF records is an error in itself, so receivers treat both as failing. Gmail answers with 550 5.7.27, "This message was blocked because it didn't pass SPF authentication", or with the softer 421 4.7.27, which delays rather than rejects.
The fix is one record that starts with v=spf1, includes the new host, and includes anything else that still sends for you, such as a newsletter tool or your website's contact form. Remove the old host only once nothing sends through it any more.
v=spf1 include:_spf.newhost.example include:newsletter-tool.example ~all2. DKIM was never published at the new host
DKIM signs each message with a key whose public half lives in your DNS. Your old host's key does not move with you; the new host gives you its own record, usually a TXT or CNAME at a name like selector._domainkey. If it was skipped, messages arrive unsigned. With SPF also broken, Gmail returns 550 5.7.26: "This email has been blocked because the sender is unauthenticated."
Publish the DKIM record your new host shows, wait for it to resolve, and send a test to a Gmail address. In Gmail, Show original should read DKIM: PASS with your domain.
3. DMARC is strict and something still fails alignment
DMARC tells receivers what to do when SPF and DKIM do not line up with the From address. If you had p=reject at the old host and the new host is not fully authenticated yet, every message that fails is refused outright. That is DMARC working as designed, and it is why the first two steps come first.
If you are mid-move and unsure, set p=none for a week, fix SPF and DKIM, read the reports, then put the policy back. Our free DMARC checker shows what your record currently says.
4. Something else still sends as your domain
A switch moves the mailboxes, not the other things that send as you: a website contact form that logs in to the old host's SMTP, an invoicing tool, a CRM, a printer that emails scans. When the old account closes, those start failing; when it does not, they send from a host your new SPF no longer lists.
Make a list from your own Sent folders and from the senders in your DMARC reports, then either point each one at the new host's SMTP settings or add its sender to SPF and DKIM.
5. The new sending IP has a reputation problem
If every record passes and one provider still files you as spam, the cause is reputation, either the host's sending IPs or your domain's history. Cheap hosts share IPs between many customers, so one bad neighbour affects everyone until the host acts. Gmail's 421 4.7.28, "Gmail has detected an unusual rate of email", is the rate-limit version of the same problem.
Ask the host whether its IPs are listed anywhere, check your domain in Google Postmaster Tools, and keep sending normal, expected mail. If the host shrugs, that is useful information about the host. Faivelo watches its sending infrastructure and pauses senders who misbehave, so one customer's campaign does not decide another's inbox placement.
Check all five at once
The free email checkup reads your MX, SPF, DKIM and DMARC records and tells you which one is wrong, in plain language. If you have the bounce message, paste its code into the SMTP error code lookup; if you have a delivered message in someone's spam folder, the header analyzer shows which check failed.
After a move, assume the records are wrong until a Gmail test says DKIM: PASS.
FAQs
How long after switching should mail settle?
Records take effect as fast as their TTL allows, often minutes and at most a day or two. If bounces continue after 48 hours, a record is wrong rather than slow.
Can I have two SPF records during the move?
No. Two records starting with v=spf1 is a permanent error and receivers treat SPF as failing. Merge them into one record with both includes.
Do I need DMARC?
For ordinary volumes Gmail requires SPF or DKIM; at 5,000 messages a day to Gmail it also requires DMARC. Publishing at least p=none is good practice for everyone, because it gets you reports.
Will Faivelo set these records for me?
At most registrars, yes: connect the registrar and Faivelo places MX, SPF, DKIM and DMARC, then keeps checking them. Elsewhere it shows each record with a copy button.
Let the records be someone else's job
Faivelo writes your MX, SPF, DKIM and DMARC at the registrar, keeps checking them, and tells you in plain words when one drifts. Fourteen days free, no card.