Skip to main content

There is no denying that MX records are an important part of digital life. They are one of the first things we set up when we register a domain name, and they specify how email messages destined to that domain should be routed. Yet, in my experience, MX records are rarely reviewed as part of digital forensics investigations.

We have recently done some work on MX records while developing Forensic Email Collector. So, I figured it was time to write a post on what MX records are, and how they can be useful during a digital forensics investigation.

What Are MX Records?

MX Records (also known as Mail Exchanger or Mail Exchange Records) are a basic element in the Domain Name System (DNS). Specifically, they are a type of DNS resource record. RFC 1035 contains detailed information on DNS, and lists other resource record types such as A records, NS records, CNAME records and TXT records.

The data format for an MX record is as follows:

Preference
16-bit integer that indicates the preference given to this MX record. Lower values have higher preference.
Exchange
Domain name that specifies a host willing to act as a mail exchange for the domain.

When we compose and send an email message, the Mail Transfer Agent (MTA) queries the MX records for each recipient’s domain name. It then tries to transmit the message starting with the mail exchange server with the lowest preference value (i.e., highest priority, most preferred) for each recipient domain. If the transmission is not successful, other mail exchange servers with higher preference values (i.e., lower priority, less preferred) are tried in increasing preference value order.

Servers with higher preference values are usually backup mail exchange servers. In the event that the primary server is unavailable, the backup servers accept the transmission and keep messages in queue until the primary server becomes available.

How Can We Query MX Records?

There are numerous ways to query MX records for a domain. Here are a few examples:

Nslookup (Windows)

On a Windows system, you can use Nslookup to query MX records for a domain as follows:

nslookup -type=MX google.com

You can use the following query to get the primary name server for a domain:

nslookup -type=soa google.com

You can then use that name server for an authoritative answer as follows:

nslookup -type=mx google.com ns1.google.com

This currently returns:

Server: ns1.google.com
Address: 216.239.32.10

google.com MX preference = 10, mail exchanger = aspmx.l.google.com
google.com MX preference = 30, mail exchanger = alt2.aspmx.l.google.com
google.com MX preference = 20, mail exchanger = alt1.aspmx.l.google.com
google.com MX preference = 50, mail exchanger = alt4.aspmx.l.google.com
google.com MX preference = 40, mail exchanger = alt3.aspmx.l.google.com
aspmx.l.google.com internet address = 173.194.202.27
aspmx.l.google.com AAAA IPv6 address = 2607:f8b0:400e:c04::1a
alt2.aspmx.l.google.com internet address = 173.194.219.27
alt2.aspmx.l.google.com AAAA IPv6 address = 2607:f8b0:4002:c03::1a
alt1.aspmx.l.google.com internet address = 74.125.201.27
alt1.aspmx.l.google.com AAAA IPv6 address = 2607:f8b0:4001:c01::1a
alt4.aspmx.l.google.com internet address = 173.194.215.27
alt4.aspmx.l.google.com AAAA IPv6 address = 2607:f8b0:400c:c0c::1a
alt3.aspmx.l.google.com internet address = 74.125.192.27
alt3.aspmx.l.google.com AAAA IPv6 address = 2607:f8b0:400d:c00::1b

dig (domain information groper) (Linux & MacOS)

On Linux or MacOS, you can use dig as follows:

dig google.com MX +noall +answer

When using dig, you can specify the DNS server to query as follows:

dig google.com MX @ns1.google.com +noall +answer

This currently returns:

; <<>> DiG 9.8.3-P1 <<>> google.com MX @ns1.google.com +noall +answer
;; global options: +cmd
google.com. 600 IN MX 40 alt3.aspmx.l.google.com.
google.com. 600 IN MX 30 alt2.aspmx.l.google.com.
google.com. 600 IN MX 50 alt4.aspmx.l.google.com.
google.com. 600 IN MX 20 alt1.aspmx.l.google.com.
google.com. 600 IN MX 10 aspmx.l.google.com.

Web Services

