Migrating SMTP e-mail from my ISP’s servers to an internally-hosted Exchange server

This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Over the last couple of days, I migrated my e-mail service to Microsoft Exchange Server. I’ve been meaning to do this since I first bought my own domain name in the late 1990s but a lack of suitable hardware to dedicate to the task has meant that until now it’s been easier to leave the service with my ISP and download it to Outlook using POP3. Using virtualisation technology has enabled me to build an e-mail infrastructure without using any extra hardware.

Phase 1 of the project was installing the mail service and connecting to my ISP’s servers. I wanted to use Microsoft Exchange Server 2003 but for various reasons I didn’t want to extend the schema for my Active Directory (AD), so I created a separate resource forest with an outgoing trust to the original domain and installed Exchange Server there. Following this, I was able to create disabled user accounts and associate the mailboxes with external accounts in the original forest, allowing me to authenticate to my mailbox in the resource forest using my normal account credentials from the original domain (as described in Marc Grote’s article on the MSExchange.org site, although assigning the external associated account is now much simplified using the Exchange Task wizard).

Next, I needed to tell my ISP’s servers to allow messages for my domain to be routed to my server. The ADSL connection that I use is not associated with my domain but it does have a static IP address (an alternative is to use a dynamic DNS service), so after opening up TCP port 25 on the firewall to allow inbound SMTP traffic I created two DNS records for each domain that I own:

  • Host (A) record to define a server name that resolves to my IP address.
  • Mail exchanger (MX) record for the domain that resolves to the A record created previously.

With the appropriate DNS records in place, that was all the configuration needed at the ISP’s end, but Exchange still needed to be configured to forward e-mail to the ISP’s SMTP relay – easily accomplished using the Exchange Server 2003 Internet Mail Wizard. The important thing to be sure of is that the server is not configured as an open relay (recent versions of Exchange Server lock this down by default). Once the SMTP connection was in place, e-mail started to flow (although for a while some mail was still being delivered to my ISP’s servers until the DNS entries had completely propagated around the Internet).

DNS Stuff is a mine of useful information, so I ran a DNS report on my domain name. This turned up various warnings about my ISP’s DNS configuration (which I can’t really do much about) but also a warning that my server’s SMTP greeting included an non-existent host name (the internal DNS name for the Exchange server):

220 hostname.internaldnsdomainname Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830 ready at Thu, 25 May 2006 12:30:31 +0100

According to the warning, if the server sends e-mail using a non-existent host name in its EHLO or HELO, e-mail could be blocked by anti-spam software, as well as being a technical violation of RFC 821 section 4.3 and RFC 2821 section 4.3.1.

A spot of Googling turned up a forum post on changing the SMTP greeting which pointed me in the direction of Microsoft knowledge base article 266686, allowing me to change the fully qualified domain name for the SMTP virtual server so that the SMTP greeting now reads as follows:

220 mailserver.domainname Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830 ready at Thu, 25 May 2006 13:18:44 +0100

Note that the hostname given in the SMTP greeting doesn’t have to be precise – it doesn’t matter that the SMTP server may handle e-mail for multiple domains (as mine does), as long as the host name given resolves to the correct IP address.

Phase 2 of the project will be to configure the intelligent message filter for Exchange Server 2003 (included as part of Exchange Server 2003 service pack 2) and hopefully cut out most of the spam that I receive (as the volume of spam hitting my server is much greater than the previous levels which were mostly handled by the Outlook junk e-mail filter). I’ll also be looking at enabling RPC over HTTP (see Microsoft knowledge base article 833401) to allow Outlook to access my mail servers using HTTP from behind my employer’s firewall.

7 thoughts on “Migrating SMTP e-mail from my ISP’s servers to an internally-hosted Exchange server

  1. One thing that I overlooked on the migration was the number of e-mail addresses that I’ve used over the years.

    As my ISP allows me to use anyone@domainname, any address sent to my domain has worked in the past but now that I have a certain number of defined mailboxes I need to make sure that all the addresses I actually want to use (except those that are simply auto-forwarded from another mail server) are configured for a mailbox on the Exchange Server (or else the recipient will receive a non-delivery report).

    I’ve probably accidentally bounced a few e-mails over the last couple of days (hopefully nothing too important) but think I’ve got all the addresses that I want to use configured now.

  2. Hi,

    I too am trying to achieve the same result, but I want email from 2 different domains to be forwarded to on mail box, do you know how I would set that up ?

    Dave

  3. Dave,
    You need the MX record for each domain to point to the Exchange Server server, then you will assign multiple SMTP e-mail addresses to the mailbox (in fact, that’s what I do too). One SMTP address will be the primary address – you will probably want to make sure that is from the domain which the virtual SMTP server reports itself as belonging to (and make sure that the IP address resolves in DNS to the virtual SMTP server name to avoid problems with sender verification).

    If you need each domain name to be primary, then I believe (but have not tested) that you will need to create a second virtual SMTP server for the second domain, with it’s own IP address. I don’t know how you would handle mail from both domains being routed to a single mailbox in that scenario.

    Mark

  4. Mark, Dave
    If you are handling mail for multiple domains…
    1) You need to add the UPN Suffixes in AD (RIGHT Click ib AD Domains And Trusts –> Properties)
    2) Add the domains for which you are accepting email in this box
    3) For your users – Make sure that when you set them up you choose the correct UPN suffix i.e. user1@domain1.com and user2@domain2.com etc
    4) Be sure to configure your recipient policies for each domain
    – this will ensure that when you create a user with UPN suffix domain1.com they will get the proper email addresses assigned… this will save you time in the long run since you will not have to edit the email addresses assigned.

    Mark – for the spam – one thing that has helped me with my server – has not totally wiped out spam but a great deal of it…
    Exchange –>Global Settings–>Message Delivery –> Properties–> Connection Filtering
    Run a google search for a listing of block list providers…
    I am using (sbl-xbl.spamhaus.org,relays.ordb.org,list.dsbl.org, blackholes.wirehub.net,bl.spamcop.net,relays.visi.com)

    Hope that helps you guys… I am in the process of upgrading to xch 2007… 2003 has served me and my domains very well.

  5. Andrew,
    Thanks for that advice… I’ll dig around in my configuration and make sure that I’ve applied all those settings (I use the Spamhaus realtime block lists now and, combined with the Exchange IMF, they have made a real difference).

    Goog luck with your migration to 2007 – I’m still on 2003 as don’t have any 64-bit hardware available; although I was one of the first in the UK (outside Microsoft) to receive Exchange Server 12 training (it hadn’t been formally named 2007 then) back in April 2006 so I’m looking forward to putting that to good use soon.

    Cheers, Mark

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.