What happens when you type a website address into your browser? And how can your website be hosted by Webcore while your business email stays with Microsoft 365?
The Domain Name System (DNS) is a distributed directory that helps devices locate services by their human-readable names. DNS records connect names to addresses, mail services and other information. Understanding DNS makes website migrations, email setup and troubleshooting much easier.
Your domain is the name people recognise. DNS helps their devices locate the services behind it. Website and email hosting do not need to be at the same provider.
How a DNS lookup works
When you visit www.example.com, a typical uncached lookup follows these stages:
Not every lookup visits all these servers. A cached response may avoid most of the steps, which makes routine lookups much faster.
Domain registrar, nameservers, DNS and hosting
Domain registrar: the company through which you register and renew the domain.
Authoritative DNS provider: the service hosting the records that other DNS systems ultimately consult. The domain delegation identifies its authoritative nameservers.
Website host: the infrastructure serving your website, possibly via a CDN or proxy.
Email provider: the service delivering and storing your business email, such as Microsoft 365.
These may all be different companies. For example, Webcore can manage DNS and host a website while Microsoft 365 continues receiving the company’s email.
Common DNS record types
A: IPv4 address
An A record points a name to an IPv4 address. For example:
www.example.com. A 203.0.113.10
This documentation-only address illustrates where a website hostname might point. The real value must be supplied by the hosting provider.
AAAA: IPv6 address
An AAAA record is the IPv6 counterpart:
www.example.com. AAAA 2001:db8::10
Publish an AAAA record only if the destination is reachable over IPv6. An obsolete IPv6 record can cause failures even when the IPv4 address is correct.
CNAME: hostname alias
A CNAME makes one hostname an alias for another:
www.example.com. CNAME example.com.
A conventional CNAME cannot coexist with other ordinary records at that same owner name. Using CNAME at the domain apex also conflicts with required apex records, unless a DNS provider offers special flattening or alias functionality.
MX: incoming mail destination
MX records identify mail servers that accept inbound mail:
example.com. MX 10 mail.example.com.
The number is the preference, with smaller values preferred. Microsoft 365 supplies tenant-specific MX destinations, so always use the value provided for the domain. Changing the website’s A record does not require changing MX.
TXT: policies and verification
TXT records are used for email authentication and many domain-verification mechanisms. A Microsoft 365-only outbound SPF record might look like this:
example.com. TXT "v=spf1 include:spf.protection.outlook.com -all"
DMARC is also stored in TXT records. Our companion guide explains SPF, DKIM, DMARC and PTR and how these email checks work together.
NS: authoritative nameservers
NS records identify nameservers for a DNS zone or delegated subdomain. The parent zone’s delegation determines which authoritative servers the public internet follows. Editing a DNS record at a provider that is not authoritative for your domain will usually have no public effect.
Other useful records: CAA and SRV
CAA can restrict which certificate authorities may issue certificates for a domain. SRV advertises endpoints and ports for certain applications. They address different needs from website address and email routing records.
TTL and why DNS changes take time
Each DNS record has a time to live (TTL), generally measured in seconds. Resolvers can cache DNS answers for a period informed by that TTL. A TTL of 3600 seconds corresponds to one hour.
Suppose you change a website from one IP address to another. A resolver that cached the old answer shortly before the change may keep using it until its cached TTL expires. Another resolver without that old answer can receive the new value immediately.
Is DNS propagation really 24 to 48 hours?
DNS updates do not literally travel one by one around the internet. When the authoritative DNS provider publishes an updated record, fresh queries to that provider can receive the new answer. Other systems may continue using older cached answers until expiration.
Nameserver changes, negative caching, provider distribution, device caches and resolver policies can affect timing as well. That is why a fixed 24–48-hour waiting period is not an accurate description of every change.
How to prepare for a website migration
- Confirm authoritative DNS. Identify which nameservers actually answer public queries.
- Record the current settings. Include A, AAAA, CNAME, MX and mail-authentication records.
- Plan TTL changes early. Lowering a TTL at the moment of cutover does not clear answers already cached under the old TTL.
- Test the destination. Use a preview URL or suitable local DNS override before shifting public traffic.
- Change only the required records. Do not overwrite Microsoft 365 mail settings during a website move.
- Verify afterwards. Check authoritative and public DNS responses, HTTPS, site behaviour and email continuity.
Common questions and misconceptions
If I move my website, does my email have to move?
No. Website address records and email MX records perform separate functions. Your website can move to Webcore while your email remains with Microsoft 365.
Is my DNS provider necessarily my web host?
No. Registration, authoritative DNS, website hosting and mailbox hosting can all be managed separately.
Does changing MX also update SPF?
No. MX routes incoming mail. SPF, DKIM and DMARC are separate authentication mechanisms.
Does clearing my browser cache update DNS for everyone?
No. Browsers, operating systems and recursive resolvers can have distinct caches. Clearing one does not invalidate the others.
Does DNS make my website secure?
DNS locates services. HTTPS, access control, security updates and email authentication protect different aspects of the connection and application. DNSSEC can authenticate DNS answers but does not encrypt a website session.
How Webcore can help
Webcore can manage domain DNS while websites and mailboxes are hosted on separate services. We help with DNS changes, Microsoft 365 mail records, email authentication, planned website migrations and troubleshooting inconsistent resolution.
See also our email authentication guide and Migrate WordPress Without Changing DNS, or contact Webcore for assistance.