Introduction

Imagine spending hours crafting the perfect email marketing campaign, writing polished transactional customer emails, or sending a critical business proposal, only for your messages to vanish into thin air or end up in the dreaded spam folder. In the modern digital landscape, email delivery is not a guarantee—it is earned through rigorous technical compliance. If your recipient server cannot verify who you are, it will block your connection or filter your mail.

At the center of email deliverability are Domain Name System (DNS) records. When email routing or verification breaks down, system administrators and IT professionals rely on diagnostic suites to isolate the problem. Among these tools, the MXToolbox MX check is the undisputed industry standard. This comprehensive guide will walk you through how to use the MXToolbox suite—including the primary MX check, TXT lookup, and PTR checks—to identify DNS configuration errors, secure your domain, and guarantee that your emails arrive safely in the inbox.

1. Demystifying DNS: What Are MX, TXT, and PTR Records?

Before diving into the mechanics of diagnostic tools, it is vital to understand the foundational DNS records that control how mail flows across the internet. DNS acts as the address book of the internet, translating human-friendly domain names (like example.com) into computer-readable IP addresses. For email, three specific records form the backbone of security, routing, and delivery verification.

Mail Exchanger (MX) Records

An MX record tells the rest of the internet which mail server is authorized to accept incoming emails on behalf of your domain. When someone sends an email to an address at your domain, the sending mail transfer agent (MTA) queries your DNS for its MX records.

MX records contain two primary elements:

1. The Mail Server Hostname: An FQDN (Fully Qualified Domain Name) pointing to the physical or virtual mail server (e.g., mail.protection.outlook.com for Microsoft Office 365).
2. The Preference (or Priority) Value: A numerical value indicating priority (e.g., 10, 20, 30). Sending MTAs will always try the server with the lowest preference number first. If that server is unreachable, they fallback to the next lowest number.

Crucially, RFC specifications dictate that MX records must point to an A record (a hostname that resolves to an IP address), never directly to an IP address itself. Misconfiguring this is one of the most common reasons email routing fails.

Text (TXT) Records

Unlike MX records, which serve a singular routing function, TXT records are highly versatile. They allow domain administrators to write arbitrary text into DNS records. In the context of email, TXT records have become the primary mechanism for sender authentication and security. The three pillars of email security—SPF, DKIM, and DMARC—are all deployed as TXT records:

• SPF (Sender Policy Framework): Lists all authorized sending IP addresses and domains. If a server not listed here sends mail claiming to be from your domain, it fails SPF.
• DKIM (DomainKeys Identified Mail): Publishes a cryptographic public key. Outbound emails are signed with a private key, and receiving servers use the public TXT record to verify the integrity and origin of the email.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): Specifies how a receiving server should handle emails that fail SPF or DKIM checks, acting as an enforcement policy.

Pointer (PTR) Records

While standard DNS lookups find the IP address associated with a hostname (Forward DNS), a PTR record does the exact opposite. It resolves an IP address back to its associated hostname (Reverse DNS or rDNS). PTR records are managed by the entity that owns the IP address space (typically your ISP or hosting provider) rather than your domain registrar. We will explore why this is a critical gatekeeper for email spam filters in later sections.

2. How to Perform and Analyze an MXToolbox MX Check

The MXToolbox MX check is a free diagnostic tool designed to test your domain's mail server configuration from an external perspective. It mimics the behavior of an external sending mail server to show you exactly how global systems see your domain.

Running the Check

To begin, navigate to the MXToolbox website. In the main search field, you can perform your search in two ways:

1. Enter your domain name (e.g., yourdomain.com) and click the "MX Lookup" button.
2. Use the direct command syntax: mx:yourdomain.com and press Enter.

Within seconds, MXToolbox will return a clean, tabular report containing critical information about your mail servers.

Parsing the MX Lookup Results

Understanding the output of the MX check is essential for diagnosis. The table includes several fields:

