Learn how an A record maps a hostname to IPv4, how it differs from AAAA, CNAME, MX, and PTR records, and when changing one can affect an email system.
A DNS A record maps a hostname to an IPv4 address. If example.com has an A record containing 192.0.2.10, a resolver can learn that IPv4 address when an application asks where example.com is hosted. The “A” means address. It does not create an email inbox, select an incoming mail server, publish a DKIM key, or provide reverse DNS.
A record example
NAME TYPE TTL VALUE
example.com. A 3600 192.0.2.10
app.example.com. A 300 192.0.2.20
example.com → IPv4 192.0.2.10
app.example.com → IPv4 192.0.2.20The owner name identifies the hostname, A identifies the record type, TTL controls how long a resolver may cache the answer, and the value is a 32-bit IPv4 address. RFC 1035 defines A record data as an Internet address stored in four octets.
A vs AAAA vs CNAME vs MX vs PTR
Hostname → IPv4 addressUse it when a service should resolve directly to an IPv4 address.
Hostname → IPv6 addressThe IPv6 counterpart. A hostname can publish both A and AAAA records.
Alias name → canonical hostnameDelegates resolution to another name instead of containing an IP address directly.
Mail domain → inbound mail exchangerRoutes incoming email for a domain and includes a preference value.
IP address → hostnameProvides reverse DNS through the address owner's reverse zone; outbound mail operators commonly need it.
Name → text dataUsed for SPF policies, DKIM public keys, DMARC policies, and many domain-verification tokens.
These records can work together but are not substitutes. An MX target normally needs to resolve to an address, but placing an A record at example.com does not tell senders to deliver mail there. Likewise, setting example.com to the outbound sending IP does not establish PTR; the IP owner controls the reverse zone.
How to look up an A record
dig A example.com
dig +short A example.com
nslookup -type=A example.com
host -t A example.com
# Ask an authoritative server directly after identifying it
dig NS example.com
dig @ns1.provider.example A example.comA recursive resolver can return a cached answer. An authoritative lookup shows what the responsible nameserver currently publishes. Comparing both helps distinguish an incorrect zone from a correct update that is still cached. Also inspect CNAMEs in the chain and query A and AAAA separately.
How to add or change an A record
- Confirm which DNS provider is authoritative by checking the domain's NS records. Editing a registrar panel that is not authoritative changes nothing publicly.
- Obtain the exact IPv4 address and hostname from the service owner. Decide whether the record belongs at the apex, a subdomain, or both.
- Check for an existing A, AAAA, CNAME, forwarding, or provider-specific flattened record at the same owner name.
- Lower the TTL before a planned migration if the provider and timeline allow it; an already cached higher TTL does not shrink retroactively.
- Publish the smallest change, verify it from authoritative nameservers, then test through multiple recursive resolvers.
- Keep the old endpoint available through the cache window when possible, and restore an appropriate TTL after the migration is stable.
Can a hostname have multiple A records?
Yes. DNS can return multiple A records for one owner. Clients may choose or reorder answers, so this is not a precise health-aware load balancer by itself. Removing an unhealthy address also does not instantly remove it from resolver caches. Use the hosting platform's documented routing design and monitor every published destination.
How A records affect email
- Inbound mail: the hostname named by an MX record must ultimately resolve to reachable mail-server addresses. Do not point MX directly to an IP literal.
- Outbound identity: a sending server's PTR should resolve to a hostname whose forward A or AAAA record returns to that IP. This forward-confirmed relationship is operationally important to many receivers.
- Tracking and links: a branded click or image hostname may use A, AAAA, or CNAME. Changing it can break links or pixels even though SMTP delivery continues.
- SPF: the a mechanism authorizes addresses returned for a hostname, but broad or changing A records can unintentionally expand authorization. Explicit provider guidance is safer than guessing.
- Web presence: the domain in a visible From address often hosts a trust and support destination. A broken website does not mechanically fail DKIM, but it can undermine recipient trust and investigations.
A record mistakes to avoid
Editing non-authoritative DNSCheck NS delegation before assuming the UI you can access controls public answers.
app.example.com.example.comSome consoles append the zone to relative names. Learn how the host field is interpreted.
Using @ literallyMany interfaces display @ as shorthand for the zone apex; it is not necessarily a literal DNS label.
Ignoring AAAAA stale IPv6 destination can fail even when the A record looks correct.
Replacing MX, PTR, or DKIM with AEach record type answers a different question.
Waiting without checking evidenceCompare authoritative answers, recursive caches, TTLs, delegation, and application behavior.
Frequently asked questions
Does every domain need an A record?
No. A domain can exist for email or another DNS-published service without hosting an IPv4 website at the apex. Configure only the records required by the services you actually operate.
Can I use a CNAME instead of an A record?
A CNAME aliases one name to another, while A contains an IPv4 address. Whether a CNAME is allowed depends on the owner name and provider design. Traditional DNS does not permit a CNAME owner to coexist with other data, which makes apex usage especially constrained; some providers offer proprietary flattening or alias records.
Does an A record control reverse DNS?
No. Reverse DNS uses PTR records under the IP address owner's reverse zone. For a mail server, arrange PTR with the hosting or IP provider, then publish matching forward A or AAAA records under a hostname you control.