A new website should be an exciting milestone. However, a rushed website launch or DNS update can create serious problems if the right people are not informed.
For many businesses, DNS changes and email are closely connected. A record added to help a website load can be changed alongside an email record, or an entire DNS zone can be replaced without the required mail settings being copied across. The result may be missed enquiries, rejected emails, broken forms or a complete email outage.
It is crucial to understand that DNS changes and email impact various aspects of online business. Frequent updates to DNS settings can lead to disruptions in email services if not managed correctly. Therefore, a keen awareness of DNS changes and email coordination is essential for any business.
This is why communication matters before, during and after any website or DNS change.
What is DNS and why does it affect more than your website?
DNS, or the Domain Name System, acts like the internet’s directory. It tells browsers, email systems and other services where to find your domain.
A single business domain might support:
- The company website
- Microsoft 365 email
- Website contact forms
- CRM and marketing automation
- Online booking systems
- Analytics and advertising platforms
- Remote access services
- Customer portals and other cloud applications
These services may be managed by different suppliers. The web developer may control the website, while the domain registrar controls the registration and the DNS provider hosts the records. Your IT support provider may manage Microsoft 365, and a marketing agency may operate email campaigns or CRM integrations.
That creates a coordination challenge. Changing DNS management or nameservers affects the whole domain, not just the website.
DNS changes and email: which records do what?
When planning DNS changes and email modifications, each record must be evaluated to ensure no disruption occurs. DNS changes and email must be synchronised to prevent any adverse effects on your business operations.
You do not need to be a DNS expert to understand the main records. Knowing their purpose makes it easier to ask the right questions.
Nameservers: who manages the DNS?
Nameservers tell the internet which provider holds the authoritative DNS records for your domain.
For example, your registrar may currently point your domain to the nameservers of a hosting provider or DNS platform. If a web agency changes those nameservers to its own service, every DNS record needs to exist in the new location.
When nameservers are changed, the new DNS provider becomes authoritative for the domain. The old provider’s DNS zone is not used as a fallback. As cached information expires, internet users and services will query the new provider instead. Any record that has not been copied across will therefore stop resolving when the new zone is used. That means an incomplete DNS copy can leave the website working while breaking Microsoft 365 email, website forms, CRM connections, security verification and other domain-dependent services. The new DNS zone must contain and be checked against every required A, AAAA, CNAME, MX and TXT record before nameserver delegation is changed.
Do not change nameservers until the new DNS provider has a complete and verified copy of the existing DNS zone.
A and AAAA records: where the website lives
An A record points a domain or subdomain to an IPv4 address. An AAAA record performs a similar function for IPv6.
These commonly direct web traffic to a hosting server. If an A record is incorrect, visitors may see an error page or reach the wrong website.
They usually control website traffic, but they are only part of the domain configuration.
CNAME records: aliases and service connections
A CNAME record points one name to another domain name. It is often used for:
- The
wwwversion of a website - Microsoft 365 verification or DKIM configuration
- Marketing and CRM platforms
- Website hosting services
- Third-party application connections
A web developer changing a CNAME may unintentionally affect a cloud service that depends on it. This is why every record should be reviewed before editing.
MX records: where incoming email is delivered
An MX record tells other mail systems where to deliver incoming email for your domain.
For a business using Microsoft 365, the MX record should point to the Microsoft 365 mail protection service shown in the Microsoft 365 admin centre. If the MX record is removed, mistyped or replaced with an old mail server, external messages may be delayed, rejected or delivered somewhere unexpected.
TXT records: text-based instructions and verification
TXT records store text information that services use to verify ownership or assess email security.
They may contain:
- SPF policies
- DKIM public keys or service references
- DMARC policies
- Microsoft 365 domain verification
- Website and security service verification
- Third-party application settings
A TXT record may look harmless, but deleting or overwriting one can break email authentication or prevent a service from verifying your domain.
SPF, DKIM and DMARC: protecting email delivery
These are email security controls, usually published through DNS.
- SPF (Sender Policy Framework) lists the services authorised to send email for your domain. Microsoft 365 may be included, along with approved marketing or CRM platforms.
- DKIM (DomainKeys Identified Mail) adds a digital signature to outgoing messages. Recipients use a public key in DNS to check that the message is genuine and has not been altered.
- DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receiving systems what to do when SPF or DKIM checks fail. It also provides reporting that can help identify spoofing and unauthorised senders.
There should generally be one correctly managed SPF record for a domain. If a new SPF record overwrites the existing one, legitimate senders such as Microsoft 365, a CRM or an email marketing platform may no longer be authorised.
For authoritative advice, review the NCSC guidance on email security and anti-spoofing.
TTL and propagation: why changes are not instant
TTL, or Time to Live, tells DNS resolvers how long to cache a record before checking again.
A lower TTL can help a planned change move more quickly, but it does not instantly clear every cached answer. Different networks may continue using the old information for different periods.
Propagation is not a substitute for testing. A change can appear correct from one location while another network is still using an old record.
What can go wrong without communication?
Consider these realistic examples:
-
An agency changes nameservers without telling IT.
The new website loads, but the new DNS provider does not contain the Microsoft 365 MX, SPF, DKIM and DMARC records. Website visitors are unaffected, but external email begins to fail.Without proper coordination, DNS changes and email can lead to significant communication breakdowns, resulting in missed opportunities and customer dissatisfaction.
-
An MX record is omitted during a DNS migration.
Staff can still send messages internally, creating a false sense that everything is working. However, customers outside the organisation cannot deliver new messages. -
An SPF record is overwritten.
Microsoft 365 may still send email, but messages from the CRM or newsletter platform start failing authentication. Some recipients may see warnings or reject the messages. -
A web developer changes a TXT record.
A verification record is updated without checking its purpose. The website may work, but DKIM or another email authentication setting no longer passes. -
A new website launches while support teams are unaware.
A contact form may be tested only in the browser. Nobody checks whether submissions reach the right mailbox, CRM or notification system.
The consequences can include:
- Missed sales enquiries
- Bounced or delayed email
- Failed Microsoft 365 mail flow
- Broken calendars and integrations
- Website downtime
- Contact form failures
- Loss of customer confidence
- Security weaknesses caused by missing authentication records
- Time-consuming troubleshooting between suppliers
Diana’s Winchester agency: a simple change with significant consequences
Diana runs a growing digital marketing agency in Winchester with 12 staff. The business uses a new website, Microsoft 365 email, a CRM, analytics tools and several client campaign platforms.
Her web developer plans to move the website to a new hosting provider. The developer asks for access to the domain registrar and says the change will take only a few minutes.
In a rushed launch, the nameservers are changed before the complete DNS inventory is checked. The website works, but the new DNS zone is missing the Microsoft 365 MX record and the DKIM CNAME records.
Diana’s team can still email each other because existing sessions and cached information mask the problem. However, some external customers receive delayed delivery notices, while others receive bounce messages. Website enquiries also stop reaching the shared sales mailbox.
The launch has created an avoidable email outage during active client campaigns.
A coordinated approach would have been different. Diana, the web developer, IT support provider, registrar and hosting company would agree the scope, copy every required record, test the new DNS zone and confirm a rollback plan before launch. The website could then be changed without disrupting email or business operations.
Use this website migration checklist
In the context of DNS changes and email, it is vital to ensure that all stakeholders are informed and involved in the process to mitigate risks.
Good DNS change management does not need to be complicated. It does need to be deliberate.
Before the change
- Identify every party involved: business owner, internal team, IT support provider, web developer, hosting company, domain registrar, DNS provider, Microsoft 365 administrator and other suppliers.
- Create a complete DNS inventory: record type, host, target, priority, TTL, purpose and owner.
- Document access: record who controls the registrar, DNS platform, hosting account and Microsoft 365 tenant. Store access securely.
- Confirm the scope: decide whether the change affects only an A record, several website records, or the nameservers and whole DNS zone.
- Lower TTLs where appropriate: do this ahead of a planned change, based on advice from the person managing DNS. Remember that cached records may still remain.
- Agree a maintenance window: avoid busy campaign periods, payroll deadlines and important customer events.
- Define responsibilities: state who makes the change, who tests it and who contacts each supplier if something fails.
- Prepare a rollback plan: take screenshots and exports of the current DNS records before making changes.
During the change
- Use a single agreed change plan.
- Make one controlled change at a time where possible.
- Keep the IT support provider and relevant suppliers informed.
- Record the time of each change, including the old and new values.
- Do not assume that a successful website launch means the change is complete.
After the change
Test from inside and outside the organisation:
- Website loading on the main domain and
wwwaddress - Website forms and confirmation emails
- Inbound email from external accounts
- Outbound email to external recipients
- Microsoft 365 mail flow and message trace
- SPF, DKIM and DMARC results
- Calendar invitations and shared mailboxes
- CRM, analytics, payment and marketing integrations
- Remote access and other domain-dependent services
- Mobile and home broadband connections, not just the office network
The Microsoft guidance on creating DNS records is a useful reference for organisations using Microsoft 365. Exact record values should always be taken from your own Microsoft 365 admin centre and DNS provider.
Finally, communicate completion. Tell all parties what changed, confirm the tests passed and update the documentation. Monitor email delivery, website forms and security reports for several days afterwards.
Proper communication about DNS changes and email adjustments is paramount to avoid misunderstandings that could lead to service outages.
Make communication part of the change
A website change is not just a web project. It may be a domain, email, security and business continuity project at the same time.
If your business is experiencing Microsoft 365 email issues after a website migration, do not immediately assume that Microsoft 365 itself is at fault. Check whether nameservers, MX, TXT, CNAME or other DNS records were changed.
Ultimately, implementing DNS changes and email strategies should align with business goals to maintain seamless communication with clients.
Moreover, after any DNS changes and email updates, a thorough analysis of the results helps to ensure that all systems are functioning optimally.
BITSmart can act as a calm, proactive IT partner when coordination is needed. We can work alongside your chosen web agency, hosting company and other suppliers to document the environment, check the impact and test critical services. Not every website change needs to be performed by BITSmart, but every important change benefits from clear ownership and communication.
Book a call before your next DNS change
Planning a website move or DNS update? A short conversation can help identify hidden dependencies before they become an email outage.
Book a Call with BITSmart to discuss your change plan, DNS records and testing requirements with a Hampshire IT support team.
With the right checklist, clear responsibilities and proactive testing, you can launch website changes confidently while keeping email and other core services available.