• Pref (Preference): Displays the priority ranking of your mail servers. Ensure your primary inbound server has the lowest numerical value.
• Hostname: The FQDN of the mail server. Ensure this points to your active email provider (e.g., Google, Microsoft, or your self-hosted mail gateway).
• IP Address: The public IPv4 or IPv6 address associated with the host. If your host resolves to multiple IPs, they will all be listed here.
• TTL (Time to Live): Shows how long external DNS servers will cache your MX records before querying your authoritative nameservers again. A high TTL (e.g., 86400 seconds / 24 hours) is great for performance, but if you are migrating mail servers, you should lower this to 300 seconds (5 minutes) a few days in advance to ensure rapid propagation.

The SMTP Diagnostic Test

Beside your MX server listings, you will see a "Test Email Server" link (often appearing as an SMTP test button). Clicking this triggers an automated SMTP handshake. MXToolbox connects to your mail server on port 25 and executes an interactive diagnostic test. It measures transaction times, checks if the server is an open relay, verifies TLS encryption availability, and evaluates the server's welcoming banner. This test is the most direct way to check if your physical mail server is online, secure, and configured in compliance with RFC standards.

3. Securing Your Sender Reputation with MXToolbox TXT Check

Having a functional MX record ensures you can receive emails, but without a properly configured MXToolbox TXT check, your outbound emails are highly susceptible to spoofing and spam folder placement. Let's explore how to use the TXT lookup tool to secure the three pillars of email authentication.

Running the TXT Check

To verify your TXT records, enter txt:yourdomain.com into the MXToolbox search bar. This query returns all TXT records published on your domain. Alternatively, you can run dedicated checks like spf:yourdomain.com or dmarc:yourdomain.com for a more structured, analytical breakdown.

Verifying SPF (Sender Policy Framework)

When running an SPF check, MXToolbox parses your SPF TXT record and flags syntax errors or architectural flaws. A standard, healthy SPF record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net -all

During the diagnostic, MXToolbox checks for the following fatal errors:

• Multiple SPF Records: Your domain must only have one SPF record. If you have multiple, receiving servers will discard them all, resulting in automated SPF failures.
• The 10-Lookup Limit: The SPF specification limits the number of DNS lookups a receiving server has to make to validate your SPF record to exactly 10. Each include, mx, a, and exists mechanism triggers a lookup. If your record requires 11 or more lookups, it will fail validation. MXToolbox provides a recursive lookup tree showing exactly how close you are to this limit.
• Permissive Fail Mechanisms: Ending your record with +all allows any server on earth to send on your behalf. MXToolbox will flag this as a critical security vulnerability.

Validating DKIM (DomainKeys Identified Mail)

Unlike SPF, DKIM records are published on subdomains using a 'selector.' For example, if your sending platform uses the selector s1, your DKIM public key will reside at s1._domainkey.yourdomain.com. To run a DKIM check, use MXToolbox's dedicated DKIM lookup by inputting your domain and the specific selector. The tool will check if the public key is correctly formatted and matches standard key sizes (2048-bit keys are the modern secure standard, while 1024-bit keys are increasingly deprecating).

Checking DMARC Alignment

Your DMARC record tells receiving servers how strictly they should enforce SPF and DKIM. To check your DMARC status, run dmarc:yourdomain.com in MXToolbox. It will look for a record like:

v=DMARC1; p=reject; rua=mailto:[email protected]

MXToolbox will evaluate your policy level (p=none, p=quarantine, or p=reject). If you are running a none policy, MXToolbox will remind you that while none is great for monitoring, you must transition toward quarantine or reject to actively protect your domain from impersonation.

4. The Critical Role of Reverse DNS: MXToolbox PTR Check

Many domain owners focus entirely on forward DNS records (MX and TXT) and completely ignore Reverse DNS. However, major email providers (including Gmail, Microsoft, Yahoo, and iCloud) use Reverse DNS validation as a primary defense mechanism against spam networks.

To understand why, consider how spammers operate. They often hijack insecure computers, residential internet connections, or deploy automated bots on cheap cloud hosting instances. These devices send emails with forged headers, but their sending IP addresses cannot be disguised.

What is a PTR Record and Reverse DNS?

When a mail server at IP address 192.0.2.55 connects to a receiving server, the receiving server queries DNS to find the hostname associated with 192.0.2.55. This is a reverse lookup. If a valid Pointer (PTR) record exists, it might return mail.yourdomain.com.

