ISSUE:
We are moving our server stack to a new colocation with a different IP range. Other than obvious corporate things like spam and virus update servers (for our established base of modusGate and modusMail clients), it also will affect our clients currently residing on nospam.vircom.com for their spam filtering.
DEADLINE:
We plan on doing the move no later than July 24th. That means you need to prepare your domain or your client's domains for the new mail routing. If we get confirmation from all clients on nospam early enough, we may opt to dot the flip earlier.
IMPLICATIONS:
The IP addresses the new nospam servers will be:
nospam1.vircom.com ip:69.172.217.51
nospam2.vircom.com ip:69.172.217.52
What you need to do is:
1. Inbound port 25 traffic to your MTA
Make sure you have your clients setup to accept SMTP traffic (port 25) to their primary MTAs if originating from those two IP addresses. Better yet, if you can allow the whole class C (69.172.217.0/24) so much the better as it will give us more flexibility if we have to change the public IPs of these machines.
2. Inbound LDAP/GC traffic to your DC
Make sure you also have the same IPs allowed for LDAP (port 389) or global catalog (port 3268) assuming you or your clients are using active directory for the user population part.
3. Inbound lockdown rules (Office365)
If your clients are on office365 - if you implemented some sort of lockdown rule for inbound SMTP traffic, you will need to add our class C to the allowed IPs (69.172.217.0/24).
4. SPF tuning
If you route email outbound through nospam.vircom.com (or nospam1+nospam2) .. make sure you add this to your SPF: include:_spf.hosted.vircom.com
5. SMARTHOST change
When we do the cutover -- if you route your outbound mail through nospam.vircom.com, you will need to adjust your smarthost settings to use the new IP address (69.172.217.51) if you don't use the smarthost by name (nospam.vircom.com) or better yet, just change the smarthost to use the nospam.vircom.com A record as the sending server since we'll be doing the change in DNS at cutover time.