Every domain has a DNS record that tells the internet where to find it. The A record is the most basic of these — it maps a domain name to an IPv4 address. If you are configuring cold email sending infrastructure, setting up a custom tracking domain, or troubleshooting why your messages are not reaching the inbox, you will run into A records. This guide covers what they are, how they interact with email sending, and the most common mistakes senders make when configuring them.
What an A Record Actually Is
DNS — the Domain Name System — functions like a directory for the internet. When a browser or mail server needs to find a domain, it queries the DNS and gets back an IP address it can connect to. Without DNS, every connection would require typing a raw IP address like 192.0.2.44 instead of a domain name.
An A record (short for "Address record") is the DNS entry that performs this translation. It maps a hostname — like mail.yourdomain.com or track.yourdomain.com — to a specific IPv4 address. The lookup process works like this:
- Your mail client or browser sends a query: "What is the IP for
mail.yourdomain.com?" - The DNS resolver checks its cache. If the record is there and not expired, it returns it immediately.
- If not cached, the resolver queries the authoritative nameserver for your domain.
- The nameserver returns the A record:
mail.yourdomain.com → 198.51.100.10 - The connection proceeds to that IP address.
This whole process typically completes in milliseconds. The result is that humans use domain names and servers use IP addresses — A records are the bridge.
A Record vs. Other DNS Record Types
DNS has several record types, each serving a distinct function. Here is a quick comparison of the ones email senders encounter most:
| Record Type | What It Does | Email Relevance |
|---|---|---|
| A | Maps hostname → IPv4 address | Tracking domains, sending subdomains, web redirects |
| MX | Points to the mail server that receives email for a domain | Required for receiving replies to your cold email |
| CNAME | Aliases one hostname to another hostname | Often used for tracking domains pointing to a provider |
| TXT | Stores text data — authentication records live here | SPF, DMARC, and DKIM public keys (for email authentication) |
| PTR | Reverse DNS — maps IP address back to hostname | Used by receiving servers to verify your sending IP identity |
For cold email senders, all five record types matter. But the A record is often the starting point when standing up a new sending subdomain or custom tracking domain.
How A Records Relate to Email Sending
Most email senders think A records are only a web hosting concern. That is wrong. A records show up in three specific places within cold email infrastructure:
Sending Domain and Subdomain Resolution
When you send cold email from a domain like outreach.yourdomain.com, receiving mail servers look up the A record for that subdomain to verify it resolves to something legitimate. A sending domain with no A record — or one that resolves to a server with no web presence — can trigger additional scrutiny from spam filters. It signals a throwaway domain rather than a real sending identity.
Custom Tracking Domains
Open and click tracking links use a custom domain — something like track.yourdomain.com. That subdomain needs an A record (or CNAME) pointing to your tracking infrastructure. If it is missing or misconfigured, tracking breaks and links in your emails will appear broken to recipients, which tanks engagement metrics and can cause spam filters to flag the message.
Reverse DNS (PTR Records) and IP Reputation
The PTR record is the inverse of an A record — it maps an IP address back to a hostname. Receiving servers check your sending IP's PTR record to confirm that the IP resolves to the domain you claim to be sending from. Without a correctly configured PTR record, many email servers will reject or flag your messages outright. The A record and PTR record need to match: your domain should point to your IP (A record), and your IP should point back to your domain (PTR record). This symmetry is one of the first things checked when receiving servers evaluate your sender reputation.
How to Check Your A Record
You have two options: command-line tools or browser-based lookup tools.
Using dig (Mac/Linux)
dig yourdomain.com AThis returns the A record for the root domain. To check a subdomain:
dig mail.yourdomain.com AUsing nslookup (Windows/Mac/Linux)
nslookup yourdomain.comOr explicitly request the A record type:
nslookup -type=A yourdomain.comOnline Tools
If you do not want to use the command line, tools like MXToolbox (mxtoolbox.com/DNSLookup), DNSChecker (dnschecker.org), and Google's DNS lookup (toolbox.googleapps.com/apps/dig/) let you enter a domain and view all DNS records including A records. These are also useful for checking propagation — you can query multiple DNS servers worldwide to see if a recent change has propagated.
How to Add or Edit an A Record
The process varies slightly by registrar, but the steps are consistent:
- Log into your domain registrar or DNS host (Cloudflare, GoDaddy, Namecheap, Route53, etc.)
- Navigate to the DNS management section for your domain
- Click "Add Record" or find the existing A record to edit
- Set the record type to A
- Enter the Name/Host — this is the subdomain portion. For
track.yourdomain.com, entertrack. For the root domain, enter@ - Enter the Value/Points To — the IPv4 address you want this hostname to resolve to
- Set the TTL (see below)
- Save the record
Changes can take anywhere from a few minutes to 48 hours to propagate globally, though most registrars now propagate within 15-30 minutes for low-TTL records.
TTL: Why It Matters When You Are Making Changes
TTL (Time to Live) is the number of seconds DNS resolvers are allowed to cache your record before re-querying. A TTL of 3600 means resolvers cache the record for one hour. A TTL of 86400 means they cache it for 24 hours.
This matters most when you are switching sending infrastructure or migrating to a new IP. If your current A record has a TTL of 86400 and you need to change the IP, some resolvers will continue sending traffic to the old IP for up to 24 hours after you make the change.
The best practice: before making a significant DNS change, lower the TTL to 300 (5 minutes) 24-48 hours in advance. Make the change. Wait for propagation. Then raise the TTL back to a normal value (3600 or 86400) once you have confirmed everything is working correctly.
Common A Record Mistakes for Email Senders
Let's walk through the most damaging ones in detail:
No A Record on Your Sending Subdomain
If you send from outreach.yourdomain.com but that subdomain does not resolve to an IP via an A record, receiving servers will see it as suspicious. A legitimate sender has a domain that actually exists and points somewhere. This is a basic hygiene issue that is easy to miss when you spin up new sending domains quickly.
Mismatched A Record and PTR Record
Your A record points your domain to an IP. Your PTR record should point that same IP back to your domain. If they do not match — or if there is no PTR record at all — many receiving servers will reject your mail or significantly downgrade its IP reputation score. This is especially common with providers that use shared IP pools without proper rDNS configuration for each customer's domain.
Broken Tracking Domain Configuration
If your click-tracking subdomain (track.yourdomain.com) does not have a valid A or CNAME record, every link in your email generates an error when a recipient clicks it. Beyond the broken user experience, spam filters evaluate link integrity as part of their scoring. A broken tracking domain can contribute to messages being flagged as spam.
Not Lowering TTL Before a Migration
When moving from one email infrastructure provider to another, senders often forget to lower their TTL in advance. The result: DNS resolvers keep returning the old IP for hours or days, routing traffic to infrastructure you have already vacated. Deliverability degrades during the transition window.
How ScaledMail Handles DNS Configuration
Setting up A records, PTR records, SPF, DKIM, and DMARC across dozens of sending domains is tedious work that most teams get wrong at least once. ScaledMail provisions and configures all DNS records automatically when you set up your sending infrastructure. That includes:
- A records and PTR (rDNS) records for every sending IP, properly matched to your sending domains
- Custom tracking domain configuration so open and click tracking resolves correctly
- SPF, DKIM, and DMARC records configured to meet current Gmail and Yahoo bulk sender requirements
- Dedicated IP addresses, so you are never sharing infrastructure with another sender whose mistakes could affect your domain reputation
You do not need to touch your registrar's DNS panel or worry about TTL management during infrastructure changes. ScaledMail handles the technical layer so you can focus on writing better cold email.
If you are running into deliverability problems and suspect DNS configuration is the cause, the fastest diagnostic step is to check your A record, PTR record, and the match between them. Most issues trace back to one of the six mistakes listed above.
Get Your DNS Right from Day One
A records are simple in concept but easy to misconfigure under pressure — especially when you are standing up multiple sending domains at once. The fix is either building a rigorous checklist and reviewing every domain before you start sending, or using infrastructure that handles this automatically.
ScaledMail provisions managed email infrastructure with all DNS records configured correctly from the start. Every sending domain gets dedicated IPs with matching PTR records, proper authentication, and clean sender reputation from day one. See how it works or view pricing.
