Email Deliverability After a Migration (SPF, DKIM, PTR)

When you migrate, your server’s sending IP changes — and email systems judge legitimacy partly by the sending IP and the records that vouch for it. To keep your mail landing in inboxes rather than spam after a move, three records deserve attention: SPF, DKIM, and PTR. This guide explains each.

Why a move can affect deliverability

Mail servers check whether the IP sending your mail is authorised to do so, whether the message is cryptographically signed, and whether the IP’s reverse DNS matches. After a migration your IP is new, so the records tied to the old IP need updating to reflect the new one. Skip this and legitimate mail can be flagged.

SPF — authorising the new server

Your SPF record lists which servers are allowed to send mail for your domain. After migrating, update it to include iWebVault’s sending server (and remove the old host if it no longer sends for you). An out-of-date SPF that doesn’t include the new server is a common cause of post-migration spam-foldering.

DKIM — signing your mail

DKIM adds a cryptographic signature proving your mail wasn’t tampered with and genuinely comes from your domain. The signing happens on the sending server, with a matching public key in your DNS. After migrating, ensure DKIM is enabled on iWebVault and the corresponding DNS record is in place for your domain.

PTR / reverse DNS — the IP’s identity

A PTR record is the reverse lookup of your sending IP back to a hostname. Mail systems distrust IPs with missing or mismatched PTR. This is set on the IP itself — which iWebVault controls — so we configure PTR for your sending IP. You don’t set this one, but it’s worth knowing it’s handled.

Verifying after cutover

1. Send a test email to a mailbox you control on a major provider
2. Check it arrives in the inbox, not spam
3. Use the message’s headers (or a mail-tester tool) to confirm SPF and DKIM pass
4. If mail still lands in spam, re-check SPF includes iWebVault and DKIM is signing

The mechanics of why mail can falter after a move

Receiving mail servers fight spam by checking several signals about the sending server. Three matter most: does the domain’s SPF record authorise this sending IP; is the message DKIM-signed with a key that matches the domain’s published key; and does the sending IP have a PTR record that resolves back to a sensible hostname. A migration changes your IP, so the records tied to the old IP need refreshing for the new one — or these checks start failing.

Updating SPF

SPF is a DNS record listing authorised senders for your domain. After migrating, edit it to include iWebVault’s sending server and drop the old host if it no longer sends for you. A stale SPF that omits your new server is the single most common reason migrated mail suddenly lands in spam, so this is the first thing to fix.

Confirming DKIM

DKIM signs your outgoing mail and publishes a matching public key in your DNS. Ensure DKIM is enabled for your domain on iWebVault and that the corresponding DNS record is present. With valid DKIM, receiving servers can confirm your mail genuinely came from your domain and wasn’t altered in transit — a strong positive signal.

PTR / reverse DNS

PTR is the reverse of an A record: it maps the sending IP back to a hostname. Mail systems distrust IPs whose PTR is missing or mismatched. Because PTR is set on the IP itself, iWebVault configures it for your sending IP — you don’t set this one, but it’s part of why mail from iWebVault is trusted.

Verifying deliverability

1. Send a test email to an address on a major provider you control
2. Confirm it lands in the inbox, not spam
3. Inspect headers or use a mail-tester to confirm SPF and DKIM pass
4. If it’s spam-foldered, re-check SPF includes iWebVault and DKIM signs

What’s next

• Keeping Email Flowing During a Migration
• Migrating Email-Only Accounts
• Verifying a Migration Was Fully Successful

Still stuck? Our team can run or finish the migration for you — open a support ticket and we’ll take it from there.

Key takeaways

A migration changes your sending IP, so update SPF to authorise iWebVault’s server, confirm DKIM is signing your mail, and rely on iWebVault to set PTR on the sending IP. Test by sending to a major provider and checking it lands in the inbox with SPF and DKIM passing. Ramp bulk sending gradually from the new IP to build reputation.

Why is my mail going to spam after the move?

Most often a stale SPF record that doesn’t include your new iWebVault sending server. Update SPF to authorise the new server (and drop the old host if it no longer sends for you), confirm DKIM is signing, and re-test. Those two DNS fixes resolve the majority of post-migration spam-foldering.

Common mistakes to avoid

• Leaving an old SPF record that doesn’t include the new sending server
• Assuming DKIM carried over without checking it’s signing on iWebVault
• Blasting your whole mailing list on day one from a fresh IP
• Ignoring spam-foldering as ‘just how it is’ instead of fixing the records

Deliverability after a move comes down to telling receiving servers your new server is legitimate: SPF authorises it, DKIM signs for it, and PTR identifies it. Update SPF and confirm DKIM yourself, let iWebVault handle PTR, ramp volume gradually, and test — and your mail keeps reaching inboxes through the move.