How should a DNS entry be formatted to work?
In general, as long as our system does not return an error message when creating a DNS entry, you have generated a “functional” entry. This does not yet mean that the resulting settings correspond to the expected result.
When creating a DNS entry, different parameters must be defined. The entry form looks like this:
Here, you must first choose the entry format (A-Record for website calls, MX-Records for the use of mail servers, TXT-Records for verification entries or parameter configuration, etc.) and then enter the corresponding parameters according to the format.
To ensure basic functionality of the DNS entry, our system automatically completes the domain name whose DNS zone you are modifying (Zone-Apex), so that to create entries for a subdomain such as “www.example-domain.com”, you only need to enter “www” in the “Record Name” field.
The “functional” settings depend heavily on the type of record being processed. Follow the system messages here to adjust missing or incorrect values before saving the zone. You can also contact hosting.fr support at support@hosting.fr about this.
Common DNS record formats with examples
DNS records have two main parts: a record name (the host label inside your DNS zone) and a record value (the target IP address, hostname, or text string). In many DNS panels, including hosting environments where the zone name is appended automatically, you typically enter only the relative record name, such as www, mail, or _acme-challenge. The system then internally builds the full domain name. Correct formatting is record-type specific, so the “value” field must match what the record expects.
Common examples (typical formats):
A record (IPv4): Name: @ or empty (zone apex), Value: 203.0.113.10
AAAA record (IPv6): Name: @ or empty, Value: 2001:db8::10
CNAME record (alias): Name: www, Value: example.net (hostname, not an IP)
MX record (mail routing): Name: @ or empty, Value: mail.example.tld plus a priority value depending on the UI
TXT record (verification/security policies): Name: @ or _acme-challenge, Value: a text string (SPF, DKIM, DMARC, verification token)
These examples reduce confusion between “what goes into name” and “what goes into value,” which is the most common formatting error.
When to use full domain vs relative record names
In DNS zones, the record name can be entered as a relative label (such as www) or as a full domain name (FQDN). In systems that automatically append the zone name, using the relative label is usually correct and avoids duplicating the domain.
Use the following guidance:
Use www to create a record for www.yourdomain.tld
Use mail to create a record for mail.yourdomain.tld
Use _acme-challenge for certificate validation records such as _acme-challenge.yourdomain.tld
Use @ (or leave the name empty if the UI supports it) to create a record for the zone apex, meaning yourdomain.tld itself
Avoid entering the full domain name unless the interface explicitly requires it. A common mistake is entering www.yourdomain.tld in a field where the system will append the zone again, resulting in a broken record such as www.yourdomain.tld.yourdomain.tld. When in doubt, enter the short label and let the DNS editor complete the full name automatically.
Common syntax errors and how to fix them
Most DNS issues are formatting mistakes rather than “wrong DNS.” If a record does not work, check these frequent errors first:
Duplicated domain in the record name
Symptom: records appear with the domain appended twice. Fix: enter only www (not www.example.com) if the editor auto-appends the zone.
Wrong record type for the value
Symptom: using an IP in a CNAME record or a hostname in an A record. Fix: use A/AAAA for IP addresses and CNAME for hostnames.
Missing or incorrect MX target
Symptom: mail delivery issues. Fix: ensure the MX value is a valid hostname and that the priority is set as required.
TXT record formatting issues
Symptom: verification fails (SPF/DKIM/DMARC or third-party tokens). Fix: paste the TXT value exactly as provided. Avoid adding extra quotes unless the provider explicitly instructs you to do so.
Forgetting the required records for a service
Symptom: website works but email validation fails, or a service cannot verify domain ownership. Fix: confirm you created all required records (often multiple TXT/CNAME records).
This checklist helps users correct the most common DNS formatting problems quickly without repeatedly changing unrelated entries.
DNS editing best practices (TTL and propagation expectations)
DNS changes are not always visible immediately because of caching. The key factor is TTL (Time To Live), which controls how long resolvers may cache a record before checking again. Lower TTL values update faster but may increase DNS query volume; higher TTL values reduce queries but can make changes take longer to propagate.
Best practices:
Plan before you change nameservers or migrate services. Copy all records first and lower TTL in advance if you need a fast cutover.
Avoid repeated edits immediately after saving. If you change a record multiple times within a short window, different resolvers may cache other values, making troubleshooting difficult.
Validate changes systematically. Confirm the record is correct in the DNS editor first, then test resolution using reliable methods (for example, checking from more than one network).
Remember that email changes can appear slower. Even when DNS updates, mail systems may retry delivery on their own schedule.
Setting expectations around TTL and propagation prevents unnecessary reconfiguration and helps users troubleshoot calmly and methodically.