Every now and then I get a question relating to running an Exchange server on an internet connection that only has a dynamic public IP address available. This is most common when people are running an Exchange Server test environment at home with a residential, consumer-grade internet connection. But it also comes up occasionally for businesses running on those types of internet connections.
There’s three challenges that present themselves here:
- Inbound connections to the server such as OWA (HTTPS) or incoming email (SMTP) will stop working if the dynamic IP changes and the DNS records for your external URLs (such as the OWA URL) and MX records aren’t updated to the new IP address
- Outbound mail flow from a dynamic IP will often be blocked due to IP reputation issues or spam block lists
- Outbound mail flow will often be blocked by the ISP not allowing outbound SMTP connections from dynamic IP ranges
Each of those has a solution and depending on your circumstances you may be able to solve them all, but I know that in some cases the problems are not able to be overcome. But let’s take a look at the solutions anyway.
Inbound Connections to a Dynamic Public IP Address
First, the inbound connections. If you’re trying to learn about Exchange Server then having inbound connectivity to services such as Outlook Anywhere, OWA, and ActiveSync is helpful, and so is being able to establish inbound mail flow or to set up a Hybrid configuration with Office 365.
The solution I use for dynamic IP addresses is to sign up with a dynamic DNS provider. There are a variety of providers out there, some are free and some are paid. You can shop around and choose one you’re comfortable with. Most recently I used No-IP who have a free option.
I set up a free hostname similar to “mytestlab.no-ip.org”. My DSL router includes a feature that will automatically update No-IP with my new public IP address each time it changes (as an alternative, they provide a client that you can install to handle this). If my IP doesn’t change for 30 days then I simply click a link in an email that No-IP sends me to re-confirm that I am using the hostname. If you want to avoid that 30 day confirmation process their paid plans are very inexpensive, and you can even use them to host your own domain name.
However, I don’t use that free hostname for my Exchange namespaces. Instead, I set up my Exchange namespaces (such as “mail.exchange2013demo.com”) as CNAME records in DNS that alias to the “mytestlab.no-ip.org” hostname. This allows me to still acquire SSL certificates for my Exchange server because I am the owner of exchange2013demo.com, whereas I am not the owner of no-ip.org and therefore can’t buy SSL certificates for hostnames in that domain.
The same applies to my MX records. I configure normal MX records, for example mail.exchange2013demo.com, and alias that to the no-ip.org hostname.
So inbound connections to an Exchange Server on a dynamic public IP can work by using:
- A dynamic DNS provider
- A DSL router that supports the dynamic DNS provider, or the provider’s downloadable client software
- CNAME records in DNS for my namespaces and MX records that alias to the dynamic hostname
I have not encountered any issues with the above solution so it should work for test environments or real production environments, though I generally wouldn’t recommend it for production environments.
Outbound Connections from a Dynamic Public IP Address
Outbound connections tend to be more troublesome because there are two common issues. But the solution for both is the same, it just depends whether your ISP supports it.
At the heart of the issue is how untrustworthy the dynamic IP address ranges for residential/consumer ISPs are, given their history of residential computers being compromised and used as botnets to spread spam, malware, or DDoS attacks. Any email sent from such an IP address is likely to be junked or blocked entirely during the initialization of the SMTP connection.
Another factor is that many ISPs block outbound SMTP connections from their customers to the internet at large, only allowing them to specific hosts such as the ISP’s own SMTP servers.
While this isn’t a big deal for a test lab that just wants to send some test messages, it is nice to see that your outbound email actually works, so if you can get around it with minimal effort then it’s worth it.
The basic solution is to configure your outgoing email to use the ISP server as a smart host.
If your ISP does not provide a smart host, and offers no way to request an exception to the rules, then you may be out of luck. I have seen some people get around this using a VPN tunnel and a smart host service, so all is not lost, but it makes things more complex overall.
If you’re trying to set up a Hybrid with Office 365 things become a bit harder. Although the Hybrid configuration itself can be set up, you’re likely to have your Hybrid mail flow from on-prem to the cloud rejected due to your dynamic IP address. You can request that the IP address be unblocked by Microsoft, which they’ll generally do without any problems, but the next time your dynamic IP address changes you could be blocked again. Still, for the sake of learning how Hybrid configurations are set up you may only need it working for a few days while you do your testing.
Summary
Those are my tips for running an Exchange Server on a dynamic IP address. They mostly apply to test environments. If you’re trying to run a production system on a dynamic IP you can expect some other concerns to arise, particularly around mail flow and things like managing SPF records, as well as optimizing your DNS record TTLs so that there is no lengthy disruption every time your IP address changes. So for production your mileage may vary, but for testing it is perfectly fine.
If you’ve got any additional tips you want to share with people from your own experience running Exchange on a dynamic IP address please leave a comment below.
Thank you for your great article, but this wont help I guess if the ISP we are trying to create test lab used shared public ip and it does not point directly to the client machine.
Please correct me if I am wrong
Hello Paul,
Thank you for the article.
Just want to check if we have two sites A and B. Site A has a static IP and Site B has Dynamic.
Can we have two records and mx records? One is A record which points to mail- static IP and other A record points to dynamic DNS hostname? Also one MX record to mail.example.com priority 10 and another MX record pointing to DynamicDNS hostname with priority 20?
This will be for site resilency kind of a approach?
Thank you
Hi Paul!
Firewall is OK now – I can close a telnet connection on my mail.domain.ca 443 (I open it on my ISP router and also, I set up a NAT port on my VMWare).
I’m getting the following error when I try to create the Endpoint:
We couldn’t detect your server settings. Please enter them. AutoDiscover failed with a configuration error: The migration service failed to detect the migration endpoint using the Autodiscover service
Sorry for asking a lot of question but I don’t have much experience with Exchange 🙂
Well, I guess we are almost there.
Actually, I think this message is more accurate:
There was no endpoint listening at net.tcp://server.domain.ca/Microsoft.Exchange.MailboxReplicationService that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
The Real Person!
The Real Person!
I can’t support you like this here in the comments. I don’t know what type of migration you’re trying to do, what guidance you’ve followed to this point, or what preparation steps you’ve already performed. There’s more to a migration than just opening firewall ports though. So I recommend you take a few steps back and do some research into the process you should be following for your scenario.
Paul, thank you for sharing this article with us! It’s really usefull!
I have a question, when you say: “provider’s downloadable client software”, what do you mean?
I already have and Hybrid environment (Exchange 2016 on premise + Office 365) e I’m trying to create an Endpoint Migration to move some mailbox from on premise to cloud but I get an error (FQDN) because my Exchange is not published.
Using No-IP, I create already my CNAME and the name resolution is already OK!
Now, is only missing the part of por redirection but I IPS’s router doen’t support DDNS.
Is there some workaround I can do?
The Real Person!
The Real Person!
Some dynamic DNS providers have a client you can download and install on a PC on your network to update the DNS records if your public IP changes.
Oh yeah, I made a download of DUC (from NO-IP). All IP changes it updates automatically.
I’m trying to figure out how to configure my router to accept Dynamic DNS and port forward. These steps are essentials, right? I mean, there’s no any workaround to make it works if my IPS’s router doens’t support DDNS?
The Real Person!
The Real Person!
If your router supports dynamic DNS it would be able to update DynDNS with your new IP any time it changes. If not, you’d download the client software to install on a PC in your network to handle that.
Other than that, it should just be a matter of setting up the NAT/port forward on your router to forward the HTTPS and/or SMTP traffic to your Exchange server.
Thanks Paul.
Ok, I can ping mail.domain.ca so, 1st part is ok – but I still cannot create and Endpoint Migration (FQDN still not accepting my mail.domain.ca).
Now, maybe is missing some port/NAT set up.
In this case (for lab propose), I need only 443?
As I’m using a VM, I think I have to configure some NAT options on my VMware too.
Any suggestion?
The Real Person!
The Real Person!
The firewall requirements for migrations are documented by Microsoft on TechNet if you need to know exact details. Yes you’ll need to open 443 to get migrations working. How exactly that is done will depend on your router and network set up. You can use the exrca.com tool to test any firewall changes you make.
Been doing this for years without issue, for outbound yes use smarthost custom port if required and add your isp to your spf records.
I have successfully setup my Exchange Server to send and receive without issues using NOIP as per Pauls directions, I use a smarthost for sending and I think everyone should checkout -Mandrillapp. “You can send up to 12,000 emails per month absolutely free. If you need to send more than 12,000 emails a month or want access to paid features, upgrade your Mandrill account. We build discounts into our payment structure, so your per-email pricing automatically decreases as you send more email. Learn how monthly billing works”. I also pay about 20 US Dollars a year to use my own domain name on NOIP which makes my setup work easily without to much configuration, meaning The cname point to my Exchange server rather than a noip name
Additionally, in case you don’t want to buy a SAN.UC certificate since it is only a lab: https://ezoltan.wordpress.com/2014/03/16/how-to-use-a-free-ssl-certificate-for-exchange-testing/
part of the problem is inability to register a ‘proper’ ptr that matches your dynamic ip(only isp can do that)
and that makes your dynamic ip be listed as ‘blacklisted’ by
SORBS DUHL
Spamhaus ZEN
which many companies and security tools use(including 365)
Regarding inbound connection:
To use a CNAME record pointing to MX resource is not recommended.
See RFC2181 section 10.3 (…Part of the value of a MX resource record must not be an alias).
If you have your own registered company with you can register with sendgrid, and send all smtp traffic to them, for free for small amounts of traffic (i.e. testing)
I did that but you’ll find that your outbound mail gets ‘sent as’ unless you pay for a higher level account. Spark post mail has a free account, however, let’s you send 10k a month so great for labs.
Fyi with smarthost you miss the internal mail headers in hybrid scenario.