Using the DNS Zone Editor in cPanel

With the DNS Zone Editor in cPanel, you can view and—provided the DNS zone is managed via this hosting environment—edit DNS records for a domain. This includes, for example, records for websites, subdomains, email services, or external services.

In CURIAWEB-cPanel you can find the zone editor under Domains → Zone Editor.

In this guide, we will show you how to check DNS records, create new records, edit existing entries, and make changes safely. We also explain the most important record types such as A, AAAA, CNAME, MX and TXT.

Attention: DNS changes can affect not only a website, but also email and other services of a domain. Therefore, do not delete or modify existing entries on suspicion.

What does DNS do? #

DNS - the Domain Name System – connects domain names with the technical destinations and information required for various internet services.

To put it simply, DNS can determine, for example:

example.com
→ Web server

www.example.com
→ Website

mail.example.com
→ Mail server or mail service

TXT record
→ Verification or email policy

Therefore, a DNS zone can contain numerous different entries.

What is a DNS zone? #

A DNS zone contains the DNS records of a domain.

For example, this can store information for the following services:

• Website
• Subdomains
• Email
• Domain Verifications
• Security and Email Policies
• external services

The individual entries are often referred to as DNS Records referred to as.

The cPanel zone editor is only relevant if this DNS zone is actually being used #

Before you change an entry, you should know where the authoritative DNS zone of your domain is managed.

If the domain uses the nameservers intended for this hosting environment, changes in the cPanel Zone Editor may take effect publicly.

If the domain instead uses external nameservers, the publicly used DNS zone may be hosted with a different provider.

Important: A DNS record in the cPanel Zone Editor has no effect on public name resolution if the domain manages its authoritative DNS zone via other nameservers.

Distinguish between nameservers and DNS records #

Nameservers determine which DNS servers are authoritatively responsible for a domain.

The individual records such as A, MX, or TXT are then located within the DNS zone managed there.

Simplified:

Domain
   ↓
Nameserver
   ↓
authoritative DNS zone
   ↓
A / AAAA / CNAME / MX / TXT / other records

1. Log in to cPanel #

Log in to your CURIAWEB cPanel.

Then open:

Domains → Zone Editor

There, the domains whose DNS zones can be managed within your hosting account are displayed.

2. Choose the correct domain #

If there are multiple domains in the hosting account, carefully check which domain you want to edit.

Select the function to manage the DNS zone for the domain in question.

Attention: Check the domain name before making any changes. A technically correct DNS record in the wrong DNS zone does not help and can disrupt another service there.

3. Check existing DNS records first #

Before you create a new record or modify an existing entry, check the existing DNS zone.

Pay special attention to:

• Name or hostname
• Record type
• current value
• TTL

If there is already an entry for the same hostname, you should first clarify what function it serves.

Do not delete DNS records based on their name #

An entry may look unassuming and still be needed for an important service.

A TXT record can be used, for example, for domain verification or email authentication.

An MX record can be crucial for email delivery.

Basic rule: If you don't know what an existing DNS record is needed for, do not change or delete it on suspicion.

The most important fields of a DNS record #

Depending on the type, a DNS record consists of several pieces of information. You will encounter these particularly often:

Field	Meaning
Name	Hostname or name for which the entry applies
TTL	Time that DNS responses can be cached
Type	Type of DNS record, for example A, CNAME, or MX
Record / Target	Value or target of the entry

Which additional fields are displayed depends on the respective record type.

What does TTL mean? #

TTL stands for Time To Live.

In simple terms, the value specifies how long a DNS response may be cached by DNS resolvers before it must be queried again.

The TTL is usually specified in seconds.

For example:

3600

corresponds to one hour.

Practical Tip: Do not change the TTL simply because you are editing a DNS record. The existing or intended setting is often sufficient for normal changes.

A-Record: Point domain to an IPv4 address #

A A-Record maps a hostname to an IPv4 address.

Simplified:

example.com
→ 192.0.2.10

The displayed IP address is just an example.

A-records are frequently used to point domains or subdomains to a web server or other service with an IPv4 address.

