Your new website loads correctly, but customers say messages are bouncing. Or mail arrives from one sender and disappears from another. A website project can become an email incident when the team treats the domain's DNS records as if they serve only the website.
DNS is the directory that helps other systems find the services attached to your domain. Different records support different purposes; the website address and the email-delivery route are not the same setting. Microsoft explains that a business can use its domain with Microsoft 365 while its website remains hosted elsewhere. [1]
Preserve the mail records, not just the homepage address
Before changing DNS providers or nameservers, inventory the records used for mail routing, authentication, verification, and connected services. MX records help identify where incoming mail should go. SPF, DKIM, and DMARC address authentication and handling decisions; changing them carelessly can disrupt legitimate senders.
The right record values come from your actual providers and configuration, not a generic template copied from another company. A website contact form or business application may send mail through a different service from employee email.
What our support evidence shows
A Blue Tree Technology® record documented SPF changes, an explanation of TTL, and a review of DNS and MX-related questions. The technician's notes also said that broader mail-flow questions still required follow-up.
That record supports the value of coordinated review. It does not prove a particular website migration caused an outage, or that every delivery question was settled when the ticket closed.
Why "just wait for propagation" is incomplete
TTL controls how long DNS information can remain cached. Records with longer cache lifetimes can take longer to reflect a change, and local caching can add complications. Lowering a value afterward does not instantly erase copies already cached elsewhere. [2]
But waiting will not repair a missing record or a wrong destination. Verify the intended authoritative records first, then use message traces, delivery errors, and DNS checks to distinguish configuration errors from caching effects.
Our recommended change checklist
Capture the current working records and identify an authorized rollback owner. Stage the new zone, check that required mail records are present, and coordinate the change with whoever manages email. Confirm any necessary DNSSEC changes rather than altering nameservers in isolation.
Afterward, test incoming and outgoing messages with external accounts, replies, website forms, and any business-critical sending applications. Check authentication results and quarantine behavior, not just whether one internal test arrived.
Avoid repeated unplanned edits. Record what changed and when so a technician can follow a timeline instead of trying to diagnose a moving target.
Blue Tree Technology® can help coordinate the IT side of a domain or website change. A working home page is one acceptance test; dependable business email is another.