How to Configure DNS Records Without Guesswork

A domain can be registered, paid for and visible in your account, yet still lead nowhere. The missing piece is usually DNS. When you configure DNS records, you tell browsers where to find your website, mail servers where to deliver messages, and third-party services how to verify your domain.

The details matter. One misplaced character can send visitors to an old server, stop email delivery or prevent a new service from connecting. The good news is that DNS follows a clear logic once you know which record does what and where it should be managed.

Before changing anything, establish where your DNS zone is hosted. This is not always the company where you bought the domain. Your registrar may manage the registration while your hosting provider, website platform or IT partner manages the nameservers and DNS records.

Look at the domain's nameservers first. They identify the service that is authoritative for DNS. Make changes only in that service's DNS control panel. Adding a record at the registrar will have no effect if the domain is using nameservers from another provider.

For a business domain, this check avoids a common and costly mistake: two people update different control panels, while neither change reaches the public internet. Keep a clear record of who owns the domain, who manages its DNS and who can approve changes.

DNS is often described as the internet's address book, but it does more than match a name to an address. Each record type has a specific job.

| Record type | What it does | Typical use | | --- | --- | --- | | A | Points a name to an IPv4 address | A website hosted on a server | | AAAA | Points a name to an IPv6 address | Modern IPv6-enabled hosting | | CNAME | Aliases one hostname to another | `www` pointing to a hosted website name | | MX | Directs email to receiving mail servers | Company email delivery | | TXT | Publishes text-based policy or verification data | SPF, DKIM, DMARC and service verification | | SRV | Defines a service, port and target | Certain telephony and communications services |

An A record may look simple: the host name is `@` or blank for the root domain, and the value is an IP address such as `203.0.113.10`. The `@` symbol generally means the domain itself, for example `example.lu`. A record with `www` as the host applies to `www.example.lu`.

A CNAME works differently. Rather than containing an IP address, it points to another hostname. This is useful when a website platform provides a target such as `customer.hosting-platform.example`. The platform can change its underlying infrastructure without asking you to update an IP address.

There is one important limitation: a hostname with a CNAME should not also have other records. The root domain can be more restrictive too, depending on the DNS provider. If your website provider asks for a root-domain alias, follow its instructions exactly or use the provider's supported alternative.

Treat a DNS change like a short technical deployment, not a quick edit made between meetings. Start by writing down the exact name, record type, value and TTL supplied by the service you are connecting. Copy technical values rather than retyping them, particularly verification strings and mail keys.

First, inspect existing records. You may find an A record for the root domain, a CNAME for `www`, MX records for email and several TXT records. Take a screenshot or export the zone before editing it. This gives you a practical rollback point if the result is not what you expected.

Next, add or amend the requested record. Be precise about the host name. A record entered as `shop` creates `shop.example.lu`; entering the full domain in a panel that automatically appends the domain can accidentally create `shop.example.lu.example.lu`. DNS interfaces vary, so check the preview or resulting record name where possible.

Then save the change and test it. Check both the root domain and `www` if your website should work on both. For email-related changes, test sending and receiving after propagation rather than assuming that a saved record is active.

Avoid deleting existing MX or TXT records unless you understand their purpose. Email often relies on several records at once, and removing a long-standing SPF or DKIM entry can affect delivery and trust. A new email provider may require replacement records, but that instruction should be explicit.

TTL means Time To Live. It tells resolvers how long they may cache a DNS answer before asking again. A TTL of 3,600 seconds means up to one hour of caching under normal conditions.

For stable records, a longer TTL reduces repeated lookups and is usually fine. Before a planned website or mail migration, lowering the TTL one or two days in advance can help changes appear sooner after the switch. Do not expect it to clear caches instantly: resolvers that already stored the old answer may keep it until the previous TTL expires.

After the migration is confirmed, set the TTL back to a sensible standard value. Very low TTLs are not automatically better. They create more lookups and do not solve configuration mistakes.

A reliable website setup normally considers both `example.lu` and `www.example.lu`. Choose one as the public, preferred address and redirect the other at the web server or website platform level. DNS can point both names to the right destination, but DNS itself does not perform web redirects.

If you host a website on your own server, you will commonly use an A record for the root domain and either an A record or CNAME for `www`. If you use a hosted platform, it may provide a specific A record, CNAME or a combination of records. Follow the platform's values exactly, including any verification record it requests.

Be careful when changing an existing A record. If the domain also supports email, changing website records should not require changes to MX records. Keeping these functions separate reduces the chance that a website move interrupts business communication.

Email records are less forgiving because delivery depends on several systems agreeing. MX records tell other mail servers where to send messages. Their priority values matter: lower numbers are preferred. If a provider supplies two MX records, both are normally required for resilience.

TXT records often handle authentication. SPF identifies which servers may send email for your domain. DKIM publishes a public key that receiving systems use to validate signed messages. DMARC sets your policy for messages that fail authentication and can provide reporting.

These records are related, but they are not interchangeable. Most domains should have only one SPF record. If more than one service sends mail - for example Microsoft 365, a marketing platform and a helpdesk - their permitted sources normally need to be combined into a single SPF value. Simply adding a second SPF TXT record can cause SPF to fail.

DKIM host names are often long and include a selector, such as `selector1._domainkey`. Do not remove the selector or quotation marks if your DNS control panel displays them. For DMARC, begin with a monitoring policy if you are still assessing legitimate sending sources. A strict reject policy is valuable once the configuration is proven, but applying it too early can block valid messages.

Website tools, cloud applications and communications platforms frequently ask you to add a TXT or CNAME record to prove domain ownership. These records may look temporary, but do not remove them immediately after verification unless the service confirms that removal is safe. Some services check again later.

Verification values are case-sensitive in practice because they are exact tokens. Preserve every character. If a value seems too long for one field, use the format specified by the service and the DNS provider rather than splitting it on your own.

A successful save message only confirms that the control panel accepted your entry. It does not prove that the public DNS response is correct. Use a DNS lookup tool or command-line query to inspect the record returned for the exact hostname and type. Check that it matches the intended value, not merely that a record exists.

If the result is wrong, review the nameservers, host name and record conflicts before making further changes. If the result is still old, allow for the TTL and cached responses. Repeatedly deleting and recreating records rarely speeds this up and can introduce new errors.

For organisations relying on hosted email, business telephony or customer-facing services, schedule material DNS changes during a controlled window and keep the previous values ready. DNS is foundational infrastructure: a careful five-minute check is worth more than a rushed fix later.

If you need a second pair of eyes, Visual Online's in-house team can help clarify what belongs in your DNS zone and what should remain untouched. The best DNS configuration is rarely the most complicated one - it is the one that is documented, tested and easy to maintain when your services change.