DNS records explainedA, AAAA, CNAME, MX, TXT, SRV and TTL

Published on October 20, 2026

What DNS records are for

The nameservers of your domain hold a zone - a list of records that answer queries. Every record consists of four parts: name (the subdomain or @ for the domain itself), type, value and TTL.

At MainHoster.de, you set these records in the web interface. Available are A, AAAA, CNAME, MX, TXT, PTR and SRV. In the subdomain field, you enter the name - www, mc or @ for the domain itself.

The record types at a glance

Values that point to a name end with a dot in the zone file. Our web interface adds it automatically for MX and CNAME targets - with other providers, it has to be added by hand.

A and AAAA: the standard cases

The A record is the record you need most often. It points from a name to an IPv4 address:

@     A     185.119.117.42
www   A     185.119.117.42

The AAAA record does the same for IPv6. Both may exist in parallel - modern clients then prefer IPv6 and fall back to IPv4 in case of problems. For your own server, see Point a domain to a VPS.

CNAME: one name points to another

A CNAME is an alias. Instead of maintaining the IP in two places, www simply points to the main domain:

www   CNAME   yourcompany.com.

Two rules that often trip people up: a CNAME must not be on the domain itself (@) if MX or NS records are also there - the standard forbids it. And next to a CNAME, no other record may exist for the same name.

MX: deliver email

The MX record tells sending mail servers who accepts mail for your domain. The number in front is the priority - if there are several MX records, the lower value wins:

@   MX   10 mail.yourcompany.com.

In our web interface, you only enter the target. It sets the priority automatically, and one MX record per name is provided - that is enough for almost all mail providers, including Google Workspace and Microsoft 365.

Important: an MX must point to a name, never directly to an IP address, and this name needs its own A record. Details in the guide Use a domain for email.

TXT: SPF, DKIM and DMARC

TXT records hold arbitrary text. In practice, they almost always contain three things that prevent your mails from landing in spam:

• SPF - which servers may send for your domain: v=spf1 mx -all
• DKIM - the public key with which recipients check your mails' signature. It lives on its own subdomain such as default._domainkey.
• DMARC - what should happen to mails that fail SPF and DKIM: v=DMARC1; p=quarantine; rua=mailto:dmarc@yourcompany.com

A second use: many services let you prove via a TXT record that the domain belongs to you - such as Google Workspace and Microsoft 365 or Discord for linking it to your profile.

SRV: service, host and port

An SRV record also names the port in addition to the target. That is exactly why it is the solution when players should reach your game server without entering a port. The name follows the pattern _service._protocol, and the target must be a name with its own A record:

mc                   A     185.119.117.42
_minecraft._tcp.mc   SRV   0 0 25565 mc.yourcompany.com.

With us, you do not have to build either by hand. If you choose the type SRV, the game server wizard only asks for subdomain (or @ for the domain itself), server type, IP and port - the web interface creates the SRV and A records automatically. For Minecraft and TeamSpeak 3, an SRV record is created; for all other games, an A record, because their clients do not query SRV. Details in SRV record for Minecraft.

TTL: why changes do not take effect immediately

The TTL defines in seconds how long resolvers may cache an answer. Typical values are 3600 (one hour) to 86400 (one day). At MainHoster.de, it is fixed at 86400 seconds for all records.

• New records are hardly affected - there is no old answer in the cache yet, and they are usually reachable after a few minutes.
• Changed records can take up to 24 hours until all resolvers know the new value. So plan switches with a day's lead time and keep the old server running until then.
• If you move to us from another provider, it is worth lowering the TTL there a day or two beforehand. Then the switch takes effect faster.
• When changing nameservers, the TTL only helps to a limited extent - the delay via the registry also applies there, see Change nameservers.

Typical mistakes

• MX points to an IP address: not allowed. Create an A record first, then let the MX point to it.
• CNAME on the main domain: breaks MX and NS. An A or AAAA record belongs on @.
• Several SPF records: only one is allowed per domain, otherwise the check is invalid. Several senders belong in one record.
• Missing dot at the end: without a trailing dot, the nameserver appends the domain again - mail.yourcompany.com becomes mail.yourcompany.com.yourcompany.com. With us, the web interface adds the dot itself for MX and CNAME; with other providers, not always.
• Giving up too early: before the TTL expires, your resolver still delivers the old value. Wait first, then keep adjusting.

Frequently asked questions