Both MX records and TXT records are related to email—what exactly do they do?

　　When setting up corporate email, many people encounter both MX records and TXT records on the DNS configuration page and easily conflate the two—thinking that since both relate to email, they should simply add them without distinction. This vague understanding causes no issues when the setup is correct, but if emails fail to send or end up in spam folders, one wouldn't know where to look for the problem.

　　MX records and TXT records serve completely different functions within an email system. To summarize: MX records determine "where the email is sent," while TXT records serve to "prove that I sent this email." The former acts as a delivery address, while the latter functions as an ID card and an anti-counterfeiting label.

　　Clarifying this distinction provides a clear direction for troubleshooting email issues later on.

　　MX Records: The "Street Address" of the Email System

　　Their Function

　　The role of an MX record is straightforward: it tells email servers worldwide which server should receive emails addressed to your domain.

　　When someone sends an email to `name@yourdomain.com`, the sender's mail server queries the MX records for `yourdomain.com`, identifies the specific mail server address you designated, and delivers the email there.

　　Without an MX record, your domain cannot receive emails. It is that simple.

　　Configuration Format

　　The DNS configuration for an MX record looks like this:

Priority  Mail Server Address
10      mx1.example.com
20      mx2.example.com

　　"Priority" is a field unique to MX records. A lower numerical value indicates higher priority; emails are delivered to the server with the highest priority first. In the example above, `mx1` is the primary server; emails are delivered to `mx2` only when `mx1` is unavailable.

　　This mechanism ensures redundancy within the email system—if the primary mail server goes down, the backup server can step in, preventing email loss.

　　A Common Misconception

　　Many people mistakenly believe that MX records can only point to subdomains of their own domain. In fact, an MX record can point to any domain name, including the servers of third-party email service providers. For instance, if you use Tencent Enterprise Mail, the MX record points to `mxbiz1.qq.com`; if you use Alibaba Cloud Enterprise Mail, it points to `mx1.mxhichina.com`.

　　This is the technical foundation that enables "hosted" enterprise email services: you don't need to set up your own mail server; you simply point your DNS MX record to the service provider, and emails are automatically routed into their systems.

　　TXT Records: The "ID Card" and "Anti-Counterfeiting Label" of Email Systems

　　TXT records are far more complex than MX records. Essentially, they are DNS records capable of holding arbitrary text—originally designed to give administrators "creative freedom." However, precisely because of this flexibility, major email service providers later adopted them for various verification purposes and policy declarations.

　　In the realm of email, TXT records primarily handle three tasks: SPF, DKIM, and DMARC. Together, these three components form the "anti-spam trio" of modern email systems.

　　The First Component: SPF—Declaring "Who Is Authorized to Send Email Using My Domain"

　　The function of SPF is to inform the recipient which servers are authorized to send emails on behalf of your domain.

　　Configuration example:

v=spf1 include:spf.mailprovider.com -all

　　Breaking it down: `v=spf1` identifies the protocol version; `include:spf.mailprovider.com` indicates that "this service provider's servers are authorized to send email on my behalf"; and `-all` signifies that "no other servers are permitted to send email on my behalf."

　　What happens without SPF? Others could easily spoof your domain to send emails, leaving recipients unable to distinguish the genuine from the fake. Your domain could be hijacked by spammers, causing your legitimate emails to be blacklisted as a result.

　　The Second Component: DKIM—Stamping Emails with an "Anti-Counterfeiting Seal"

　　The logic behind DKIM goes a step further than that of SPF. SPF focuses on "who is sending the email," whereas DKIM checks whether the email was tampered with during transit.

　　The mechanism works like this: the sending server applies a digital signature to the email header using a private key; the receiving server retrieves the public key via a DNS TXT record and uses it to verify the signature. If the signature matches, it confirms that the email originated from your server and remained unaltered along the way.

　　Configuration example:

selector._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

　　The "selector" allows a single domain to have multiple DKIM records for different email services or sending scenarios. The long string following `p=` is the public key.

　　The third component: DMARC—instructing the recipient on "what to do if verification fails."

　　DMARC acts as the "management layer" for SPF and DKIM. It does not participate directly in the verification process itself; instead, it tells the recipient how to handle the email if both SPF and DKIM checks fail.

　　Configuration example:

_dmarc.yourdomain.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com"

　　`p=quarantine` means "send emails that fail verification to the spam folder"; `p=reject` means "reject them outright"; and `p=none` means "take no action, just report." The `rua` parameter specifies the email address for receiving reports, allowing you to monitor your domain's email activity.

　　An added benefit of DMARC: it provides reports on who might be impersonating your domain. If a specific IP address is forging your domain to send mass emails, DMARC reports will alert you to this.

　　Let's tie it all together with a scenario: the complete lifecycle of an email from sending to receipt.

　　Suppose you send a price quote email to a client using `yourdomain.com`. The recipient's mail server performs the following checks:

　　Step 1: Check MX records. It locates the MX records for `yourdomain.com` to confirm that your mail server address is valid. This step verifies whether the recipient address actually exists.

　　Step 2: Check SPF records. It examines the SPF declaration within the TXT records for `yourdomain.com` to confirm whether the sending server's IP address is on the authorized list. This step verifies whether the sending server is authorized.

　　Step 3: Check DKIM records. Using the DKIM signature identifier in the email header, it queries the DNS for the corresponding public key to verify if the signature matches. This step verifies whether the email content has been tampered with.

　　Step 4: Check DMARC records. If either SPF or DKIM passes, DMARC is considered passed; if both fail, the email is handled according to the DMARC policy—whether to deliver it, send it to spam, or reject it.

　　Throughout this process, MX records determine "where the email is sent," while TXT records determine "whether the email is trustworthy." Both are essential, yet they serve completely different functions.

　　Summary: MX records handle "delivery destination," while TXT records handle "trustworthiness." If you configure MX records but not TXT records, the email may be delivered but is likely to be flagged as spam or a forgery; if you configure TXT records but not MX records, the system cannot find a delivery address at all. Only when both are properly configured does the email system function correctly.