Contents
Summary: MX Records holds important information regarding the mail servers that route the emails to their destination. In this blog, we have explained MX Records in great detail. Starting from the format of MX Records to how the MX Records work, we have explained everything. From checking discrepancies in email headers to data collection from additional sources, we have described how MX Records helps in the Forensic Investigation of Emails.
An MX Record or Mail Exchange Record is a type of Domain Name System (DNS) record that points to the mail server responsible for handling email for a given domain. It defines how email messages will be routed in line with the Simple Mail Transfer Protocol (SMTP).
The primary purpose of MX Records is to ensure that emails are sent to the correct destination address. MX records are a vital part of a working email system. They can play an essential role in the forensic analysis of email.
MX Record Format
The standard format of an MX Record includes [name] [TTL] [class] [type] [priority] [rdata]. This is an example of MX record:
google.com. 3600 IN MX 0 alt3.aspmx.l.google.com
- name: The first field contains the domain name.
- TTL: It stands for Time To Live, which defines the period (in seconds) for which the email client can retain MX record information in its cache memory. In the above example, it is 3600, which translates to 60 minutes or one hour. So, a client can keep this MX record information in its cache for one hour. If this time lapses, then it must again fetch the record from the name server. The name server is the server that stores DNS records.
- class: The Class field specifies the type of network. It is always set to IN, which stands for Internet.
- type: The DNSrecord type. In this case, it is set to MX (for MX Records).
- priority: This field defines the mail server?s priority. The lower the value of this field, the higher is the mail server?s priority. When there are multiple servers for the same domain, this field establishes the priority order of the servers. In the above example, the priority of the mail server is set to 0 which is the highest priority.
- rdata: This is a resource data field that defines the name of the mail server. In the above example, the rdata field is alt3.aspmx.l.google.com, which means all emails for the domain google.com will be delivered to alt3.aspmx.l.google.com.
How do MX Records Work?
Whenever you send an email message, your Mail Transfer Agent (MTA) accesses the MX record of the receiver?s domain name. It then tries sending the email to the mail server with the highest priority in the record. If delivery fails, it retries with the remaining mail servers in the record in their increasing preference order until the message is delivered.
How to Fetch MX Records?
Finding MX records is easy. On a Windows system, you can use the nslookup command-line tool. You can run the following script in command prompt (CMD) to find the MX records for the domain google.com:
nslookup -type=MX google.com
This will provide you with a non-authoritative answer to the query.
Figure 1 highlights the non-authoritative answer for the google.com domain. A non-authoritative answer means the answer is not fetched from the authoritative DNS server for the queried domain name.
A DNS system is divided into three tiers:
- root DNS servers
- top-level domain DNS servers
- authoritative DNS servers
There?s another DNS server class, usually called local DNS server, whose IP address is specified in your operating system.
When your browser connects to a website such as google.com, the browser first queries the local DNS server to get the IP address of the website.
- If the local DNS server doesn?t have the record, i.e., a record of google.com, it will query one of the root DNS servers.
- The root DNS server would say, ?I don?t have a record of google.com, but I know the top-level domain DNS server responsible for .com domains?.
- Then the local DNS server queries the top-level domain DNS server responsible for .com domains. The top-level domain DNS server would respond as: ?I don?t know, but I know which DNS server is authoritative for google.com?.
- Now, the local DNS server queries the authoritative DNS server. Since the actual DNS record is stored on that authoritative DNS server, it will give the local DNS server an answer.
This query result gets cached on the local DNS server but can get outdated. When the [TTL] time expires, the local DNS server will update the query result from the authoritative DNS server. Therefore, whenever you query a DNS record on the local DNS server, it returns a non-authoritative answer. You need to specify the authoritative DNS server while using nslookup or other utilities to get an authoritative answer. A local DNS server can also be called a caching DNS server.
You can use the following command to find the primary name server of the domain:
nslookup -type=soa google.com
Now that you have the name of the primary name server, which is ns1.google.com, you can run the following command to get an authoritative answer:
nslookup -type=mx google.com ns1.google.com
The command gives you the most up-to-date information about the domain including the internet addresses and IPv6 addresses of the mail servers that are used.
If you don?t want to use CMD, you can also fetch MX records of domains with web services, such as DNSChecker and MXToolbox.
Role of MX Records in Email Forensics
MX records can help in forensic analysis of emails in the following ways:
1. Check Discrepancies in Email Headers
An email header contains important information, such as details of sender and receiver, hops, etc., which help track the message’s journey. So, when you analyze an email, you can check if the details in the header match the MX records of the domain.
Suppose you are analyzing an email that was sent a few years back. If you find that the email service provider mentioned in the email header is one that the target domain switched to only recently, it can be considered a red flag. In this situation, you can investigate further to get more information about the discrepancy and find smoking guns.
2. Data Collection from Additional Sources
A change in MX records doesn’t necessarily mean that the email service provider was changed. Sometimes, domain owners use additional services to improve email security or archive emails. When this happens, the MX records may show the details of these servers as they work on top of existing email servers. In other words, the emails go through these additional servers first and then to the primary email servers.
Looking up a domain’s historical MX records can help you discover additional data collection sources. For instance, if you find out that a domain is using an archival service in addition to the primary email servers, then the archival service may have backup files that you can collect and scan for additional data.
Conclusion
In email forensics, fetching MX Records for a domain name can be helpful in many ways. For example, it can help verify that the recipient of an email used the correct email service provider. It can also help in checking if the owner of a domain changed their service provider and lead you to additional sources for data collection.
Need an advanced eDiscovery and email forensics software that is user-friendly and offers a wide range of valuable features? Try Stellar Email Forensic! It supports more than 25 email file formats such as PST, EDB, OST, DBX, NSF, MBOX, OLM, TBB, EML, etc. In addition, this software makes email analysis easy with features such as preservation of evidence with MD5 and SHA1 hash values, bulk analysis of emails, deleted email recovery, tagging and bookmarking, log management, and much more. Download Stellar Email Forensic now. It is available for a free 60-day trial.