4. Create A-Record #

If you need a new A record, select the function to add a new record in the zone editor.

Enter the desired name or hostname.

For example:

shop.example.com

Select as type:

A

and enter the intended IPv4 address as the destination.

For example:

192.0.2.10

Save the record afterwards.

Attention: Use exclusively the IP address intended for the service in question. Do not adopt an IP address from any manual or old screenshot.

5. Check A-record #

Check after saving whether the new record is displayed in the DNS zone.

Check in particular:

• Hostname
• Type A
• IPv4 address
• TTL

AAAA Record: Point hostname to an IPv6 address #

A AAAA record performs a similar task to an A record, but uses an IPv6 address.

Simplified:

example.com
→ IPv6 address

An AAAA record should only point to an IPv6 address at which the service in question is actually intended to be reachable.

Do not simply create an additional AAAA record #

If both A and AAAA records exist for a hostname, clients can use IPv4 or IPv6 depending on the network and configuration.

An incorrect AAAA record can therefore cause the website not to work for certain visitors, or to work unreliably, even though the A record is correct.

Important: Create an AAAA record only if the service is actually provided correctly at the specified IPv6 address.

CNAME: Point a hostname to another hostname #

A CNAME record points one hostname to another hostname.

For example:

www.example.com
→ example.com

The goal here is a hostname and not an IP address.

CNAME is not a browser redirect #

If:

www.example.com

via CNAME to:

example.com

refers, doesn't that mean the browser automatically changes its address from www.example.com on example.com changed.

A CNAME works at the DNS level.

If the URL in the browser needs to change, an HTTP redirect is required.

We explain how to set these up at Set up domain redirection in cPanel.

6. Create CNAME record #

Create a new record in the zone editor.

Enter the desired hostname.

For example:

www.example.com

Choose:

CNAME

and enter the intended destination hostname.

For example:

example.com

Then save the record.

Do not use a CNAME with an IP address #

A CNAME points to a hostname.

If you want to point directly to an IPv4 address, you use an A record.

An AAAA record is used for an IPv6 address.

Check existing records before a CNAME #

DNS rules restrict which other records may exist simultaneously for the same name alongside a CNAME.

Therefore, if other entries already exist for the desired hostname, you should not simply replace them with a CNAME.

Attention: If an external service requires a CNAME, first check the existing records for this exact hostname.

MX Record: Configure Email Delivery #

A MX record determines which mail servers should receive emails for a domain.

MX stands for Mail Exchange.

An MX record typically contains a mail server destination and a priority.

Simplified:

example.com
→ Mail server
→ Priority

Change MX records with extreme caution #

An incorrect MX record can cause incoming emails to no longer arrive at the intended mail service.

Attention: Change MX records only if you know exactly which mail service should be responsible for the domain. A working website does not mean that the MX settings are automatically correct as well.

Priority of MX records #

MX records have a priority value. If multiple MX entries exist, this value is taken into account for the order of delivery attempts.

In doing so, the smaller numerical value higher priority.

For example:

10 mail1.example.com
20 mail2.example.com

In this example, has mail1.example.com the higher priority.

7. Set up MX record only according to specifications #

If you use an external mail service, you will usually receive specific information from them regarding the required MX records.

Take over:

• Mail server destination
• Priority
• if necessary, further required DNS entries

exactly in accordance with the intended configuration.

MX Change and Email Routing #

The MX record and email routing within cPanel are related, but distinct settings.

If emails for a domain are to be processed by an external mail server, the correct routing configuration of the hosting account can be relevant in addition to the DNS settings.

We explain how to check this setting at How to properly set up email routing in cPanel.

TXT Record: Text Information in DNS #

A TXT record stores text information in DNS.

TXT records are used for very different purposes.

This includes, for example:

• Domain Verifications
• SPF
• DKIM
• DMARC
• Verification of external services

The exact content depends on the respective purpose.

Copy TXT values exactly #

If a service provides you with a TXT value, you should copy it exactly according to that service's instructions.

