MX Records Say Where Mail Goes, Not Who Exists

BY IN news NO COMMENTS YET

An MX record is a delivery instruction, not an inventory of mailboxes. It tells a sending server which host should accept mail for a domain, and nothing more. If you have been using an MX lookup to figure out whether a catch-all address exists, you are asking the DNS system a question it was never designed to answer. The catch-all can be on, off, or pointed at a black hole, and the MX record will look exactly the same in every case.

What an MX record actually tells the sending server

When someone sends mail to anything@yourdomain.com, their server performs an MX record lookup on yourdomain.com. The answer is a hostname like mail.yourdomain.com plus a priority number. That hostname resolves to an IP address, and the sending server opens an SMTP connection there and hands over the message with the original recipient address in the envelope. The receiving server then decides what to do with that address. Every decision about whether a mailbox exists, whether it forwards, whether it bounces, or whether it lands in a catch-all happens after the connection is made, inside the mail server or the email hosting panel that controls it.

This is the part people miss. The MX record is the street address of the post office. It says nothing about which names on the mailbox wall are real. You can run an MX lookup on a domain with zero mailboxes and get a perfectly valid answer, because the record points at a server that is configured to reject every recipient. You can run the same lookup on a domain with 200 active mailboxes and get the identical answer. DNS is a routing layer, and routing is not the same as provisioning.

The practical consequence is that diagnosing a catch-all problem with dig or an online MX checker is a dead end. If mail to random-address@yourdomain.com is bouncing, the bounce message will tell you more than any DNS query. Look for the SMTP rejection code and the server that produced it. A 550 “no such user” or “recipient rejected” reply means the message reached the right server and that server refused the address. That is a configuration issue inside the hosting panel, not a DNS issue.

Where the catch-all setting actually lives

A catch-all address, sometimes called a default address, is a rule on the receiving mail server that says: if an incoming message is addressed to a local recipient that does not match any real mailbox or forwarder, deliver it here instead of rejecting it. That rule lives in the email hosting panel, not in DNS. The exact location depends on the platform, and the platform is determined by where your MX records point. This is the one place DNS matters for catch-all troubleshooting: you have to know which server is receiving the mail before you know which panel to open.

Panel-by-panel locations for the catch-all setting

In cPanel, the setting is called Default Address and it sits under the Email section. cPanel calls the catch-all the Default Address, and it applies to the domain selected in the panel. You can set it to forward unrouted email to a specified mailbox, discard it, or reject it. cPanel is used by Namecheap shared hosting and GoDaddy cPanel hosting, so the same screen appears on both, even though the two companies sell it under different names. If your MX records point at a cPanel server, that is where you look.

Namecheap offers catch-all via free email forwarding on domains that use its forwarding service rather than a hosted mailbox. GoDaddy provides a catch-all toggle in the email settings for its own mail products, including Professional Email. Google Workspace requires its own catch-all rule, configured per domain in the admin console under routing and recipient addressing, and it ignores anything you set in a cPanel panel because Google is the one receiving the mail. Private Email, Namecheap’s paid mail product, has its own catch-all setting separate from the free forwarding path. The pattern holds everywhere: find the server named in your MX records, then find that server’s control panel.

One wrinkle trips up people who switch providers. Domain-level forwarders override the Default Address. If you have a forwarder set for sales@yourdomain.com, mail to that address goes to the forwarder’s destination even if the catch-all would otherwise have handled it. Forwarders are evaluated first because they match a specific address. The catch-all only fires for addresses that match nothing else. If a catch-all seems to be ignoring certain addresses, check for an existing forwarder or mailbox on those addresses before you touch the catch-all itself.

The information gain worth repeating: MX records only tell the sending server where to deliver. They do not define which addresses exist. A catch-all is invisible to MX record lookup and has to be diagnosed inside the email hosting panel. If you take one thing from this article, take that.

The trade-off with catch-all is spam. Once a catch-all is live, every misspelled address, every scraped guess, and every dictionary attack against your domain lands somewhere. Spammers may cause large amounts of spam at the default address, and that inbox becomes a magnet. Many admins run a catch-all for a few months to catch legitimate mail sent to old addresses, then turn it off once they have collected the stragglers. Others point the catch-all at a dedicated mailbox they check weekly, or set it to discard after the initial grace period. There is no right answer, but there is a real cost, and it is paid in spam volume.

If you are troubleshooting a missing email, start with the bounce message and the receiving server, then open the panel that controls it. Check the Default Address or catch-all setting, check for a conflicting forwarder on the specific address, and confirm the MX records still point at the server you think they do. If you are setting up a new domain, decide on the catch-all before you publish MX records, because the setting only takes effect on the server that actually receives the mail. Run the MX record lookup once to confirm the destination, then do all remaining work inside the email hosting panel.

Comments are closed.