How to Fix Your Domain Email Landing in Spam After a Host Move

Your mail is landing in spam after a host move because the receiving side no longer has the evidence it used to have that your domain is allowed to send. That evidence lives in DNS and in the headers of every message, and moving hosts changes both. The fix is to re-establish that evidence and prove it with the checks below, in the order a receiving mail server evaluates them.

People search for answers about email deliverability after moving hosting and usually start at the spam filter. Start earlier, at the envelope and the headers. The receiving server decides whether to trust you long before a content filter looks at the words in the body.

Why a host move breaks email deliverability

When mail leaves your new host, it goes out from a different IP address and possibly a different hostname than before. The receiving server checks whether that IP is authorised to send for your domain. That authorisation is published in DNS as SPF, and it is checked against the envelope sender, the address in MAIL FROM, not the From: header the reader sees. If your SPF record still lists only the old host, or lists nothing at all, the new sending IP fails the check.

DKIM is the second problem. Your old host may have signed outgoing mail with a key whose public half was published at selector._domainkey.yourdomain. The new host either signs with a different selector, signs with nothing, or expects you to publish a key it generated. A signature that cannot be verified is worse than no signature, because a receiver that sees a DKIM header it cannot validate may treat the message as suspect.

DMARC ties the two together. It tells receivers what to do when SPF and DKIM both fail to align with your From: domain. If you had a DMARC record with an enforcing policy and the move broke alignment, you have effectively instructed receivers to distrust your own mail.

There is a fourth cause that has nothing to do with authentication. If the move changed your outbound path, your sending IP may have no reputation at the receiver, or a poor one if it is shared with other senders. Reputation is earned over time and cannot be configured, but you can at least confirm that the IP you now send from is the one your records describe.

Check what your domain actually publishes

Before changing anything, read the current state. Query the records a receiver will query. Use whichever resolver tool you have; the output shape matters more than the tool.

dig +short TXT yourdomain.example
dig +short TXT _dmarc.yourdomain.example
dig +short TXT selector._domainkey.yourdomain.example
dig +short MX yourdomain.example

You are looking for three things. An SPF record beginning v=spf1 that includes a mechanism covering your new sender. A DMARC record beginning v=DMARC1. And a DKIM public key at the selector your new host told you to use. If the DKIM query returns nothing, the selector is wrong or the record was never published.

Then check what your mail server is really sending. Send a message to a mailbox you control elsewhere and read the full headers. Every authentication result a receiver computed is stamped into the message as it is delivered.

Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=yourdomain.example;
  dkim=pass header.d=yourdomain.example header.s=selector;
  dmarc=pass header.from=yourdomain.example

If you see spf=softfail or spf=fail, the envelope sender is not covered by your record. If dkim is missing entirely, your new host is not signing. If dmarc=fail, neither SPF nor DKIM aligned with the From: domain, and that is the single most common reason mail from a freshly moved domain goes to spam.

Fix SPF without breaking other senders

SPF is a single TXT record per domain. You cannot publish two; a second one causes a permanent error. So edit the existing record rather than adding a new one. Add an include: for your new provider and remove the one for the old host only once you are sure nothing else sends through it. Keep the record under the lookup limit, because each include:, a, mx and ptr mechanism costs a DNS lookup and receivers stop evaluating past the limit.

Watch the all qualifier at the end. A record ending in -all tells receivers to reject anything not listed, which is the right end state but a harsh one to publish while you are still inventorying senders. A ~all softfail gives you room to find what you missed. Move to -all after the headers show pass on everything legitimate.

Remember that SPF checks the envelope sender. If your application sends mail through a third party that rewrites the envelope to its own domain, SPF for your domain is not the constraint; DMARC alignment is, and that is what DKIM is for.

Get DKIM signing and alignment right

Ask your new host which selector it signs with, publish the public key it gives you at selector._domainkey.yourdomain, and confirm the private key is actually in use by reading the headers of a test message. The s= value in the signature must match the selector you published. A mismatch is silent: the signature exists, the record exists, and they never meet.

Alignment is the subtle part. DMARC requires that the domain in the DKIM d= tag match the From: domain, or that the SPF envelope domain match it. A provider that signs with its own domain passes DKIM at the receiver but does not pass DMARC for you. If your provider insists on signing as itself, that is a reason to look at how it handles custom domains, not something you can patch in DNS.

Roll out DMARC gradually and watch the reports

Publish DMARC at _dmarc.yourdomain with a reporting address and a permissive policy first, then enforce once the reports are clean.

v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r

The rua address receives aggregate reports, which are XML summaries of what receivers saw. Read them. They tell you which IPs sent as your domain, whether they passed SPF and DKIM, and whether they aligned. This is how you discover a forgotten sender before you tighten the policy. When every source in the reports shows aligned passes, change p=none to p=quarantine and later to p=reject.

Do not skip the reporting step and go straight to reject. That is how a host move turns into silent mail loss instead of spam placement, and lost mail is harder to notice than filtered mail.

Check the things that are not authentication

Reverse DNS is still worth verifying. Query the IP your new host sends from and confirm the PTR record resolves to a hostname that forward-resolves to the same IP. Some receivers weight this heavily, particularly for small senders.

dig +short -x 192.0.2.10
dig +short mail.yourdomain.example

If the two do not agree, ask your provider to set the PTR. You usually cannot set it yourself; it belongs to whoever owns the address block.

Also confirm your From: domain and the domain in your Return-Path are consistent with what you published, that your MX records point at a host that accepts mail for the domain, and that any greylisting or rate limiting on the new outbound path is not causing retries that receivers read as suspicious. A burst of retried connections from a new IP looks like a compromised host to some filters.

What to do next

Work in the order above: read the headers of a real message first, because they tell you which of SPF, DKIM or DMARC is actually failing rather than which one you assume is failing. Fix the failing mechanism, retest, and only then tighten policy. Keep the DMARC reports flowing for a few weeks after the move so that any forgotten sender surfaces while the policy is still permissive, and keep a copy of your old DNS records so you can compare if delivery regresses.