Find cheap domain names for your website - namesilo.com
Namesilo Blog
Blog
DNS8 min

DNS 101: The Four Records You'll Actually Use

NS
NameSilo Staff

11/27/2025
Share
When you register a domain, you gain access to a DNS management dashboard that might look intimidating at first. Rows of cryptic acronyms, dropdown menus with options like A, AAAA, CNAME, and dozens of other record types can make you wonder if you need a networking degree just to get your website running.
The good news? For most everyday scenarios, you'll only work with four DNS record types. Understanding these four records will cover 95% of what you need to do with your domain.

Why DNS Records Matter

Think of DNS records as a directory that tells the internet where to find different services connected to your domain. When someone types your domain into their browser, or sends you an email, DNS records guide that request to the right destination. Each record type handles a specific job, and knowing which one to use makes configuration straightforward rather than overwhelming.

The Four Essential DNS Records

A Record: Pointing Your Domain to a Website

The A record (Address record) is the most fundamental DNS entry you'll configure. It maps your domain name to an IPv4 address, which is the numeric location of your web server.
When you'll use it: Setting up a website, pointing your domain to a server, or directing a subdomain to a specific service.
Common setup:
  • @ (apex domain) → 192.0.2.1
  • www192.0.2.1
The @ symbol represents your root domain (example.com), while subdomains like www or blog get their own entries. Most people create separate A records for both the root and www subdomain, ensuring visitors reach your site whether they type "example.com" or "www.example.com."
The biggest gotcha: Not setting up both the apex and www subdomain. If you only configure one, visitors who type the other version will see an error. Many hosting providers give you a single IP address to use for both records.

CNAME Record: Creating Aliases and Subdomain Shortcuts

A CNAME (Canonical Name) record creates an alias that points one domain name to another. Instead of pointing to an IP address like an A record, it points to another domain name.
When you'll use it: Routing subdomains to external services, setting up CDN configurations, or managing multiple subdomains that should follow a primary destination.
Common setup:
  • wwwexample.com
  • bloghosting-provider.com
  • shopmystore.shopify.com
CNAMEs are particularly useful when working with platforms that manage their own infrastructure. If your e-commerce platform changes their server IP addresses, your CNAME continues working without any updates needed on your end.
The biggest gotcha: You cannot create a CNAME record at your apex domain (the root domain itself). This is a DNS protocol limitation. If you try to set @ as a CNAME, it will either fail or break other essential records like MX records for email. Some DNS providers offer "CNAME flattening" or "ANAME records" as workarounds, but these are proprietary solutions. For standard compatibility, use A records at the apex.
Another common issue: CNAME records cannot coexist with other record types for the same name. If you create a CNAME for www, you cannot also have an A record or MX record for www.

MX Record: Routing Your Email

MX records (Mail Exchange records) tell other mail servers where to deliver email for your domain. Without properly configured MX records, you won't receive email at your domain.
When you'll use it: Setting up domain-based email, migrating email providers, or configuring a new mail service.
Common setup:
Priority 10: mail.example.com
Priority 20: mail-backup.example.com

The priority number (sometimes called preference) determines which server receives mail first. Lower numbers have higher priority. If your primary mail server is unavailable, the sending server tries the next priority level.
The biggest gotcha: Forgetting to remove old MX records when switching email providers. If outdated MX records remain active, some of your email might get delivered to the wrong server, creating confusion and potentially losing messages. When changing providers, delete the old records rather than just adding new ones.
Also, MX records must point to a domain name (which has an A record), not directly to an IP address. Setting your MX record to point to mail.example.com is correct, but pointing it to 192.0.2.5 will not work.

TXT Record: Verification, Authentication, and Configuration

TXT records store text information in your DNS and serve multiple purposes. They're the Swiss Army knife of DNS records, handling everything from domain ownership verification to email security policies.
When you'll use it: Verifying domain ownership, configuring email authentication (SPF, DKIM, DMARC), setting up third-party services, or adding security policies.
Common setup:
SPF: "v=spf1 include:_spf.google.com ~all"
DKIM: Selector._domainkey → "v=DKIM1; k=rsa; p=MIGfMA0..."
DMARC: _dmarc → "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
Verification: "google-site-verification=abc123xyz"

SPF records specify which servers are allowed to send email on behalf of your domain. DKIM adds a digital signature to your outgoing mail. DMARC tells receiving servers what to do with messages that fail authentication checks. Together, these three records dramatically improve your email deliverability and protect against spoofing.
The biggest gotcha: Creating multiple SPF records. DNS allows multiple TXT records for a domain, but SPF specifically requires only one SPF record. If you need to authorize multiple email services, include them all in a single SPF record using multiple include: statements. Having two separate SPF records will cause both to be ignored.
Also, TXT records have syntax requirements. Missing quotes, incorrect formatting, or typos can break functionality entirely. Always copy and paste configuration values from your service provider rather than typing them manually.

