Overview and Principles

The core challenge with any MX migration is the DNS propagation delay. When you change your MX records, it takes time — sometimes up to 48 hours, though often less — for sending servers around the internet to see the new values. During this window, some senders will use the old MX record and some will use the new one. If you simply swap the records and the new destination is not ready, mail that reaches the new MX before you are prepared can bounce or queue at the sending side.

The zero-downtime approach solves this by setting up the new path fully before cutting over any DNS, and by using DNS TTLs strategically to minimize the propagation window when you do make the switch. At no point during this process should mail be at risk of loss. The phases below are designed so that each one is reversible if something goes wrong.

Before you begin, make a note of your current MX records and their TTLs. You will need these for the rollback procedure.

Phase 1: Set Up and Test (No DNS Changes)

Create your Spam Killer account and add your domain. In the dashboard, configure the upstream server: this is the hostname or IP address of your existing mail server, along with the port (typically 25 or 587) and any TLS settings.

Do not change any DNS records yet. Instead, test the full pipeline by connecting directly to Spam Killer's SMTP endpoint using a mail client or command-line tool:

# Test a direct SMTP delivery to the proxy (bypassing DNS)
# Replace with your assigned proxy hostname
swaks --to you@yourdomain.com \
      --server inbound.spamkiller.io \
      --port 25 \
      --from test@yourdomain.com \
      --body "Direct SMTP test - no DNS change yet"

Check the Spam Killer dashboard to confirm the message was received, filtered, and forwarded to your upstream server. Check your upstream server's logs to confirm it received the message from the proxy IP address. If this works, the pipeline is functional end-to-end.

Rollback at this phase: Nothing has changed. There is nothing to roll back.

Phase 2: Lower Your MX TTL (24-48 Hours Before Cutover)

Log into your DNS provider and reduce the TTL on your existing MX records from whatever it currently is (often 3600 seconds or higher) down to 300 seconds (5 minutes). Do this 24 to 48 hours before your planned cutover. This is critical: the TTL reduction needs to propagate before you change the records themselves, so that when you do change the MX values, those changes propagate quickly.

If your current MX TTL is 86400 (24 hours), you must wait a full 24 hours after lowering the TTL before the cutover, or some servers may cache the old values for the full original TTL duration. If your TTL is already 3600 (one hour), waiting one hour after lowering it to 300 is sufficient.

# Example: current MX record in zone file before TTL reduction
yourdomain.com. 3600 IN MX 10 mail.yourserver.com.

# After TTL reduction (apply this change, wait 24-48 hours, then proceed)
yourdomain.com. 300  IN MX 10 mail.yourserver.com.

Rollback at this phase: Raise the TTL back to its original value. The MX destination has not changed, so mail delivery is unaffected.

Phase 3: Cutover — Add New MX, Keep Old MX Temporarily

This is the cutover step. Do not simply replace your old MX record — add the new one alongside it with a lower priority number (lower priority number = higher preference in MX semantics). This means senders who have already cached the old record will still deliver successfully, while new lookups will prefer the proxy.

# Add the new Spam Killer MX record with priority 5 (preferred)
yourdomain.com. 300 IN MX 5  inbound.spamkiller.io.

# Keep the old record temporarily with priority 20 (fallback)
yourdomain.com. 300 IN MX 20 mail.yourserver.com.

With this configuration, senders who look up your MX will use the proxy (priority 5). Senders who cached your old record before the change will deliver directly to your original server (priority 20 as a fallback, or directly if they have the old record cached). You have overlapping coverage during the propagation window.

Note: keeping the old MX record as a direct fallback means some mail will bypass the proxy briefly. This is intentional — the goal here is zero message loss, not immediate filtering coverage. You will remove the old record in Phase 5.

Rollback at this phase: Remove the new MX record pointing to the proxy. Raise the old MX record's priority back to 10. Mail will continue flowing to your original server normally.

Phase 4: Verify Delivery

After updating the DNS records, wait 10-15 minutes and then send test emails from a few different sources: your personal Gmail, a colleague's email on a different domain, and ideally a mail sender outside your country if possible. Different senders will have different DNS caches.

In the Spam Killer dashboard, watch the live log. You should see messages arriving from external senders, being filtered, and being forwarded to your upstream. Check the following:

  • Messages are arriving at the proxy (visible in the inbound log)
  • Messages are being forwarded and accepted by your upstream server (no forwarding errors)
  • Messages are appearing in the destination mailbox as expected
  • Reply-to and From headers are intact (the proxy should not modify these)

Check your upstream server's access logs to confirm the source IP of forwarded mail has changed from random internet IPs to the Spam Killer proxy IP range. This is important for Phase 5.

Rollback at this phase: Same as Phase 3. Remove the proxy MX record and restore the old record to priority 10. The old MX record is still present and will continue to work.

Phase 5: Lock Down and Clean Up

Once you have confirmed delivery is working correctly through the proxy for a period you are comfortable with (at minimum 30 minutes, ideally 24 hours), you can clean up the temporary setup.

First, remove the old MX record that points directly to your upstream server. Your DNS should now have only the Spam Killer MX record:

yourdomain.com. 300 IN MX 5 inbound.spamkiller.io.

Second — and this is important for security — configure your upstream mail server to only accept SMTP connections from Spam Killer's proxy IP addresses. Without this step, spammers who find your upstream server's hostname or IP directly can bypass your filtering entirely.

In Postfix, this is done via the mynetworks setting or an IP-based restriction in smtpd_client_restrictions. In Exchange, configure the Receive Connector to only accept from the proxy IP range. The specific proxy IP addresses are listed in your Spam Killer dashboard under Settings → Proxy IPs.

# Example Postfix smtpd restriction to only accept from proxy IPs
# In /etc/postfix/main.cf:
smtpd_client_restrictions =
  permit_mynetworks,
  check_client_access cidr:/etc/postfix/proxy_ips.cidr,
  reject

Finally, raise your MX TTL back to a normal value (3600 or higher) now that the migration is complete. A low TTL causes unnecessary DNS traffic and slightly increases lookup latency for every sender.

If Things Go Wrong: Troubleshooting Table

Symptom Likely Cause Action
Proxy receives mail but forwarding fails with 5xx error Upstream server rejecting the proxy IP Temporarily allow the proxy IP on your upstream server; check firewall rules
Proxy receives mail but forwarding fails with 4xx error Upstream server temporarily unavailable or overloaded Proxy will retry; check upstream server health; messages will not be lost
Test emails do not arrive at proxy at all DNS not yet propagated to sender's resolver Wait; check DNS propagation tools; the old MX fallback is still live
Mail arrives at proxy but spam filter is too aggressive Threshold misconfigured for your traffic Lower the spam score threshold; whitelist known-good senders temporarily
Greylisting is deferring mail from important senders New senders hit the greylist on first attempt Whitelist the sender in Spam Killer; they will retry within minutes