Knowledge Base

How to set up DNS records properly for a migration


How to set up DNS records for a source and target domains, to make the cross-domain migration flawless.


Please be aware that steps below are for cross-domain migration and assume both domains should be resolvable in public DNS records. This is the case, for example, when you are migrating to a different forest with a different domain or to a different domain in the same forest but in different site. There are many possible migration scenarios - see a description of some of them in CodeTwo Exchange Migration user's manual. Please review the whole article below before you start applying any changes.

The bottom line is that you must be able to connect to the target server from within source server environment using target server's FQDN (check that by pinging the target server using its FQDN). For this to be possible, the following should be verified and amended, if necessary:


Proper public DNS records for both source and target domain

First, please ensure that appropriate A NS CNAME record is set for both source and target domain in public DNS by checking with your domain registrar:

  • If a domain should point directly to your server, add an A record with IP address of the server.
  • If you wish to create non-direct association, so domain points to some name servers, which in turn return IP address of the server, add NS records with addresses of name servers
  • If your domain is an alias of some other domain, please add a valid CNAME record with name of the primary domain.

Be advised that such changes needs to be propagated over the Internet. In the worst case scenario you may need to wait up to 48 hours for the process to complete, depending on TTL property of the DNS entries.

Source server local DNS records match to public DNS records

If you are running a local DNS server, please compare the information reported by your DNS server (e.g. using nslookup command) with any public service that is able to read DNS records (such as website). If there is inconsistency, you have to resolve all differences before going further. To discover these differences, you can follow the steps below:

  1. Open the MXtoolbox DNS Lookup website.
  2. Check the domain in question and write down the results.
  3. On a machine where CodeTwo software is installed, open command line prompt (cmd).
  4. Execute the following command, providing the desired domain and address of your DNS server:
    #In the example below server localhost is asked about domain1.example domain
    nslookup -q=a domain1.example localhost
  5. Compare the result from step 2.

Source server local DNS A and SRV records adjustment

If the source machine is unable to resolve the FQDN of target server (e.g. using ping command) despite other steps from this article being done, that means you also have to add and SRV records to the source DNS. To add the A entries you will need the IP addresses of the target Exchange server and target Domain Controllers. However, the SRV records need to be read directly from the target DNS Manager:

  1. Head to the machine on the target environment, which runs the DNS role.
  2. Open DNS Manager.
  3. Expand Forward Lookup Zones/<your domain>/_tcp.
  4. Note down all records with all their values.

Once you have sufficient information about target environment, you can add the records to the source DNS server:

  1. Head to the machine on the source environment, which runs the DNS role.
  2. Open the DNS Manager.
  3. Right-click Forward Lookup Zones and choose New Zone...
  4. Select Primary Zone and your preference of data replication.
  5. As the Zone name set target domain, e.g. domain1.lab.
  6. Complete the wizard.
  7. Choose the newly created zone from the tree.
  8. Add Host (A) entries for the target Exchange server and target Domain Controllers.
  9. Now you can begin to provide the SRV records. For every record noted previously:
    1. Right-click the right pane.
    2. Choose Other New Records...
    3. Select Service Location (SRV).
    4. Hit Create Record...
    5. Use the information noted down previously to fill the requested fields.
  10. Last but not least, on the machine that runs the migration software, run the following command as an administrator:
    ipconfig /flushdns

From now on, you should be able to connect to the target server. Although, if the solution does not work for you, it may be a good idea to setup a trust relationship between source and target domain.

In the case there is still no connectivity via FQDN, but you are able to ping your target server via IP address you can still migrate with CodeTwo software. However, the configuration will be more difficult e.g. you will not be able to list target server mailboxes and automatch them with source mailboxes.

Office 365 DNS records

If you have an Office 365 subscription, but the domain is not managed directly on Office 365, please double check whether following records are present in DNS configuration of your domain. The following entries are important from the application point of view, since they enable proper behavior of Autodiscover. More information about setting up domains you may find in Office 365 documentation.


Please be aware that every record have its own Time To Live (TTL) property. After changing the records you have to wait the chosen amount of seconds before going further. Therefore, for the records shown above you have to wait an hour since there are 3600 seconds.

MX records

Changes made to the MX records of your domain should not affect behavior of our software. However, all NS CNAME records must not be modified, since after such a change, the software may attempt to contact inappropriate server. 

Was this information useful?