Or how the smallest mistake can create huge problems…
Think of DNS Like Your Phone’s Contact List
Most of us have hundreds of contacts stored in our phones. When you want to call a friend, you usually don’t memorize their phone number—you tap their name. Your phone looks up the number stored behind that contact and makes the connection.
The Internet works in much the same way. When you type www.caribbeansignal.com into your web browser, your computer doesn’t actually know where that website is located. Instead, it asks another service to find the answer.
That service is called the Domain Name System, or DNS. Think of DNS as the Internet’s contact list. Rather than forcing us to remember IP addresses such as 192.0.2.25, DNS translates easy-to-remember names like www.caribbeansignal.com into the IP address computers use to communicate with one another.
Without DNS, every website, email service and cloud application would require us to remember IP addresses instead of names. Most people never think about DNS. Until something goes wrong.
Email Depends on DNS Too
Many people associate DNS with websites, but email relies on it just as heavily.
Imagine you want to send an email to:
Before your email leaves your mail server, it needs to answer one important question:
“Which mail server is responsible for receiving email for example.com?”
DNS answers that question using a special record known as an MX (Mail Exchange) record. Think of the MX record as the postal sorting office for a company.
When you mail a letter, it doesn’t magically appear on someone’s desk. It first arrives at the correct postal facility, which then routes it to the intended recipient. Email works the same way. If the postal address is wrong, the letter never arrives.
A Real-World Investigation
Recently, I was reminded of an email delivery issue that I resolved during my operational IT days (most of my time is now spent on strategic IT initiatives), and in particular, email server administration.
Staff could send email without any difficulty.
But nobody could send email to them.
Every external sender received a bounce-back message.
At first glance, everything appeared normal.
The domain was verified in Google Workspace (mind you, this could have happened in an Exchange Online / Microsoft 365 environment as well).
The DNS records looked correct.
The MX record even appeared to point to Google’s recommended mail server.
Nothing immediately stood out.
The First Clue
The bounce message contained this line:
Host or domain name not found.
name=smtp.google.com.example.comThat immediately caught my attention. Notice that the mail server wasn’t trying to reach:
smtp.google.comInstead, it was trying to connect to:
smtp.google.com.example.comThose are completely different destinations.
Somehow, the company’s domain name had been appended to Google’s mail server name.
Everything Looked Correct…
When I looked at the DNS management console, the MX record appeared to be configured correctly.
It showed:
smtp.google.comMany people would have stopped there.
After all, if the management screen says it’s correct, surely the problem must lie elsewhere.
But…Never assume the Internet sees what the management console displays.
Management interfaces are simply tools for editing configuration. They don’t necessarily show you exactly what the rest of the world is seeing.
Trust the DNS, Not the GUI
Instead of relying on the management console, I queried Google’s public DNS server directly using:
nslookup -type=mx example.com 8.8.8.8The result immediately exposed the problem.
Instead of returning:
smtp.google.comit returned:
smtp.google.com.example.comThe authoritative DNS server was publishing a completely different value than what the management interface suggested. That explained everything.
One Tiny Detail
The DNS provider had entered the mail server name as a relative hostname instead of a Fully Qualified Domain Name (FQDN), two very different things. Because of that, the DNS software automatically appended the company’s domain name.
Instead of publishing:
smtp.google.comit published:
smtp.google.com.example.comSince that server doesn’t exist, every mail server attempting delivery received a “Host not found” response.
The Fix? Simply configure the MX destination as a Fully Qualified Domain Name. One tiny detail (a missing “dot”). One very large impact (no inbound email).
Final Thoughts
DNS quietly powers almost everything we do online. Most days it performs millions of lookups without anyone noticing. But when something does go wrong, the answer often isn’t found by making assumptions—it’s found by following the evidence.
In this case, the clue wasn’t hidden inside Google Workspace. It wasn’t inside Outlook. It wasn’t inside the firewall. It was hidden inside a single DNS record that looked perfectly correct but was far from it.
Sometimes, the difference between “working” and “not working” really is just a dot.