Home / Getting Started / Best Practices

Update DNS Records

Most migration projects require access to DNS records to perform important mailbox migration related tasks:

  1. Validate your domain in the target tenant
  2. Perform the Cutover (update mail routing)
  3. Authenticate mail delivery

Depending on your setup and mail delivery habits, it’s possible your project will require updating several DNS records. The timing and sequence of changes may vary depending on your mail routing requirements and transitional goals. You will need access to your DNS name server or registrar account to make these updates.

DNS Validation

Cloud-hosted services may require proof of domain ownership in the form of a DNS record containing a unique assigned value. Often this involves adding a TXT record while validating the domain on your target tenant. Once validated, you can assign email addresses within that domain. In most cases you’ll validate domains before creating user accounts, but in some cases (most often when migrating between tenants of the same provider, i.e. Microsoft 365 to Microsoft 365) domain validation must be delayed until mail cutover.

MX Records

Mail Exchanger records identify the servers to which mail addressed to your domain should be delivered. These records will be updated at cutover time according to instructions from your mail provider or with the IP address of your new mail server.

If you are using a separate mail filtering service, your cutover may require modifying that service’s configuration rather than changing the MX records themselves. In that scenario, you should review your service’s instructions in advance of cutover.

Reducing DNS TTL

The DNS TTL property specifies how long it can be safely cached. It is specified in seconds so a value of 3600 would call for a 1-hour cache duration and 86400 indicates a full day between cache refresh lookups. At least 24 hours prior to cutover you should reduce the TTL value on MX records to not more than 600. After cutover is complete you can return TTL values to their original states.

Note that some registrars may be slower to update than others so reducing TTL may not guarantee prompt updates.

Autodiscover

Autodiscover records are used by Microsoft mail clients (i.e. Outlook) to easily identify their mail server. These are CNAME records whose values should be set according to instructions available after you validate your domain. In most cases you should set your Autodiscover record prior to cutover by at least a day, or often even earlier.

SPF Records

Sender Policy Framework (SPF) uses DNS TXT records to identify servers that should be trusted to send mail for your domain. Most cloud-hosted mail providers will provide guidance on how to configure your SPF records for their service. If you prefer to set only a single allowed sender, you may replace your existing SPF record at cutover time with the value suggested by your provider. Alternatively, you can update the SPF record so that both your source and target mail systems are valid in advance of cutover. In the latter scenario, you’ll want to remove the source servers after cutover is complete.

DKIM Selectors

Domain Keys Identified Mail (DKIM) is a PKI-based system that allows mail servers to authenticate more securely than SPF alone. By sharing your public keys over DNS, your mail server can be uniquely identified by its private key. Your mail provider will have instructions on how to enable DKIM message signing and share your public key via DKIM Selectors. The selector will typically be a TXT or CNAME record and can be configured after your DNS validation is complete.

DMARC Records

DMARC stands for Domain-based Message Authentication, Reporting & Conformance. These records establish a policy for how your mail is to be handled with respect to DKIM signature compliance. If your migration scenario requires delaying DNS validation until cutover time, you may want to ensure your DMARC policy is not set to “none” rather than “reject” prior to cutover. After cutover is complete and DKIM message signing is enabled, you can return your DMARC policy to your preferred level.