New Domain Email Not Receiving Messages? DNS Checks

When a new domain email address cannot receive messages, confirm that the mailbox exists and that incoming mail is routed to the correct provider. A working website or a successful outgoing message does not prove that inbound delivery is configured. Start with the recipient address, sender’s error report and the domain’s active DNS records.

Confirm which domain email addresses are affected

Write down exactly what is failing, when it started and who is affected. Test from another device or connection where appropriate. Save the exact error message rather than paraphrasing it. Small details can distinguish a local device problem from a DNS, hosting, account or WordPress issue.

Send a test from an unrelated external account to each affected address. Check webmail as well as the desktop application, and record any non-delivery report. If only one address fails, review its mailbox or alias setup before changing records for the entire domain.

Review domain email setup and recent DNS changes

Recent changes are often the most useful clue. Look for plugin or theme updates, password changes, DNS edits, hosting migrations, PHP upgrades, new security rules or mailbox configuration changes. Do not assume the most recent change caused the fault, but use the timeline to narrow the investigation.

Protect your recovery options

Before editing files, databases or DNS, confirm that you have a usable backup or another recovery path. A backup is only useful when you know what it contains and can restore it. For security incidents, preserve relevant logs before cleaning up because they may help explain how access occurred.

For Microsoft 365, confirm domain verification and compare the published MX destination with the value supplied by the tenant. Microsoft’s new-domain delivery guidance covers these checks and replication delays. Use the provider’s values rather than copying another business’s records.

Check the domain email route before changing applications

Compare the public MX result with your intended email provider and review whether old destinations remain. Confirm mailbox readiness before a planned routing change. If messages reach webmail but not one application, investigate that application’s account and synchronisation state instead of changing MX records again.

Change one thing at a time

Multiple simultaneous changes make troubleshooting harder because you lose the ability to identify what fixed or worsened the issue. Record important settings, make one controlled change and test again. If it has no effect, revert it where practical before moving to the next hypothesis.

Check that you are editing the DNS zone used by the domain’s active nameservers. Save the old values and the change time. An edit in an inactive zone will not change public delivery, and repeatedly changing correct records makes the timeline harder to interpret.

Test domain email delivery from outside the organisation

A homepage loading does not prove a website is healthy, and sending one email does not prove mail flow is correct. Test the functions the business actually relies on: forms, logins, checkout, inbound and outbound email, mobile access, SSL and scheduled processes where relevant.

Prevent the same issue from becoming an emergency again

Once the immediate fault is resolved, document the cause and the recovery steps. Keep domain, hosting and email ownership clear. Maintain backups, updates and account security. Record DNS settings and important third-party services so the next incident starts with useful information rather than guesswork.

Related troubleshooting guides

For help configuring the service, see Microsoft 365 setup. If the fault began during a wider move, use the hosting migration checklist to identify which provider controls each system.

Practical takeaway

For domain email DNS, diagnose before you repair. Confirm the scope, protect recovery options, check recent changes, test systematically and verify the full service afterwards. That approach is usually faster and safer than trying a long list of unrelated fixes.