To ensure complete legitimacy, the receiving server then performs a forward lookup on mail.yourdomain.com. If the forward lookup returns 192.0.2.55, the loop is closed, and the connection is verified (known as Forward Confirmed Reverse DNS, or FCrDNS). If this chain is broken, spam filters will instantly flag or reject the email.

Running an MXToolbox PTR Check

To check your reverse DNS configuration, you must use the IP address of your sending mail server (not your domain name). Input the IP into MXToolbox using the PTR lookup tool, or type ptr:192.0.2.55 in the query box.

MXToolbox will return the hostname associated with that IP address. If the tool displays a red warning stating that no PTR record was found, or that the PTR record resolves to a generic ISP hostname (e.g., dynamic-ip-192-0-2-55.isp.com), you have a delivery bottleneck.

How to Fix a PTR Record Issue

Unlike standard DNS records, you cannot configure PTR records through your domain registrar (like GoDaddy, Cloudflare, or Namecheap). PTR records must be configured by the entity that controls the IP block:

• If you use a hosted cloud provider (AWS, Azure, DigitalOcean): You can set up reverse DNS via your cloud management console or by submitting a reverse DNS request form to their support team.
• If you host your own mail server on an business ISP line: You must contact your ISP's technical support department and ask them to map your static sending IP address to your mail server's FQDN (e.g., mail.yourdomain.com).
• If you use SaaS email providers (Google Workspace, Microsoft 365): You do not need to configure PTR records. These companies maintain massive, dedicated IP blocks with perfectly aligned PTR records on their end.

5. Troubleshooting Common MXToolbox Errors and Warning Badges

When running diagnostic checks, seeing a yellow warning or a red error badge can be alarming. Here is a breakdown of the most common alerts flagged by MXToolbox, their underlying causes, and practical steps to resolve them.

1. SMTP Banner Check Failed / Reverse DNS Does Not Match SMTP Banner

• The Issue: When MXToolbox connects to your mail server, it initiates an SMTP connection. The server responds with a welcoming banner, such as 220 smtp.example.com. If the hostname declared in this banner does not match the PTR record assigned to the server's public IP address, MXToolbox flags this error.
• The Fix: Access your mail server configuration files. In Postfix, edit the myhostname parameter in main.cf. In Microsoft Exchange, update the FQDN on your Receive Connector. Ensure this hostname matches your public PTR record exactly.

2. SMTP Transaction Time Is Too Slow (> 15 seconds)

• The Issue: MXToolbox measures the time it takes to connect, handshake, and disconnect from your mail server. If this process takes longer than 15 seconds, it warns you of a performance issue. Slow handshakes can cause external servers to time out, leading to delayed or dropped emails.
• The Fix:
  • Verify that your mail server is not overloaded with CPU or memory usage.
  • Check your firewall settings. Some stateful firewalls use features like "SMTP Fixup" or "Mail Guard" that inspect packets and slow down handshakes. Disable these legacy features.
  • Ensure your mail server is not attempting to perform its own reverse DNS lookup on the incoming MXToolbox testing IP before responding. If your server's DNS resolvers are slow, it will delay the handshake.

3. Mail Server is an Open Relay

• The Issue: This is a critical security vulnerability. An open relay is an SMTP server configured in such a way that it allows anyone on the internet to send email through it to any destination domain. Spammers actively scan the internet for open relays to send millions of spam messages, resulting in instant global blacklisting of your IP.
• The Fix: Secure your mail server immediately. Configure your SMTP settings to strictly require authentication (such as SMTP-AUTH/SASL) for any outbound mail. Disable relaying for any IP address outside of your trusted local network subnets.

4. SPF Record Syntax and "Too Many DNS Lookups" Errors

• The Issue: If you query your domain and get a warning about exceeding the 10-lookup limit or having a syntax error (like using ip4:192.0.2.0/24 with a missing slash or typo), your SPF authentication is broken.
• The Fix: Use an SPF flattening service to consolidate nested include mechanisms into a list of raw IP addresses, or audit your sending services (SendGrid, Mailchimp, HubSpot) and remove those you no longer use. Correct any syntax mistakes flagged by the interactive parser.

5. No DMARC Record Found

• The Issue: Your domain lacks a DMARC policy. This has transitioned from a security recommendation to an absolute requirement for modern email systems.
• The Fix: Create a simple TXT record named _dmarc.yourdomain.com with the value v=DMARC1; p=none; rua=mailto:[email protected]. Over time, analyze your reports and upgrade the policy p from none to quarantine and eventually reject.

