Netlify Load Balancer IP: The Apex A Record, and Why You Need It

Netlify’s load balancer IP for an apex domain A record is 75.2.60.5, which is the fallback to use when your DNS provider cannot do ALIAS, ANAME or flattened CNAME records for the bare domain.

That one address answers the search, but it does not explain the setup. Why does an apex domain need an A record when www can use a CNAME? Which record should you try first? And what happens when a tutorial from three years ago hands you an IP that no longer matches the docs? Here is the complete picture, based on Netlify’s own DNS documentation.

Table of contents

• The short answer: which record to add
• Why an apex domain needs an A record but www does not
• Setting it up, step by step
• Verify with dig before you assume it worked
• Pitfalls: stale IPs, proxies and conflicting records
• Pointing the same domain at a different host
• How this fits the rest of the stack
• FAQ

The short answer: which record to add

According to Netlify’s external DNS guide, an apex domain (example.com with no www in front) cannot use a CNAME record, so you have two options. The recommended one is an ALIAS, ANAME or flattened CNAME record at the apex pointing to apex-loadbalancer.netlify.com. It is more resilient because the target name can change behind the scenes without you touching DNS.

The fallback, for providers that only offer plain records, is an A record for the apex pointing to Netlify’s load balancer IP address, 75.2.60.5. Leave the host field empty or enter @, depending on how your DNS provider labels the root of the zone.

; recommended (provider supports ALIAS / ANAME / flattened CNAME)
example.com.     ALIAS   apex-loadbalancer.netlify.com.

; fallback (provider only supports plain records)
example.com.     A       75.2.60.5

; subdomain, always a CNAME to your site's Netlify subdomain
www.example.com. CNAME   your-site-name.netlify.app.

Always check the exact values in your own dashboard before you copy anything from a blog post, this one included. Netlify shows customised DNS instructions for each domain under Domain management, on the Pending DNS verification link. That page is the source of truth for your site, and it is worth ten seconds to confirm the address matches what you are about to type.

Why an apex domain needs an A record but www does not

The DNS standard says a CNAME record cannot coexist with any other record at the same name. The apex of your domain always has other records: the SOA, the NS records that name your nameservers, and usually MX records for email. So a CNAME at the apex would break the zone, and standard-compliant providers do not allow it.

A subdomain like www has no such conflict. It can be a pure alias, so you point it at your Netlify subdomain with a CNAME and let Netlify decide which servers answer. That is why the documentation recommends the www form as your primary address if you use external DNS.

ALIAS, ANAME and flattened CNAME are provider-specific tricks that behave like a CNAME at the apex. The provider resolves the target name on its own servers and returns plain A records to the visitor, so the standard is respected and you still get the flexibility of a name. Not every provider offers one, which is exactly why the raw A record fallback exists.

There is a trade-off Netlify calls out itself: either way, the apex eventually resolves to a single load balancer address, so it cannot use the direct DNS routing that a subdomain gets on Netlify’s CDN. In practice this means the apex is a slightly weaker front door than www, and the recommendation is to make a subdomain the canonical address and redirect the apex to it.

Setting it up, step by step

The steps are the same at any DNS provider. The labels differ, but the sequence does not.

1. Add the domain to your site in Netlify first. Until you do, the record points at something that does not know about your site.
2. Open your DNS provider and find the record editor for the root of your domain.
3. Remove any existing A, AAAA or ALIAS records at the apex that point to an old host, so they do not compete.
4. Add the ALIAS record to apex-loadbalancer.netlify.com if your provider supports it. Otherwise add an A record to 75.2.60.5.
5. Add a CNAME for www pointing at your-site-name.netlify.app.
6. Save, then wait. Netlify says propagation can take a full day, though it is often far faster.
7. Back in Netlify, verify DNS and let it provision the TLS certificate.

If www is configured first, Netlify adds the apex to the site automatically and handles the redirect between the two. You still need to make the apex record yourself, since Netlify cannot edit a zone it does not control.

Do this in a quiet window if the domain already serves a live site. Lower the TTL on the old records a day beforehand so a mistake can be rolled back quickly. The subdomain side of this work has its own quirks, which we cover in subdomains on Netlify.

Verify with dig before you assume it worked

DNS gives you wrong answers politely. Your registrar’s control panel showing the record does not mean the world sees it. Use dig to ask the internet directly, and ask a public resolver so you do not get your own machine’s cache.