There are also various web services such as MX Toolbox and G Suite Dig which allow you to, among other things, query MX records of a domain.

DNSdumpster is a great DNS reconnaissance tool that can be used to gather useful information from an organization’s DNS records.

One of my favorite online services for querying DNS records is DNSTrails. In addition to querying current DNS records, it provides historical DNS records—including MX records—for a domain. We will see how this can be useful in the following paragraphs.

Using MX Records in Digital Forensics

We will now review a few scenarios where querying MX records for a domain can be useful:

Transport Header Mismatch

Email headers usually contain valuable information about, among other things, an email’s travel from the sender to the recipient. If you are authenticating an e-mail message, you would expect the email header to contain information that is consistent with the historical MX records of the domain at the time the message was transmitted.

Finding a mismatch such as the email header reflecting an email service provider who the owner of the target domain switched to years later should be treated as a red flag and requires further investigation.

Detecting Migrations

Querying historical Mail Exchanger records for a domain can also help detect if the owner of the target domain has changed email service providers during the time period of interest. If service providers have been changed while a legal hold was in effect, further scrutiny is usually in order. Changing providers usually involves archiving and migrating existing messages, which can result in changes to valuable metadata and even data loss.

Note that a change in Mail Exchanger records does not always indicate a migration. The owner of the domain might have started using an additional service for email security, archival or redundancy which acts as an additional layer before their existing email server.

In my opinion, switching email service providers should be postponed to the extent possible while litigation is reasonably anticipated. If changing providers is unavoidable, the best course of action usually involves extensive documentation, forensic preservation, and full disclosure.

Detecting Additional ESI Sources

Querying Mail Exchanger records may sometimes reveal additional sources of electronically stored information (ESI) that were not included in the data map. For example, you might find evidence that an email security and archival service was being used in addition to on-premises email servers.

This archival service may contain historical back-ups that can be extracted and used during digital forensics investigations and eDiscovery.

Email Preservation

Another use of Mail Exchanger records in the digital forensics context is during preservation. Before getting started with preserving email evidence from a cloud service, it is usually a good idea to check the MX records of the target domain to make sure that the information you have been provided regarding the email server is accurate.

List of MX Records for Popular Providers

In this section, I will maintain a list of MX records for popular email service providers. When reviewing historical MX records for a domain, this list can be used to map MX records to service providers.

ProviderMX Records
Aolmailin-01.mx.aol.com
mailin-02.mx.aol.com
mailin-03.mx.aol.com
mailin-04.mx.aol.com
GoDaddysmtp.secureserver.net
mailstore1.secureserver.net
GoogleASPMX.L.GOOGLE.COM
ALT1.ASPMX.L.GOOGLE.COM
ALT2.ASPMX.L.GOOGLE.COM
ALT3.ASPMX.L.GOOGLE.COM
ALT4.ASPMX.L.GOOGLE.COM
Mailfencesmtp1.mailfence.com
smtp2.mailfence.com
Mimecastus-smtp-inbound-1.mimecast.com
us-smtp-inbound-2.mimecast.com
Office 365<domain>.mail.protection.outlook.com
Postinidomainname.com.s7a1.psmtp.com
domainname.com.s7a2.psmtp.com
domainname.com.s7b1.psmtp.com
domainname.com.s7b2.psmtp.com
ProtonMailmail.protonmail.ch
Rackspacemx1.emailsrvr.com
mx2.emailsrvr.com
Yahoo Business Mailmx-biz.mail.am0.yahoodns.net
Yandexmx.yandex.net
Zohomx.zohomail.com
mx2.zohomail.com

Conclusion

Querying Mail Exchanger records is a quick and easy way to verify that an email’s header reflects the correct service provider used by the recipient at the time, and to detect whether or not the owner of a domain switched email service providers while a legal hold was in effect.

If you perform forensic email examinations, it is worthwhile to learn more about MX records and make it a small part of your workflow to query and review them.

References:

  • RFC 1035 | Domain Names – Implementation and Specification—https://tools.ietf.org/html/rfc1035