6. Email Infrastructure Best Practices for Modern Administrators

Optimizing email deliverability is not a one-time event; it is an ongoing maintenance protocol. As spam filters become increasingly sophisticated and aggressive, administrators must adopt proactive habits to keep their domains healthy.

• Transition to Strict Alignment: Ensure that your header 'From' address, your envelope sender (SPF domain), and your DKIM signature domain all share the same organizational domain. Strict alignment prevents modern spam filters from flagging authentic mail as suspicious.
• Actively Monitor Blacklists: Even with perfect DNS configuration, an compromised employee account or malware on a local device can cause your mail server IP to send spam. Make weekly or bi-weekly blacklist audits a standard operating procedure. MXToolbox offers automated monitoring services that will notify you instantly via email or SMS if your IP is flagged on an RBL (Real-time Blackhole List).
• Implement TLS Encryption: Modern senders must support opportunistic TLS. Ensure your mail servers support TLS 1.2 and TLS 1.3 for secure transmission. Run an SMTP check regularly to confirm that secure handshakes are functional and that old protocols (like SSLv3 or TLS 1.0) are completely disabled.
• Follow Google and Yahoo Sender Guidelines: Google and Yahoo implement strict requirements for bulk senders (sending over 5,000 messages a day). These guidelines require a validated SPF/DKIM/DMARC implementation, clean reverse DNS (PTR) records, a functional one-click unsubscribe mechanism, and a spam complaint rate kept strictly below 0.3% (ideally under 0.1%). Non-compliance results in immediate rate-limiting or outright rejection of your outbound emails.

Frequently Asked Questions (FAQ)

Q: What is the optimal priority value for my MX records?

There is no single "optimal" priority value; what matters is the relationship between the values. Traditionally, administrators use increments of 10. For example, your primary mail server gets a priority of 10, your secondary gateway gets 20, and a backup spooler gets 30. If you only have one mail server (common with cloud suites like Google Workspace or Microsoft 365), you can set a single record with a priority of 1 or 10.

Q: Why is my MX record lookup showing old data after I updated my DNS?

This is caused by DNS caching, governed by the Time to Live (TTL) value of your original record. If your old MX record had a TTL of 86,400 seconds, local internet service providers and external query engines like MXToolbox may cache and display the old record for up to 24 hours. To avoid this during future migrations, lower your TTL to 300 seconds (5 minutes) at least 24 hours before making the actual mail server switch.

Q: Can I map my MX record directly to an IP address?

No. According to SMTP and DNS standards (RFC 5321), an MX record must point strictly to a domain name (FQDN) that resolves via an A (or AAAA) record. Pointing an MX record directly to an IP address will cause many sending mail servers to reject connection attempts, leading to failed inbound emails.

Q: What is the difference between SPF '~all' and '-all'?

These represent different failure handling mechanisms in SPF records. The tilde ~all stands for a "Soft Fail." It tells receiving servers that if the sending IP is not on the list, the email should still be accepted but flagged as suspicious (often landing in spam). The hyphen -all stands for a "Hard Fail," instructing receiving servers to reject the email outright. While -all is more secure, you should only implement it once you are 100% certain that all legitimate sending services for your domain are correctly listed in your SPF record.

Q: Why does the MXToolbox PTR check fail even though my website loads fine?

Your website and your reverse DNS configuration are entirely unrelated. Your website loads because a forward DNS record (the A record) translates yourdomain.com into an IP address. The PTR check fails because your IP provider has not created the reverse mapping from your mail server's public IP address back to your hostname. You must contact your hosting or ISP provider to create or update the PTR record.

Conclusion

Your domain's email health is only as strong as its underlying DNS configuration. Utilizing tools like the MXToolbox MX check, TXT check, and PTR check allows you to shed light on obscure networking errors before they disrupt your business operations. By proactively aligning your MX routing, auditing your SPF/DKIM/DMARC authentication, and securing your reverse DNS configurations, you establish an authoritative digital identity that spam filters trust. Don't wait for critical emails to bounce—make DNS auditing a core pillar of your technical hygiene today.