Understanding TTL and DNS Propagation

Every DNS record includes a TTL (Time To Live) value, measured in seconds. This tells other DNS servers how long to cache your record before checking for updates. A TTL of 3600 means DNS servers will store your record for one hour before requesting fresh data.
When you make DNS changes, propagation isn't instantaneous. If your previous TTL was 86400 (24 hours) and you update a record, some DNS servers might serve the old information for up to 24 hours because they cached it. This is why you'll see advice to lower your TTL before making major changes, then raise it again afterward.
Practical tip: Before migrating hosting providers or switching email services, reduce your TTL to 3600 (1 hour) a day in advance. Make your changes, verify everything works, then increase the TTL back to default or higher to reduce DNS query load.

Working in Your DNS Dashboard

Most registrars, including those offering domain registration, provide a DNS management interface where you can add, edit, and delete records. The interface typically asks for:
  • Type: The record type (A, CNAME, MX, TXT)
  • Host/Name: The subdomain or @ for apex
  • Value/Answer: The destination (IP address, domain name, or text string)
  • TTL: How long to cache the record
  • Priority: Only for MX records
When adding records, the host field can trip people up. If you want to create a record for blog.example.com, you typically enter just blog in the host field, not the full blog.example.com. The registrar automatically appends your domain name. Some systems use @ to represent the root domain, while others leave the host field blank.

Common DNS Setup Scenarios

Setting up a new website:
  1. Get your server IP address from your hosting provider
  1. Create an A record for @ pointing to that IP
  1. Create an A record for www pointing to the same IP
  1. Wait for DNS propagation (usually 15 minutes to a few hours)
Configuring email:
  1. Get MX record details from your email provider
  1. Add the MX records with correct priorities
  1. Add SPF, DKIM, and DMARC TXT records for authentication
  1. Test email delivery after propagation completes
Adding a third-party service:
  1. The service provides specific DNS records to add
  1. Usually includes a TXT record for verification
  1. May include CNAME records for subdomains (like app.example.com)
  1. Verify within the service's dashboard after changes propagate

Troubleshooting DNS Issues

Website not loading: Check that your A records point to the correct IP address. Verify both the apex and www subdomain. Use a DNS lookup tool to confirm the records are visible publicly.
Email not working: Confirm MX records are correct and point to valid mail servers. Make sure you removed old MX records if you changed providers. Check that your email provider is actually receiving the mail (their end might have issues).
Verification failing: Double-check that TXT records are entered exactly as provided, including quotes and special characters. Even an extra space can cause verification to fail. Some systems require the full domain in the host field for TXT records; others want just the subdomain.
Changes not taking effect: Remember TTL and propagation. If you just made changes, wait at least as long as your previous TTL value. Clear your local DNS cache (on Windows: ipconfig /flushdns, on Mac: sudo dscacheutil -flushcache).

DNS Best Practices

Document your changes: Keep notes about why you added specific records and when. Six months later, you'll have forgotten which TXT record belongs to which service.
Lower TTL before major changes: This reduces how long old, incorrect information stays cached during migrations.
Don't delete records you don't recognize: Research them first. Some services add records automatically, and removing them could break functionality.
Use separate records for separate services: Don't try to combine multiple services on one subdomain. Give each service its own subdomain with appropriate records.
Test after changes: Use tools like dig, nslookup, or online DNS checkers to verify records are set correctly and propagating.
Enable DNSSEC if available: This adds cryptographic signatures to your DNS records, preventing certain types of attacks. Not all registrars support it, but it's worth enabling if yours does.

Moving Beyond the Basics

Once you're comfortable with these four record types, you might encounter situations that need additional records:
  • AAAA records: Like A records but for IPv6 addresses
  • NS records: Nameserver records that delegate DNS control
  • SRV records: Service records for specific protocols
But for most domain owners, mastering A, CNAME, MX, and TXT records provides everything needed to run websites, receive email, integrate services, and maintain a professional online presence. The key is understanding what each record does, where it can be used, and the common pitfalls to avoid.
With this foundation, your DNS dashboard transforms from an intimidating grid of options into a straightforward control panel where you confidently route traffic, configure services, and maintain your domain infrastructure.
ns
NameSilo StaffThe NameSilo staff of writers worked together on this post. It was a combination of efforts from our passionate writers that produce content to educate and provide insights for all our readers.
More articleswritten by NameSilo
Jump to
Smiling person asking you to sign up for newsletter
Namesilo Blog
Crafted with Care by Professionals

Millions of customers rely on our domains and web hosting to get their ideas online. We know what we do and like to share them with you.

This newsletter may contain advertising, deals, or affiliate links. Subscribing to a newsletter indicates your consent to our Terms of Use and Privacy Policy. You may unsubscribe from the newsletters at any time.