Why can the business send email but not receive it?
Outbound and inbound email use different paths. Successful sending does not prove that inbound DNS, mail routing, mailbox delivery, filtering or storage is correct. Diagnosis should trace the inbound path independently.
What this can look like in practice
A single symptom rarely tells the whole story. These are some of the signs worth checking before deciding what needs to change.
Outbound messages arrive but replies never reach the mailbox
MX records point somewhere unexpected
Messages reach server logs but not the user mailbox
Only some recipient aliases fail
Mailbox quotas, filters or routing rules have not been checked
What to check next
Start with the parts that can be verified. This helps avoid expensive changes based on assumptions.
Verify the domain’s current MX destination
Confirm the receiving server accepts mail for the domain
Trace a controlled inbound message through server logs
Check aliases, filters, quotas and mailbox delivery
Verify the client is reading the correct mailbox and folders
Decision point
The practical takeaway
Treat inbound delivery as its own system path instead of repeatedly changing outbound settings.
Decision field guide
Trace inbound mail from public MX records to the user’s mailbox.
Sending and receiving use different infrastructure. Successful outbound delivery proves little about inbound MX records, provider acceptance, domain routing, aliases, filtering, quotas or the mail client. A controlled incoming test should be traced through each layer.
FIELD 01
Start with the domain’s MX destination
Confirm the active public MX records point to the provider intended to receive mail and that obsolete records have been removed when appropriate. DNS changes need time to propagate through caches. Compare the current records with the provider’s documented configuration rather than relying on an old setup guide.
FIELD 02
Confirm the receiving platform accepts the domain and address
Check that the domain is active in the receiving service, the mailbox or alias exists and routing rules send mail to the intended destination. Provider logs or message traces can show whether a controlled test reached the service, was rejected or was redirected.
FIELD 03
Inspect mailbox delivery after server acceptance
If the provider accepted the message, review spam or quarantine, user rules, forwarding, storage quota, aliases and client synchronization. Test through webmail when available to separate server delivery from a desktop or mobile client problem.
Evidence worth collecting
Current MX and DNS records
Provider domain and mailbox status
Controlled sender timestamp and recipient
Mail trace or server acceptance evidence
Mailbox rules, quotas and client configuration
Questions that sharpen the decision
Why can users send when MX is wrong?
Outbound sending can use authenticated SMTP or a provider API that does not depend on the same inbound MX route.
Should SPF be changed to fix incoming mail?
SPF primarily authorizes outbound senders for a domain. Incoming routing problems usually require MX, provider or mailbox investigation.
What is the fastest safe test?
Send a controlled message from an independent external provider, record the time and trace it through the intended receiving system.
DSDillon Commercial Intelligence Advisory. Information is provided to help businesses investigate a problem and make a more informed decision. Outcomes depend on the facts and circumstances of each business.
DSDillon Intelligence Pathways
Continue investigating
Related evidence-led briefs selected from search demand DSDillon has measured.
Explore more about Business Email Can Send But Not Receive
Practical answers for businesses losing traffic, leads or customer confidence. Use the related paths below to find supporting information, practical tools and the next step that fits your needs.
