Home /Getting Started /Best Practices
Update DNS Records
Most migration projects require access to DNS records to perform importantmailbox migration related tasks:
- Validate your domain in the target tenant
- Perform the Cutover (update mail routing)
- Authenticate mail delivery
Depending on your setup and mail delivery habits, it’s possible your projectwill require updating several DNS records. The timing and sequence of changesmay vary depending on your mail routing requirements and transitional goals. Youwill need access to your DNS name server or registrar account to make theseupdates.
DNS Validation
Cloud-hosted services may require proof of domain ownership in the form of a DNSrecord containing a unique assigned value. Often this involves adding a TXTrecord while validating the domain on your target tenant. Once validated, youcan assign email addresses within that domain. In most cases you’ll validatedomains before creating user accounts, but in some cases (most often whenmigrating between tenants of the same provider, i.e. Microsoft 365 toMicrosoft 365) domain validation must be delayed until mail cutover.
MX Records
Mail Exchanger records identify the servers to which mail addressed to yourdomain should be delivered. These records will be updated at cutover timeaccording to instructions from your mail provider or with the IP address of yournew mail server.
If you are using a separate mail filtering service, your cutover may requiremodifying that service’s configuration rather than changing the MX recordsthemselves. In that scenario, you should review your service’s instructions inadvance of cutover.
Reducing DNS TTL
The DNS TTL property specifies how long it can be safely cached. It is specifiedin seconds so a value of 3600 would call for a 1-hour cache duration and 86400indicates a full day between cache refresh lookups. At least 24 hours prior tocutover 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 TTLmay not guarantee prompt updates.
Autodiscover
Autodiscover records are used by Microsoft mail clients (i.e. Outlook) to easilyidentify their mail server. These are CNAME records whose values should be setaccording to instructions available after you validate your domain. In mostcases you should set your Autodiscover record prior to cutover by at least aday, or often even earlier.
SPF Records
Sender Policy Framework (SPF) uses DNS TXT records to identify servers thatshould be trusted to send mail for your domain. Most cloud-hosted mail providerswill provide guidance on how to configure your SPF records for their service. Ifyou prefer to set only a single allowed sender, you may replace your existingSPF record at cutover time with the value suggested by your provider.Alternatively, you can update the SPF record so that both your source and targetmail systems are valid in advance of cutover. In the latter scenario, you’llwant to remove the source servers after cutover is complete.
DKIM Selectors
Domain Keys Identified Mail (DKIM) is a system that allows mail servers toauthenticate more securely than SPF alone. By sharing your public keys over DNS,your mail server can be uniquely identified by its private key. Your mailprovider will have instructions on how to enable DKIM message signing and shareyour public key via DKIM Selectors. The selector will typically be a TXT orCNAME 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 respectto DKIM signature compliance. If your migration scenario requires delaying DNSvalidation until cutover time, you may want to ensure your DMARC policy is notset to “none” rather than “reject” prior to cutover. After cutover is completeand DKIM message signing is enabled, you can return your DMARC policy to yourpreferred level.