How to Keep Your Emails Out of Spam When You Use a New Host

To avoid email spam on a new web host, you must verify that your domain's authentication records are published and that your mail server presents a valid, matching identity for every message it sends. Spam filters score mail by checking SPF, DKIM, and DMARC, and a brand new host almost always breaks at least one of these checks because its IP addresses and hostnames differ from your old setup. The moment you switch DNS to point at the new server, run the checks below before you send a single campaign or transactional email.

Why a New Host Trips Spam Filters

When you change hosts, your outgoing mail now originates from an IP address that has no history on your domain. Reputation is built per IP, not per domain, so the new IP starts cold. More importantly, your DNS records still describe the old host. SPF records list allowed sending IPs, DKIM records hold a public key that signs your mail, and DMARC tells receivers what to do if SPF or DKIM fail. If any of those records point to the old server, your new mail fails authentication and lands in spam or gets rejected outright.

Your new host will give you a dedicated IP and a hostname for your mail server, plus a DKIM selector and public key. You must update three DNS records: an TXT record for SPF, a TXT record for DMARC, and a CNAME or TXT record for DKIM depending on your provider. The exact names and values are in your host's control panel or setup documentation. Do not copy values from your old host, they are tied to the old IP and key.

Check SPF Before You Send

SPF (Sender Policy Framework) tells receiving servers which IP addresses are allowed to send mail for your domain. Your SPF record is a TXT record at the root of your domain, for example example.com. It should list only your new host's IP or its include mechanism. A typical record looks like this:

v=spf1 ip4:203.0.113.10 include:_spf.newhost.example.net ~all

The ~all at the end means soft fail, which is safer for testing. Once you confirm everything works, you can change it to -all for a hard fail. To test, run a DNS query from your terminal:

dig TXT example.com +short
"v=spf1 ip4:203.0.113.10 include:_spf.newhost.example.net ~all"

If you see your old host's IP or an old include in that output, your mail will fail SPF. Remove those entries. Also check that the IP in your SPF record matches the IP your new host assigned to you, not a shared IP. Many budget hosts put you on a shared IP, and if that shared IP has a poor reputation, your mail suffers even with perfect SPF. Ask your host for a dedicated IP if they offer one, because shared IP reputation is outside your control.

Verify DKIM Signing and DNS

DKIM (DomainKeys Identified Mail) uses a private key on your mail server to sign each message's headers and body. The public key lives in a DNS TXT record under a selector name. Your new host gives you a selector, often something like default or mail, and the full record name is selector._domainkey.example.com. The record value is a long string starting with v=DKIM1; k=rsa; p= followed by the base64 public key.

After you add that record, confirm the DNS propagation and then send a test email to a mailbox you control. Inspect the raw headers of that message, look for the DKIM-Signature header. It should contain d=example.com and s=selector. Then run a verification command on the received message, for example with opendkim-testmsg or a mail client that shows authentication results. A passing result looks like this in the headers:

Authentication-Results: mx.google.com;
       dkim=pass [email protected] header.s=selector
       spf=pass [email protected]

If you see dkim=fail or dkim=neutral, the public key in DNS does not match the private key on your mail server. Double check the selector name, because a typo in the domain key record is the most common cause. Also verify that your mail server is actually signing outgoing messages, some hosts require you to enable DKIM signing in the mail server config, often in postfix/main.cf or exim.conf with a line like dkim_selector = selector.

Set Up DMARC and Watch for Failures

DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells receivers what to do when SPF and DKIM both fail. Without DMARC, many receivers silently drop or spam your mail. Start with a monitoring policy, not a reject policy. A DMARC record is a TXT record at _dmarc.example.com and looks like this:

v=DMARC1; p=none; rua=mailto:[email protected]; fo=1

The p=none means receivers should not reject mail, only send you aggregate reports to the rua address. Set up a mailbox that can receive those reports, then wait a few days. Look for reports showing failures from your new host's IP. If you see SPF failures, your SPF record is wrong. If you see DKIM failures, your key or selector is wrong. Once reports show no failures for a week, tighten the policy to p=quarantine and later to p=reject.

Do not skip DMARC because you think SPF and DKIM are enough. Modern filters treat missing DMARC as a negative signal, especially for domains that previously had a DMARC record. Check your old DNS history, use a tool like dig on a DNS archive, and replicate the old policy if you had one. If you never had DMARC, start with p=none and be patient.

Check Reverse DNS and Hostname Matching

Reverse DNS (PTR record) maps your IP back to a hostname. Receiving servers check that the hostname in your message's EHLO command matches the PTR record for your sending IP. Your new host must assign a PTR record that resolves to a hostname like mail.example.com, not something generic. Ask your host to set the PTR, because you cannot create a PTR record in your own DNS, only your IP provider can.

Then configure your mail server to use that same hostname in its EHLO greeting. In Postfix, set myhostname = mail.example.com in main.cf. In Exim, set primary_hostname. Verify the match with a command that queries the PTR and then test the greeting:

dig -x 203.0.113.10 +short
mail.example.com.

If the PTR returns a hostname that does not match your EHLO, or if the PTR is missing, your mail will get flagged for lack of identity. Also check that the hostname resolves forward to the same IP, a broken forward-confirmed reverse DNS (FCrDNS) is a common spam signal. Fix any mismatch before you send mail to customers.

What to Do Next

After you update SPF, DKIM, DMARC, and PTR, send test messages to multiple inboxes, including Gmail, Outlook, and a small provider. Watch the raw headers for authentication results, then send a low volume of real mail and monitor your DMARC reports for a week. If any record is wrong, fix it and wait for DNS propagation to finish, which can take hours. Do not ramp up volume until every test passes, because a burst of unauthenticated mail from a new IP can poison your reputation before you have a chance to correct the records.