MX Records

This article explores MX records, detailing their structure and role in email delivery. When you reply to an email—for example, one sent from a cochla.com address using your Gmail account—several behind-the-scenes steps occur:

1. Since your email is hosted by Gmail, Google selects a Gmail mail server for SMTP delivery.
2. The Gmail server performs a DNS query for the MX records of the cochla.com domain to locate the appropriate mail servers.
3. Once the MX records are returned, the server with the highest priority (lower number) is chosen, and an A record lookup is performed to fetch its IP address.
4. The email is then delivered to that IP address.

In the Domain Name System (DNS), MX records are essential because they point to mail servers, ensuring your email messages are delivered correctly.

Anatomy of an MX Record

An MX record is composed of several components:

• Domain Name: The domain you own and manage.
• TTL (Time to Live): For instance, "300" seconds means DNS servers cache the record for 5 minutes before checking for updates.
• IN: Indicates the Internet class, a standard for modern DNS records.
• MX: Specifies that the record is a mail exchange record.
• Priority: Numerical values (e.g., 1, 5, 10) indicate the order of preference. Lower values mean higher priority.
• Mail Server Hostname: A valid SMTP server hostname that will receive email for the domain.

Consider this example MX record entry:

kodekloud.com. 300 IN MX 10 alt3.aspmx.l.google.com.

This record directs emails destined for kodekloud.com to the mail server at alt3.aspmx.l.google.com. It is crucial that this mail server's hostname resolves to an A (or AAAA) record, allowing it to be reached.

Most domain registrars such as Cloudflare, Route 53, or GoDaddy offer user-friendly interfaces to add MX records. Simply navigate to your DNS settings, select the MX record type, and provide the appropriate priority and mail server hostname.

MX Record Priority and Redundancy

Email systems rely on MX record priorities to choose the optimal mail server for delivery. For example, running the query for kodekloud.com's MX records may return the following:

$ dig kodekloud.com MX
;; DiG 9.10.6 ;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64585
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;kodekloud.com.             IN      MX

;; ANSWER SECTION:
kodekloud.com.      300     IN      MX      10 alt3.aspmx.l.google.com.
kodekloud.com.      300     IN      MX      10 alt4.aspmx.l.google.com.
kodekloud.com.      300     IN      MX      5 alt2.aspmx.l.google.com.
kodekloud.com.      300     IN      MX      5 alt1.aspmx.l.google.com.
kodekloud.com.      300     IN      MX      1 aspmx.l.google.com.

;; ADDITIONAL SECTION:
alt1.aspmx.l.google.com. 129 IN A 142.250.152.27

;; Query time: 187 msec
;; SERVER: 2806:10:cfff:0:e::e
;; WHEN: Sat Feb 01 22:04:02 CST 2025
;; MSG SIZE  rcvd: 173

Here, the mail server with priority 1 (aspmx.l.google.com) is attempted first. If it is unreachable, servers with priority 5 are used next, followed by the servers with priority 10. When multiple MX records share the same priority, email delivery is distributed in a load-balanced manner:

sample.com. 300 IN MX 10 ms1.aspmx.l.google.com.
sample.com. 300 IN MX 10 ms2.aspmx.l.google.com.

Email Security and Authentication Protocols

Security in email communications is critical. Without proper configurations, attackers could intercept emails or spoof sender addresses. Modern email systems utilize three key protocols to enhance security:

SPF (Sender Policy Framework)

SPF uses TXT records to specify which mail servers are authorized to send emails on behalf of your domain. For example:

example.com. 300 IN TXT "v=spf1 include:_spf.google.com ip4:192.168.1.10 -all"

When an email is received, the recipient's mail server checks the SPF record to verify that the sending server is permitted to send emails from the domain.

DKIM (DomainKeys Identified Mail)

DKIM adds a unique digital signature to each outgoing email. This signature is created using a private key held by your mail server, while the corresponding public key is published in a TXT record within your DNS:

default._domainkey.example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgCQA4JICUYrYG/UjtGhK4PIZx0Ii8zWfgLeE1Slc14jL91Raja9m8F6D2DyqMB+xrIrHR/2xCXgNWEFw0fqQmWGRcpxdBlvAkCu9oHzqiDnXEBg98PUN9x7yFqoVuTAFM6H0Uv5ChCwbmXXn2mwQFu..."

Receiving servers use this public key to validate the digital signature, ensuring the email content remains unchanged during transit.

DMARC (Domain-Based Message Authentication, Reporting, and Conformance)

DMARC policies work in conjunction with SPF and DKIM. They are also stored as TXT records and instruct receiving servers on how to handle emails that fail authentication checks. Actions can include rejecting, quarantining, or simply reporting the non-compliant emails:

_dmarc.example.com. 300 IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100"

Integrating SPF, DKIM, and DMARC creates a robust framework that significantly reduces the risk of email spoofing and phishing attacks.

When these protocols are properly configured, they make it considerably more difficult for attackers to spoof emails or use your domain for phishing attacks.