Even small changes can prevent a verification or policy from being recognized.

Important: TXT records often look cryptic. Do not change their content just to make them more „understandable“ or „nicer“.

8. Create TXT record #

Create a new record in the zone editor.

Enter the name or hostname required by the respective service.

Choose:

TXT

and insert the designated TXT value.

Save the entry afterwards.

SPF as TXT record #

SPF policies are commonly published as TXT records today.

Simply put, an SPF record specifies which systems are authorized to send emails for a domain.

An SPF value can, for example, be:

v=spf1

Start.

However, the specific SPF configuration depends on the mail services actually used.

Do not create multiple SPF policies just in case #

If an SPF TXT record already exists and an additional mail service is to be integrated, you should not simply create a second independent SPF policy for the same name.

The existing configuration must be properly adjusted according to the mail services used.

Attention: A new mail service does not automatically mean „add a new second SPF record.“ Check the existing SPF configuration first.

DKIM as a DNS record #

DKIM uses DNS to provide public information that receiving mail servers can use to verify a DKIM signature.

The corresponding DNS name usually contains a so-called selector.

An example of the structure of such a name would be:

selector._domainkey.example.com

The actual values depend on the email service used.

DMARC as a TXT record #

A DMARC policy is typically under a hostname like:

_dmarc.example.com

published.

The TXT value typically begins with:

v=DMARC1

The specific policy should match the actual email configuration of the domain.

Attention: Do not copy SPF, DKIM, or DMARC values from a third-party domain. These settings must match the email services actually used and your own domain.

Verification TXT record of an external service #

Many external services require a DNS record to prove that you own a domain.

You will then receive, for example, a specific TXT name and an individual value.

Apply both pieces of information precisely according to the instructions of the respective service.

9. Edit existing DNS record #

If an existing record needs to be modified, search for it in the DNS zone.

Check before processing:

• Hostname
• Record type
• previous value
• new intended value
• Purpose of the record

Then edit only the actually required setting.

Document the old value before a change #

For important DNS changes, it is advisable to note the previous value or take a screenshot.

This allows you to see later what the configuration looked like before the change.

Practical Tip: Before an important DNS change: document the existing record, then change it. This makes a potential return to the previous configuration much easier.

10. Delete DNS record #

When a record is definitely no longer needed, you can remove it using the zone editor.

Check beforehand which service uses the entry.

You should be especially careful with the following records:

• A and AAAA for active websites
• MX for email
• TXT records for SPF, DKIM, and DMARC
• CNAME for external services
• Verification records

Do not delete an entry just because you don't know it #

A DNS zone can grow over years and contain entries for various services.

Therefore, if you do not know the function of a record, the first step should not be deletion.

First, check whether the service in question is still being used.

11. Save and check DNS changes #

After a change, the new value should be displayed in the zone editor.

Check again:

• correct hostname
• correct record type
• correct target value
• TTL

This ensures that a typo has not already occurred during entry.

DNS changes are not always immediately visible everywhere #

DNS responses can be cached according to their TTL and the resolvers involved.

Following a change, both old and new results may therefore be observed temporarily.

This is often referred to as DNS propagation.

Briefly explained: A DNS change may already be correctly stored on the authoritative DNS server, while another DNS resolver is still using a previously cached value.

There is no fixed „DNS always takes 24 hours“ rule #

How quickly a change becomes visible depends, among other things, on the previous TTL and the DNS caches involved.

A blanket statement that every DNS change fundamentally requires a certain number of hours is therefore incorrect.

TTL becomes relevant before the change #

If an old DNS value has already been cached with a specific TTL, this cache may still be used until it expires.

A subsequent reduction of the TTL does not retroactively remove existing caches.

DNS change during a website migration #

During a hosting change, for example, an A record can be changed from the previous server address to the new one.

Before the change, the website should be fully prepared on the new hosting.

Simplified:

Before:
example.com
→ old server

After:
example.com
→ new server

While existing DNS caches expire, visitors may temporarily still reach different servers.

Prepare website for DNS switch #

