Setting Up DNS Records (A, CNAME, MX, TXT) Explained

DNS records are the lookup table that turns domain names into the actual servers your traffic should reach. Most customers only need to touch four record types: A, CNAME, MX, and TXT. This guide explains what each does, when you need them, and the exact values for the most common real-world scenarios.

The record types, in plain terms

Where to edit DNS records on iWebVault

If your domain uses iWebVault nameservers (ns1.iwebvault.com, ns2.iwebvault.com), the DNS records are managed in your control panel:

• cPanel: Domains → Zone Editor → click Manage next to the domain.
• DirectAdmin: Account Manager → DNS Management → select the domain.

If your domain uses a different DNS provider (Cloudflare, your registrar’s DNS, etc), you’ll add records there instead. The record syntax is identical everywhere — only the UI differs.

A record — pointing your domain to your server

This is the most fundamental record. It says “the IP for yourdomain.com is 185.123.45.67“.

• Type: A
• Host: @ (or leave blank — means the root domain itself)
• Value: 185.123.45.67 (your server IP, from welcome email)
• TTL: 14400 (4 hours, default) — fine in most cases

You’ll often have multiple A records:

If your account is on iWebVault, these are usually auto-created when you set up the domain. Edit only if your IP changes.

CNAME record — aliases between hostnames

A CNAME says “this hostname is just another name for this other hostname”. Common pattern: www.yourdomain.com as a CNAME for yourdomain.com (instead of two A records).

• Type: CNAME
• Host: www
• Value: yourdomain.com. (note the trailing dot — required in most DNS systems)

CNAMEs are useful for third-party services that need a stable hostname pointing at them:

• shop.yourdomain.com CNAME to your Shopify-provided hostname.
• docs.yourdomain.com CNAME to your Notion/Bookstack hostname.
• links.yourdomain.com CNAME to your URL shortener.

Important rule: CNAME records cannot exist on the root domain (@). If you need the root to point at a hostname, use an A record (or ALIAS/ANAME if your DNS provider supports it).

MX records — where email goes

MX records tell other mail servers “send mail for this domain to these hosts”. Each MX record has a priority — lower numbers are tried first.

If you use iWebVault for email (cPanel/DirectAdmin standard setup):

• Type: MX
• Host: @
• Priority: 0
• Value: mail.yourdomain.com.

If you use Google Workspace:

Critical: only one mail provider at a time. If you point MX at both iWebVault and Gmail, mail delivery becomes random. Pick one.

TXT records — verification and authentication

TXT records hold arbitrary text. They’re used for two main purposes: verifying ownership of a domain (Google, Microsoft, Cloudflare, etc., ask you to add a TXT record to prove you control the domain), and email authentication (SPF, DKIM, DMARC).

Domain verification example (Google Search Console)

• Type: TXT
• Host: @
• Value: google-site-verification=AbCdEf123456... (provided by Google)

SPF (Sender Policy Framework)

• Type: TXT
• Host: @
• Value: v=spf1 +a +mx +ip4:185.123.45.67 ~all (use your actual server IP)

You can only have one SPF record per domain. If you also use Mailchimp or another sender, merge their include: directive into the same record. See the full deliverability guide.

DKIM

• Type: TXT
• Host: default._domainkey
• Value: the long v=DKIM1; k=rsa; p=... string provided by cPanel/DirectAdmin Email Deliverability

DMARC

• Type: TXT
• Host: _dmarc
• Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

A complete example zone

For a typical WordPress site on iWebVault with email, your DNS zone would look like:

That’s the standard set for a hosted site with working email and authentication. Everything else (subdomains, services, custom apps) goes on top of this baseline.

DNS propagation

DNS changes don’t go live instantly. They propagate from your authoritative DNS server outward to caches around the world. Most changes show globally within 1-2 hours; some can take up to 48.

Speed up propagation:

• Lower the TTL before making a change. Set to 300 (5 minutes), wait the old TTL to expire, then make your change. After it propagates, raise TTL back to 3600+.
• Test from multiple locations: whatsmydns.net shows your record’s status from servers worldwide.
• Clear your local DNS cache: ipconfig /flushdns (Windows) or sudo dscacheutil -flushcache (macOS) — useful for testing your own changes.

Common DNS mistakes

Forgetting the trailing dot in record values. Some DNS systems require it (yourdomain.com.), others add it automatically. If the record breaks after saving, try toggling it.

Multiple SPF records. Causes silent SPF failures. Merge into one record.

CNAME at the root domain. Not allowed. Use A record (or ALIAS if supported).

Editing DNS at the wrong place. If your registrar is Namecheap but your nameservers are Cloudflare, edits made at Namecheap have no effect. Find where your nameservers point and edit there.

What’s next

• Domain not resolving even after DNS changes? Troubleshooting guide.
• Transferring a domain? Transfer vs nameserver change.
• Setting up email authentication? Email deliverability guide covers SPF, DKIM, DMARC in detail.

Once you’ve set up the standard zone above, you’ll rarely need to touch DNS again unless adding a new service. Most domains run on the same handful of records for years.