dig +short example.com A @1.1.1.1
dig +short www.example.com CNAME @1.1.1.1
dig +short example.com NS
curl -sI https://example.com | head -n 5

With the A record fallback you should see 75.2.60.5. With an ALIAS setup you will see Netlify addresses returned as plain A records, and they may differ from what this guide lists, which is normal. The NS output tells you which provider is actually authoritative for the domain. This is the most common source of wasted hours: people edit records at their registrar while the nameservers point at a different company entirely.

The curl check confirms the last piece. A certificate error means DNS is right but Netlify has not issued the certificate yet, which is usually a matter of waiting, or of a leftover AAAA record sending IPv6 visitors elsewhere. A 404 from Netlify means the domain reached them but is not attached to a site.

Pitfalls: stale IPs, proxies and conflicting records

The classic one is the outdated address. Older tutorials list a different Netlify IP, and copied records from a decade-old guide still work until they do not. The Netlify forums have threads about a change of load balancer address, and the current answer from Netlify staff is that the documented A record address is the intended one. Treat any IP you did not read from the current docs or your dashboard as suspect.

• Stale IPs: replace anything that does not match the value Netlify shows for your domain today.
• Leftover records: an old AAAA or a second A record at the apex splits traffic between Netlify and the previous host.
• Proxying in front: putting another CDN or proxy in front changes what Netlify sees and can break certificate issuance. Our post on Netlify with Cloudflare covers the settings that matter.
• Bypassing the CDN: pointing the apex at the load balancer means you do not get direct CDN routing there, so keep www as canonical.
• CAA records: if a CAA record exists, it must permit the certificate authority Netlify uses.

If you are deciding whether you need a separate CDN layer at all, CDN on Netlify explains what is already included. Most sites do not need a second one.

Pointing the same domain at a different host

Everything above is a pattern, not a Netlify secret. Any static or app host works the same way: an apex needs an A or ALIAS record, www uses a CNAME, and the host tells you the exact values for your domain. If you ever move a site, you repeat the dance with new values, which is why it pays to keep TTLs low around a migration.

The failure modes also repeat. Someone edits DNS at the wrong provider, a stale AAAA record survives, or the certificate never issues because the domain is not attached to a site yet. Learn to read the dig output once and you can debug any host.

Where we come in is the moment after the records exist. RunxBuild does not register domains, so you buy one wherever you like, add it to a static site or service, and the dashboard shows the records to create and handles the certificate once they resolve. The steps are in the custom domains docs.

How this fits the rest of the stack

If you are weighing where to host the site behind this domain, the RunxBuild hosting calculator shows what a static site or service costs with bandwidth included, so the comparison is on real numbers. Static sites on RunxBuild build from a repository with custom domains, headers, redirects and 120 GB of bandwidth included, then $0.10 per GB. You can add a domain and read the exact records from the dashboard.

Useful related references:

• Subdomains on Netlify
• Netlify with Cloudflare
• CDN on Netlify
• Custom domains and certificates on RunxBuild

FAQ

What is Netlify’s load balancer IP address?

Netlify’s documented load balancer IP for an apex domain A record is 75.2.60.5. It is the fallback for DNS providers that do not support ALIAS, ANAME or flattened CNAME records. Confirm the value in your own Netlify domain settings before using it.

Why can’t I use a CNAME for my root domain?

A CNAME cannot coexist with other records at the same name, and the root of a domain always has SOA, NS and often MX records. Because of that conflict, the apex needs an A record or a provider-specific ALIAS, ANAME or flattened CNAME.

Should I use the A record or ALIAS for Netlify?

Use ALIAS, ANAME or a flattened CNAME pointing to apex-loadbalancer.netlify.com if your DNS provider supports it, because it is more resilient. Use the A record to 75.2.60.5 only when your provider offers nothing else.

How long does a Netlify DNS change take to work?

Netlify says it can take a full day for records to propagate across DNS, though many changes are visible within minutes to hours. Lowering the TTL beforehand and checking with dig against a public resolver helps you see the real state.

Do I need Netlify DNS to use a custom domain?

No. You can keep your DNS at any provider and add the records Netlify specifies, an A or ALIAS at the apex and a CNAME for www. Netlify DNS is an option that manages the records for you, not a requirement.