When you migrate a website to a new server, you should prepare the files, database, and configuration before the DNS switch, if possible.

This reduces the risk that visitors will reach a server that is not yet fully set up after the DNS change.

Monitor dynamic websites for data changes #

During a server migration, new data may continue to be generated on online shops, forums, or other dynamic websites.

When some visitors still reach the old server and others already reach the new one, data can be created on two different systems.

Therefore, a DNS change should be coordinated with the actual migration for such applications.

Domain still points to the old server after DNS change #

If the change was just made, a DNS cache may still return the previous value.

Therefore, first check whether the new record has been correctly saved in the authoritative DNS.

Do not change the entry back and forth repeatedly just because a single device is still reaching the old server.

The domain points to the correct server, but the wrong website #

If the DNS is already pointing to the correct server but the wrong website is being displayed there, you should check the domain configuration and the document root in cPanel.

We explain how to check this assignment under Add and manage a domain in cPanel.

DNS correct, website still unreachable #

A correct DNS resolution merely proves that the hostname points to the intended technical target.

Nevertheless, the website may not work for other reasons.

This includes, for example:

• wrong document root
• missing website files
• SSL issues
• PHP error
• Web server or application error

DNS is therefore only one level of error analysis.

Point a subdomain to another server via DNS #

A subdomain can point to a different technical service independently of the main domain.

For example:

example.com
→ Server A

app.example.com
→ Server B

The main domain does not also have to be switched to Server B for this.

Run local subdomain in cPanel or externally? #

When a subdomain points to an external service or another server, you should not simultaneously assume that its website is loaded from the local cPanel document root.

The decisive factor is where DNS directs the request.

Create subdomain in cPanel #

If, on the other hand, the subdomain is to have its own website within your web hosting account, the corresponding domain configuration must be present in addition to DNS.

You can find the procedure under Create subdomain in cPanel.

Handle DNS and email with special care #

When making changes to nameservers or DNS zones, the existing email configuration must not be forgotten.

A website can function correctly after a DNS change while emails are no longer delivered if required MX or other mail records are missing.

Attention: When changing a nameserver, the new DNS zone must account for all services that are still required – not just the website.

Changing nameservers is more than just changing an A record #

If you merely change an A record, you are modifying a single DNS entry.

In contrast, during a nameserver change, the responsibility for the entire DNS zone is transferred to other nameservers.

This is a much more invasive procedure.

Before changing a nameserver, all required records of the previous zone should therefore be known.

Add DNS record for an external service #

If an external provider requests a DNS record, you should read their specifications carefully.

Check:

• which record type is required
• which name or host should be used
• what target value is required
• whether a record for the same name already exists
• whether the provider requires a specific TTL

Then transfer the details precisely into the zone editor.

@ as hostname #

DNS instructions from third-party providers often use the character:

@

as a shorthand for the main domain or the zone apex.

However, the specific input in the cPanel Zone Editor may be displayed differently or automatically treated as a fully qualified domain name.

Important: Copy the spelling @ Do not blindly copy into every DNS system from an external guide. Check how the cPanel Zone Editor expects or displays the name of the main domain.

Full hostnames in the zone editor #

cPanel can display DNS names as fully qualified domain names.

For example:

shop.example.com

Check after saving which name is actually displayed in the record.

Period at the end of a DNS name #

In DNS representations, fully qualified domain names may also appear with a trailing dot.

For example:

mail.example.com.

This dot denotes a fully qualified domain name in DNS contexts.

Do not remove or add it on speculation if a service specifies a particular spelling or cPanel displays the value accordingly itself.

Accidentally changed DNS record incorrectly #

If you notice that an incorrect value was saved immediately after a change, restore the previously documented correct value.

Please note, however, that the incorrect value may already have been queried and cached by DNS resolvers.

Even after the correction, differing results may therefore occur temporarily.

Why a screenshot before DNS changes is helpful #

For important changes, a screenshot of the records in question can document the original state.

This is particularly helpful for:

• Mail server migration
• Website migration
• Setup of external services
• Modifying multiple records
• Change nameservers

