Most DNS outages have nothing to do with a failed server. They come from one badly written record: a second record added by a new mail provider that breaks authentication for every message, a CNAME at the apex that the panel rejects, or a missing trailing dot that turns your mail server into a name that doesn’t exist. This is a practical reference for the records in your : what each one does, how to write it, which TTL suits it, the mistake that keeps coming back with it, and how to check it with dig. The examples use DNS Console, Illevante’s platform for managing domains and their zones, but the rules are the same with any provider.
01A record in four fields
Every record in the zone has four fields: name, type, TTL and value. The name is either the itself, written as @ in zone files, or a subdomain such as www or shop. In DNS Console you open the domain’s zone and edit its records in a single table, each type with its own fields, and every save is applied instantly on Illevante’s name servers.
Watch the difference between a relative name and a . In zone-file syntax, a name that ends with a dot is read as is, and a name without one gets the domain appended automatically. Write an MX value as mail.ahweh-alhamra.com without the dot, and it becomes mail.ahweh-alhamra.com.ahweh-alhamra.com. Panels differ in how they treat that dot, so don’t assume: check the final value after every save.
DNS Console supports thirteen record types: A, AAAA, CNAME, ALIAS, DNAME, MX, TXT, SRV, NS, PTR, CAA, DS and TLSA. Here we go through the ones almost every domain needs.
02Addresses: A, AAAA and CNAME
An A record maps a name to an IPv4 address, and AAAA maps it to an IPv6 address. One name may hold several A records, which spreads requests across the addresses, but that isn’t real load balancing: DNS doesn’t know when one of the servers is down, and keeps handing out its address.
A CNAME makes a name an alias of another name, such as pointing www at the apex, or shop at an external store platform. It comes with a strict rule: a name that holds a CNAME holds no other record. That’s why a CNAME isn’t allowed at the apex, which always carries SOA and NS records, and usually MX and TXT too. If an external platform asks you to point your apex at one of its names, use an ALIAS record in DNS Console: it works like a CNAME but answers with the target’s addresses, so it can live at the apex alongside the other records.
And a second rule many people break: never point MX or NS at a name that holds a CNAME, or at an IP address. Their target must be a name with its own A or AAAA record.
03Mail and verification: MX and TXT
An MX record names the mail servers that receive your domain’s email, each with a priority number: the lowest is tried first, and equal numbers share the mail. With 10 on a primary server and 20 on a backup, mail only goes to the backup when the first can’t be reached.
A TXT record is free text, used by three mail security standards and by many platforms to prove you own the domain:
- SPF: At the apex, it starts with v=spf1 and lists the servers allowed to send as your domain. A domain has exactly one SPF record, and the mechanisms that trigger lookups, such as include, a and mx, must not exceed ten lookups in total.
- DKIM: Under a name such as sel1._domainkey, it holds the public key receiving servers use to verify your messages’ signature. A 2048-bit RSA key is longer than 255 characters, so it’s split into several strings inside the same record, not into two records.
- DMARC: Under the name _dmarc, it tells receivers what to do with a message that fails authentication, and where to send reports. Start with p=none and a reporting address, then move to quarantine and reject once you’re sure every source of your mail is signed.
- Ownership proof: Tokens requested by platforms such as Google and Microsoft, and sometimes by certificate authorities. Add each one as a separate record, and never merge it into your SPF record.
Since February 2024, Gmail and Yahoo require every sender to pass SPF or DKIM, and anyone sending around 5,000 messages a day or more to have both SPF and DKIM plus a DMARC record, even at p=none. DNS Console has ready-made templates that write your mail provider’s records for you, which cuts typing mistakes. Mail setup and sender reputation are covered in detail in separate articles on the blog.
04Services, certificates and delegation: SRV, CAA and NS
An SRV record tells applications which server and port a service runs on. Its name combines the service and the protocol, such as _submission._tcp for sending mail, and its value has four parts: priority, weight, port and target. That’s how a mail client finds its settings on its own when the user types an address, and voice services and some games rely on it too.
A record lists the certificate authorities allowed to issue SSL certificates for your domain. Every CA must check it before issuing, and refuses if its name isn’t there. Add an issue line for each CA you actually use, including the one your hosting panel gets its automatic certificates from, and an iodef line so you’re alerted to every refused attempt. Certificates and their chain are covered in a separate article on the blog.
NS records at the apex declare the name servers responsible for your domain, and they must match what you set at the registrar. Add NS records to a subdomain such as lab, and you delegate that name and everything under it to other servers, such as your development team’s. If your domain is registered elsewhere, managing it from DNS Console starts with adding all its records to the platform, then setting Illevante’s two name servers at the registrar.
PTR records live in the reverse zone of an IP address, not in your domain’s zone, and mail servers ask for them to match the sender’s address with its name. In DNS Console you manage reverse zones and PTR records for IPv4 and IPv6 addresses, provided the owner of the address block has delegated its reverse zone to you; otherwise, ask your server provider to set the record.
A complete zone for a small shop
Here’s the zone of a small coffee shop in Beirut in zone-file syntax. The apex SOA and NS records are written by the name server operator, so we left them out:
# Names ending with a dot are fully qualified; others get the domain appended$ORIGIN ahweh-alhamra.com.@ 3600 IN A 203.0.113.20@ 3600 IN AAAA 2001:db8:20::20www 3600 IN CNAME ahweh-alhamra.com.shop 300 IN A 198.51.100.45@ 3600 IN MX 10 mx1.mailhost.example.@ 3600 IN MX 20 mx2.mailhost.example.@ 3600 IN TXT "v=spf1 include:_spf.mailhost.example ~all"# The key is shortened here; your mail provider gives you the full onesel1._domainkey 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."_dmarc 3600 IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"_submission._tcp 3600 IN SRV 0 1 587 smtp.mailhost.example.@ 86400 IN CAA 0 issue "sectigo.com"@ 86400 IN CAA 0 iodef "mailto:[email protected]"lab 86400 IN NS ns1.devhost.example.
05A TTL strategy for each record
The TTL sets how long resolvers keep an answer before asking again, which means how long your visitors wait for any change. There’s no single right value: pick it by how likely the record is to change and how costly the wait would be.
| Record or situation | Suggested TTL | Why |
|---|---|---|
| NS and subdomain delegations | 86400 | Rarely change; a high value cuts lookups and the impact of a brief outage |
| A, AAAA and CNAME for a stable site | 3600 | A balance between change speed and query volume |
| A during a server move or switch | 300 | Visitors follow the new address within minutes |
| MX | 3600 to 14400 | Mail servers rarely change, and the sending server retries on failure |
| TXT for mail and ownership proof | 3600 | Frequent edits during setup, then stable |
| CAA | 3600 to 86400 | CAs only read it at issuance |
Before any planned change, lower the record’s TTL to 300 ahead of it by at least its old value, then restore it once things settle. Why the old TTL sets the wait, along with negative caching and name server changes, is covered in a separate article on the blog about DNS propagation. And after every save in DNS Console, propagation monitoring shows you which resolvers have the new answer and which are still waiting for their TTL to expire.
06Common mistakes and how to spot them
- ProblemYour mail is rejected or lands in spam after adding a new provider, and the apex has two SPF records
- FixTwo records make every SPF check an error (permerror). Merge them into one record that combines the providers’ include mechanisms, and keep it within ten lookups.
- ProblemThe panel refuses to add a TXT or MX to a name, or the name breaks after you add it
- FixThe name holds a CNAME, and a CNAME can’t share its name with another record. Move the other record to a different name, or replace the CNAME with an A record, or with an ALIAS at the apex.
- ProblemAn MX or CNAME value shows up doubled in dig, such as mail.ahweh-alhamra.com.ahweh-alhamra.com
- FixA full name was written without its trailing dot. Add the dot, or enter only the relative part, depending on what the panel expects.
- ProblemSome sending servers won’t deliver, and MX points to an IP address or to a name with a CNAME
- FixPoint MX at a server name that has its own A or AAAA record.
- ProblemDMARC reports never arrive, and checkers say the domain has no policy
- FixThe record sits at the apex instead of under _dmarc. Move it to _dmarc.
- ProblemA certificate issuance or automatic renewal fails after adding CAA
- FixThe CA that issues your certificates isn’t listed. Add an issue line for it, then try again.
Before you declare everything working, ask your domain’s name servers directly, with no cache between you and them:
# The first name server responsible for your domainNS=$(dig +short NS ahweh-alhamra.com | head -n1)dig @$NS ahweh-alhamra.com MX +noall +answer# Number of SPF records: the output must be 1dig @$NS ahweh-alhamra.com TXT +short | grep -c "v=spf1"dig @$NS _dmarc.ahweh-alhamra.com TXT +shortdig @$NS sel1._domainkey.ahweh-alhamra.com TXT +shortdig @$NS ahweh-alhamra.com CAA +shortdig @$NS _submission._tcp.ahweh-alhamra.com SRV +short# The MX target must return an address directly, not a CNAMEdig mx1.mailhost.example A +noall +answer
Then check the picture from outside your network with Illevante’s DNS propagation check, which asks points around the world, from Dubai, Riyadh and Cairo to Frankfurt and Tokyo, and compares each answer with your domain’s authoritative name servers.
07Before you press “Save”
Copy the current zone before any major edit: it’s your only way back. Change one thing at a time, and check it with dig before the next. Keep a single SPF record, never put a CNAME at the apex, and write fully qualified names with their dot where they’re required. Set the TTL to an hour for most records and a day for NS and CAA, and lower it ahead of any planned move.
If you keep your domains in DNS Console, the ready-made templates write your mail records for you, and you can build your own template and apply it to many domains at once, so manual typing mistakes don’t repeat. The platform is an annual subscription that includes all thirteen record types, PTR records and propagation monitoring.
