# What is a DNS A record? Examples, lookups, and email implications > 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. - **Category:** Deliverability - **Published:** August 4, 2026 - **Reading time:** 13 min read - **Author:** Maya Chen, Deliverability - **Canonical page:** [https://emailbump.com/blog/what-is-a-dns-a-record](https://emailbump.com/blog/what-is-a-dns-a-record) 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. > **Use documentation addresses in examples** > > The 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24 ranges are reserved for documentation. Replace example values with the exact address supplied by your hosting or infrastructure provider; never point production DNS at an address copied from a tutorial. ## A record example ### Conceptual DNS record ```text 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.20 ``` The 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 ### A **Hostname → IPv4 address** Use it when a service should resolve directly to an IPv4 address. ### AAAA **Hostname → IPv6 address** The IPv6 counterpart. A hostname can publish both A and AAAA records. ### CNAME **Alias name → canonical hostname** Delegates resolution to another name instead of containing an IP address directly. ### MX **Mail domain → inbound mail exchanger** Routes incoming email for a domain and includes a preference value. ### PTR **IP address → hostname** Provides reverse DNS through the address owner's reverse zone; outbound mail operators commonly need it. ### TXT **Name → text data** Used 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 ### Command-line lookups ```bash 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.com ``` A 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 ### Wrong zone **Editing non-authoritative DNS** Check NS delegation before assuming the UI you can access controls public answers. ### Duplicated name **app.example.com.example.com** Some consoles append the zone to relative names. Learn how the host field is interpreted. ### Apex confusion **Using @ literally** Many interfaces display @ as shorthand for the zone apex; it is not necessarily a literal DNS label. ### IPv4-only testing **Ignoring AAAA** A stale IPv6 destination can fail even when the A record looks correct. ### Mail-record swap **Replacing MX, PTR, or DKIM with A** Each record type answers a different question. ### Propagation guess **Waiting without checking evidence** Compare authoritative answers, recursive caches, TTLs, delegation, and application behavior. ## Connect DNS changes to sending evidence Record which application, domain, IP, and message stream a DNS change affects so delivery investigations begin with the actual dependency. - Verified sending domains - Message activity - Authentication and delivery context [Learn more](https://emailbump.com/signup) ## 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. ## Check the rest of the email DNS path - [MX record lookup](https://emailbump.com/tools/mx-record-lookup) — Inspect the mail exchangers responsible for inbound delivery. - [DNS propagation checker](https://emailbump.com/tools/dns-propagation-checker) — Compare record answers across public resolvers with clear cache limits. - [DKIM selector guide](https://emailbump.com/blog/find-dkim-selector) — Construct and resolve a DKIM key owner from message headers. - [Email authentication methods](https://emailbump.com/blog/email-authentication-methods) — Separate DNS authentication from SMTP login and transport security. ## Sources - [RFC 1034: Domain Names—Concepts and Facilities](https://www.rfc-editor.org/rfc/rfc1034) - [RFC 1035: Domain Names—Implementation and Specification](https://www.rfc-editor.org/rfc/rfc1035) - [RFC 1912: Common DNS Operational and Configuration Errors](https://www.rfc-editor.org/rfc/rfc1912)