For extensive changes, you should document not just a single value, but the relevant existing records.

Do not make multiple changes simultaneously without necessity #

If you change A, MX, TXT, and other records at the same time and a problem occurs afterwards, error analysis becomes more difficult.

Therefore, change as few records as possible that are actually required for the respective process.

Practical Tip: The more targeted a DNS change is carried out, the easier it is later to trace which change caused which behavior.

Do not use DNS to forward a URL #

DNS works with hostnames and technical destinations, not with complete URL paths.

An address like:

example.com/alte-seite/

therefore cannot be accessed via a normal A, CNAME, or MX record:

example.com/new-page/

be forwarded.

For URL redirects, you use an HTTP redirect.

DNS cannot process paths #

For example, DNS knows:

shop.example.com

but not the URL path:

/products/product-1/

The processing of such paths only takes place at the web server or application level.

Change DNS record or create domain redirection? #

The right function depends on the goal:

Desired result	Appropriate mechanism
Domain should reach a specific server	DNS
Subdomain should point to an IP address	A or AAAA
Hostname should point to another hostname	CNAME
Email should run through specific mail server	MX and further mail DNS records
Browser should navigate to a different URL	HTTP redirection

Recommended procedure for changing a DNS record #

1. Check where the authoritative DNS zone is managed.
2. Log in to cPanel.
3. Open Domains → Zone Editor.
4. Select the correct domain.
5. Find the relevant record.
6. Check its current purpose and value.
7. Document the previous value.
8. Check the new information.
9. Change only the actually required record.
10. Save the change.
11. Check the saved value.
12. Consider existing DNS caches.
13. Then test the affected service.

Recommended procedure for creating a new DNS record #

1. Check the requirements of the service for which the record is needed.
2. Check if a record for the same hostname already exists.
3. Select the correct record type.
4. Enter hostname and target value exactly.
5. Only change the TTL if there is a specific reason to do so.
6. Save the record.
7. Check the saved view.
8. Wait for existing DNS caches to expire, if necessary.
9. Then check whether the service in question detects the change.

Recommended troubleshooting after a DNS change #

1. Check if the domain actually uses this DNS zone.
2. Check the modified record in the zone editor.
3. Compare hostname, type, and target value with the intended configuration.
4. Consider the previous TTL and possible DNS caches.
5. Check whether only one device or multiple networks are affected.
6. Distinguish between a DNS problem and an error in the actual service.
7. In the event of website problems, subsequently check the domain mapping and document root.
8. In case of email problems, check MX and the further mail configuration in particular.
9. Do not change several other records on suspicion.

Basic rule: In case of DNS problems, first determine which DNS zone is actually authoritative and what value it is returning. Only then should you investigate the website, email, or other services further.

When should you contact support? #

If you are not sure which DNS record needs to be changed or if a service stops working after a DNS change, you should document the current state as accurately as possible.

For an analysis, the following information is particularly helpful:

• affected domain or subdomain
• which service should be set up or modified
• affected record type
• previous value, if known
• new registered value
• Time of change
• whether the nameservers were changed recently
• exact error message or observed behavior
• Specifications of an external service, if one is to be set up

Do not transmit any passwords or other confidential access credentials.

Summary #

You can find the DNS zone editor in the CURIAWEB cPanel under Domains → Zone Editor. There you can view the DNS records of a domain and—provided the DNS zone is actually managed via this hosting environment—edit them.

A A-Record refers to an IPv4 address, a AAAA record to an IPv6 address and a CNAME to another hostname. MX records control email delivery, while TXT Records used among other things for verifications as well as SPF, DKIM and DMARC.

Check what an existing record is needed for before every change, and document the previous value for important changes. Especially MX and TXT records should not be changed on a hunch.

Also note that DNS changes do not necessarily become visible everywhere immediately due to existing caches. Therefore, do not change an entry back and forth repeatedly just because a single device is still using an older value.

The most important rule when working with DNS is: First check jurisdiction and existing record, then make targeted changes and subsequently test the exact service affected.