DNS Records Explained: A, AAAA, CNAME, MX, TXT, and SRV

DNS Records Explained: A, AAAA, CNAME, MX, TXT, and SRV

A working understanding of six DNS record types covers nearly everything an SMB ever needs to look at in a domain control panel. Each record answers one specific question about your domain: which server hosts the site, which provider receives email, which third-party service is allowed to send on your behalf, and which protocol endpoint a client should connect to. With the patterns in this post in your head, the registrar dashboard stops being a black box and becomes a short, readable list you can edit with confidence.

This guide walks through the six record types you will actually use - A, AAAA, CNAME, MX, TXT, and SRV - with a plain-English explanation, the real-world job each one does, and the syntax you will see in any DNS panel.

How DNS Records Work (Quick Mental Model)

DNS is the directory layer that maps human-readable domain names to the resources behind them. Each record in a domain's zone is a single entry with four parts: a host (the root @ or a subdomain), a record type, a value, and a TTL (time-to-live, in seconds, that controls how long resolvers cache the answer).

When a browser, mail server, or app needs to reach example.com, it asks the domain's authoritative name servers for records of a specific type. The name server returns the matching values and the TTL. A clean DNS zone has the minimum number of records doing the maximum amount of work, with each one labeled clearly enough that a future admin can tell what it is for.

A Records (Address Records)

How ScaleIT handles this: See plans and pricing

An A record points a hostname to an IPv4 address. This is the most common record type and the one most people picture when they think "DNS."

The job: send example.com or www.example.com to your web server's public IPv4 address.

Pattern:

@         A    203.0.113.10
www       A    203.0.113.10

A records are used any time a service is hosted at a fixed IPv4 address - a VPS you run, a static-site host that gives you a dedicated IP, or a load balancer in front of an application server. Cloud providers and managed hosts often prefer that you use a CNAME instead, because their underlying IPs change. When a host gives you a literal IP to enter, it is an A record.

AAAA Records (IPv6 Address Records)

AAAA records do the same job as A records, but with IPv6 addresses instead of IPv4. The "AAAA" name reflects that an IPv6 address is four times the size of an IPv4 one.

Pattern:

@    AAAA    2001:db8::1

For most SMB sites, the host either provides a recommended AAAA value alongside the A record or handles dual-stack DNS automatically when you point your domain at them. If your host publishes both A and AAAA values, keep both: the resolver returns the right one for each visitor based on the network they are on.

CNAME Records (Canonical Name Records)

A CNAME points one hostname at another hostname instead of at an IP address. It is an alias.

The job: say app.example.com is really mycompany.lovable.app, or blog.example.com is really a Webflow or HubSpot host. The destination provider can swap their underlying IPs whenever they want, and your DNS keeps working without any changes on your end.

Pattern:

app      CNAME    mycompany.lovable.app
blog     CNAME    proxy-ssl.webflow.com

One hard rule: a CNAME cannot live at the root of a domain alongside other records. The DNS spec forbids it, which is why providers tell you to use www for CNAMEs and a different record type at the root. Some managed DNS platforms (Cloudflare, AWS Route 53, NS1) offer proprietary apex flattening that makes this look like a CNAME at the root, but under the hood they are returning A and AAAA records.

MX Records (Mail Exchanger Records)

MX records tell the world which servers receive email for your domain. Every email sent to you@example.com triggers an MX lookup before the message is delivered.

Each MX has a priority number, and the lowest priority wins. Higher numbers serve as backups when the primary is unreachable. For Google Workspace, Microsoft 365, Fastmail, Zoho, and most modern providers, the MX records are short, fixed, and copy-pasted directly from the provider's setup page.

Pattern (Google Workspace):

@    MX    1    SMTP.GOOGLE.COM

Pattern (Microsoft 365, with example-com as your tenant prefix):

@    MX    0    example-com.mail.protection.outlook.com

One hard rule: only one set of MX records can be active at a time. A domain cannot split incoming mail between two mail providers using MX records. Email forwarding from a registrar (or a service like ImprovMX) is a different mechanism that sits in front of your real mailbox.

TXT Records (Text Records)

TXT records hold arbitrary text strings attached to a hostname. They started life as a free-form metadata mechanism and have become the workhorse of modern email authentication and SaaS verification.

Common modern jobs for TXT records:

A domain commonly has five to ten TXT records once it is set up with email plus a few SaaS integrations. Each one is a string, and string values are case-sensitive.

Pattern (SPF, allowing Google Workspace to send):

@    TXT    "v=spf1 include:_spf.google.com ~all"

Pattern (DMARC policy, on the conventional _dmarc subdomain):

_dmarc    TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

SRV Records (Service Records)

SRV records describe where to find a specific service for a domain. Each SRV entry includes a target host, a target port, a priority (lower wins), and a weight (used for load balancing across equal-priority targets).

The most common SMB encounter with SRV records is Microsoft 365 setup. Microsoft Teams, Skype for Business, and Lync still rely on a handful of SRV records for autodiscovery, and the M365 admin center generates the exact entries you need.

Pattern:

_sip._tls.example.com    SRV    100  1  443  sipdir.online.lync.com

Most modern SaaS does not require SRV records. If you are not running a Microsoft-stack mail or collaboration setup, you may go years without writing one.

Where These Records Show Up in Practice

For an SMB, the typical zone looks like this once it has been set up correctly: A and AAAA records at the apex pointing to the website host, a CNAME for www pointing back to the apex (or vice versa), MX records for the mail provider, several TXT records for SPF, DKIM, DMARC, and SaaS verification tokens, and possibly SRV records if Microsoft 365 is in the picture.

It is best to configure DNS this way from day one. If you are sitting on a sprawling zone you inherited - records nobody documented, integrations from a SaaS tool that left the company two years ago, three TXT records that look almost the same but are not - the cleanup is a one-day project, not a multi-week migration. The faster route is to bring in someone who has done it before, hand over the registrar credentials, and let them prune and label.

Capabilities of a Well-Run DNS Setup

When the records above are healthy and documented, the day-to-day looks like this:

Next Step

Are you looking to free up your team's time to focus on growing the business? ScaleIt sets up and maintains DNS, email authentication, and SaaS integrations for SMBs. Contact us for a free consultation.

Verified against the IANA DNS Parameters registry and the relevant standards documents (RFC 1035 for A, CNAME, MX, TXT; RFC 3596 for AAAA; RFC 2782 for SRV; RFC 7208 for SPF; RFC 6376 for DKIM; RFC 7489 for DMARC). Last reviewed 2026-05-07.