When a mailbox can send but cannot receive, the fastest route to a fix is to separate outbound submission from inbound delivery. The user’s mail client can authenticate to an SMTP server and send successfully while public DNS tells every outside sender to deliver incoming mail somewhere else. This is common after migrations, DNS changes and partial email setups.
Key takeaways
- Sending successfully does not prove the domain’s incoming mail route is correct.
- MX records tell other mail systems where to deliver incoming messages.
- A bounce response can separate DNS and routing failures from mailbox, quota and policy failures.
- During migrations, old and new mail platforms can both appear configured while inbound delivery still points to the wrong system.
Understand the two routes
Outbound mail begins with the user or application handing a message to an authorised sending server. Incoming mail begins with a remote sender asking DNS which servers accept mail for the recipient domain. Those are independent paths.
That independence explains why “I can send” is not evidence that receiving is healthy. It confirms only that the user can submit mail to an outbound service.
Check MX records before changing the mailbox
MX records publish the destination for inbound mail. Google Workspace’s receive-mail troubleshooting starts by asking whether email is activated and whether MX records are configured correctly. Other hosted mail systems use the same DNS mechanism, even though required values differ.
Common faults include old-provider records left after a migration, an incorrect hostname, records entered under the wrong DNS name, conflicting priorities, or a domain whose authoritative DNS is not the zone the administrator edited.
Use the bounce response to identify the layer
If an outside sender receives a nondelivery report, preserve the exact SMTP status and text. A DNS lookup failure means the message may never have reached the intended provider. An unknown-recipient response suggests the provider was reached but did not recognise the mailbox. A quota or policy response points to another layer.
This prevents a common mistake: changing DNS after the message is already reaching the correct provider, or changing mailbox settings when the remote sender cannot find the receiving servers.
If the provider received the message, investigate internal routing
Once logs confirm that the receiving platform saw the message, inspect aliases, groups, forwarding, split delivery, routing rules, quarantine, spam controls and mailbox status. Public MX changes are unlikely to be the primary fix at that point.
Test from more than one external network. A message sent from the same platform can follow internal routing that hides an external DNS problem.
Migrations deserve special suspicion
Moving from cPanel mail, Google Workspace, Microsoft 365 or another platform creates a period where several systems may still contain valid user accounts. Only one public route should normally be authoritative for incoming delivery unless split or dual delivery was intentionally designed.
Document the cutover: authoritative DNS provider, required MX values, TTLs, old routes to remove, new routing rules, aliases and forwarding.
Use a reliable diagnostic sequence
Test the address from an unrelated external account and preserve the bounce. Query the public MX records from outside the hosting environment. Confirm they match the intended provider. Then use the provider’s mail logs to determine whether it saw the test message.
That sequence isolates public routing before internal mailbox logic and avoids the random cycle of deleting and recreating accounts.
- Send a test from an unrelated provider.
- Record the exact SMTP or DNS error.
- Query public MX records.
- Confirm authoritative DNS is the zone being edited.
- Check receiving-provider logs.
- Inspect aliases and routing only after delivery reaches the provider.
Why can a business email account send successfully but receive nothing?
Because outbound and inbound email use different routing decisions. Sending proves that a client or application can hand a message to an outbound SMTP service that is willing to relay it. Receiving requires other mail systems to discover where your domain accepts mail, connect to that destination, complete SMTP delivery, address a valid recipient and survive any routing, filtering or mailbox rules inside the receiving environment. One side can work while the other is completely broken.
This asymmetry is useful evidence. If outbound mail works after a migration but inbound mail does not, do not start by changing the user’s password or reinstalling the mail app. Test the domain’s MX records, authoritative DNS, receiving server reachability and recipient routing. Google’s own “I’m not receiving mail” troubleshooter starts with activation and MX configuration because inbound routing has to exist before inbox settings matter.
The MX record is the public road sign for inbound mail
MX records tell sending systems which host or hosts are responsible for receiving mail for a domain. The record points to a hostname, not directly to a mailbox. That hostname must in turn resolve to reachable infrastructure. If the MX record points to an old provider, an expired service, a typo or a hostname that no longer resolves correctly, senders can fail before your mailbox platform ever sees the message.
Multiple MX records also carry priorities. Lower preference numbers are normally tried first under SMTP routing rules. A leftover higher-priority server may still receive mail under some failure conditions, which can create intermittent behavior that is harder to diagnose. During migration, inventory every MX record and understand why it exists rather than assuming that adding the new provider alongside old records is harmless.
DNS authority problems can make a correct-looking record irrelevant
A common migration failure occurs when the administrator edits DNS in one control panel while the domain is actually delegated to different authoritative name servers. The new MX record appears in the hosting interface but never becomes authoritative on the public internet. Another failure occurs when nameserver changes are only partially complete or the domain registration itself lapses, producing NXDOMAIN or stale responses.
Always check public DNS from outside the hosting account. Ask which name servers are authoritative, query the MX record from independent resolvers, then resolve the MX target. This separates “what I typed into a dashboard” from “what the rest of the internet can actually see.” If public DNS is wrong, changing mailbox settings cannot fix inbound delivery.
A reachable server can still reject the recipient
Once a sender reaches the correct mail server, SMTP recipient validation becomes the next layer. The server can reject a message because the mailbox does not exist, an alias is missing, the domain is not configured as local, the recipient has been suspended, a quota or policy is blocking delivery, or the address is being routed somewhere else. Status codes in the bounce usually reveal whether the failure happened at this stage.
This is why the sender’s non-delivery report is valuable. “Domain not found,” “no such user,” “relay denied,” “mailbox unavailable,” “policy rejection” and “connection timed out” point to different components. Ask an external sender for the full diagnostic text rather than accepting “it bounced” as the entire incident report.
Firewall, port and TLS failures sit between DNS and the mailbox
Public MX records can be correct while the receiving host is unreachable on SMTP. Firewalls, security groups, NAT rules, failed services and provider blocks can prevent connections to port 25. TLS negotiation can also fail when the server is configured incorrectly, although the exact behavior depends on sender policy and whether encryption is required. A self-hosted mail platform therefore needs external connection tests, not only local service checks.
Test from outside the server’s network. Confirm the MX target resolves to the intended address, that SMTP answers, that the greeting identifies the correct server, and that the server is willing to accept the intended recipient domain. Internal tests from the same VPS can miss firewall, routing and DNS conditions that affect real senders.
Internal routing and filtering become relevant only after receipt is proven
If logs show that the receiving server accepted the message, the investigation moves inward. The message may be routed to another mailbox, redirected by a transport rule, placed in spam, quarantined, rejected by a content filter after initial acceptance, delivered to a shared mailbox, or hidden by a client-side rule. In hosted systems, an email log search or message trace is often the fastest way to determine what happened after acceptance.
The key is to preserve the sequence. Do not spend an hour searching the spam folder when the server never received the message. Do not edit MX records when the trace proves the provider accepted it and delivered it to a quarantine. Each piece of evidence narrows the next step.
Split delivery and hybrid migrations create subtle failure modes
Businesses sometimes keep some users on an old provider while moving others to a new system. This requires deliberate split-delivery or routing rules. Without them, the public MX destination may accept mail for users it does not actually host, or the old platform may continue receiving messages that the new users never see. Aliases and distribution groups are particularly easy to miss because they may not appear in a basic mailbox inventory.
Before cutover, export every mailbox, alias, forwarding rule, group and special recipient. After cutover, test each recipient class from an external domain. The fact that one executive mailbox receives mail does not certify the domain. A production migration is complete only when the full recipient map and expected routing paths are verified.
How should you test inbound email after a DNS or hosting change?
Use at least two external sending providers and test representative recipient types. Record the send time, recipient, sender, result and any bounce. Check public MX responses and server logs during the same window. If the environment supports it, confirm the final mailbox folder and message ID. This creates an evidence chain from external sender to public DNS to receiving server to mailbox.
Avoid declaring success immediately after changing DNS merely because one message arrives. Cached records can cause different senders to use old and new routes for a period. Keep old receiving infrastructure available where practical during a controlled transition, and monitor both paths until public DNS and real delivery are stable.
What should you expect from a professional business-email repair?
A professional repair should begin with the domain and routing evidence, not with a recommendation to buy a new mailbox plan. The provider should identify the authoritative DNS, current MX set, receiving host, SMTP reachability, recipient configuration and relevant logs. If a migration is involved, the provider should also verify aliases, historical mail, authentication records and rollback options.
The buyer should receive a clear statement of root cause and proof of restoration, ideally with external test messages and preserved diagnostic evidence. If the issue is only a missing MX record, the solution may be small. If DNS, routing and mailbox state have diverged across providers, the engagement is more complex. Pricing should reflect the actual failure domain, not the panic level of the customer.
SPF, DKIM and DMARC are usually not the reason inbound mail cannot reach your domain
SPF, DKIM and DMARC primarily help receiving systems evaluate messages that claim to come from a domain. They are important for outbound identity and anti-spoofing policy, but a broken SPF record normally does not tell the rest of the internet where to deliver mail addressed to you. That job begins with MX and DNS routing. Businesses sometimes lose hours editing authentication records while the inbound MX destination is still pointing at the old provider.
There are exceptions and interactions: a receiving gateway can enforce authentication policies on messages entering your environment, and DMARC affects how other providers treat mail claiming to be from you. But when the symptom is “everyone can receive what I send, nobody can send to me,” start with inbound routing and server acceptance. Solve the path in the order the message travels.
Avoid using a random backup MX server as a safety net
Older mail architectures sometimes used secondary MX hosts that queued messages when the primary server was unavailable. A badly configured secondary server can instead become a source of loss, spam acceptance or delayed mail. If it is not synchronized with valid recipients and anti-abuse policy, it may accept mail the primary would reject or become a target for attackers trying to bypass filtering.
For modern small-business deployments, every published MX record should have a documented purpose and be actively managed. If high availability is required, design it intentionally with compatible routing, recipient validation, security and monitoring. Do not leave an old provider in DNS “just in case” after migration unless you have verified exactly what it will do with incoming messages.
Sources reviewed
Requirements, platform behavior and market conditions can change. Review the current source material before acting on time-sensitive requirements.
Related DSDillon resources
DSDillon can examine the technical, commercial or property-specific evidence and define the next action.
Talk to DSDillon