At some point in your WordPress journey, you might have to configure DNS records for your domain, and it can be one of the most complicated aspects of managing any website. If something goes wrong with DNS and you don’t know what it is or how to handle it, you may end up struggling for hours and hours, like I have. After 10 years building sites and adopting a plugin that deals with domain mapping, I’ve learned a thing or two about DNS that will hopefully save others a great deal of time.
There’s a few reasons why you might encounter DNS when building a WordPress site. You might be:
- Setting up your domain/website for the first time,
- Creating multiple subdomains or domains for different parts of your website,
- Building a multisite network,
- Mapping individual domains to different posts/pages on your site,
- Or, even enhancing email deliverability.
While you might encounter DNS for any number of reasons, not limited to just those above, it’s important to understand what it is and how it works relative to having a WordPress site.
I’ll start from the beginning and build on each concept so that everyone can be on the same page.
Here’s what I’ll cover about DNS in this article:
- What does DNS mean?
- What are DNS Records?
- Why are “Nameserver” Records important?
- What is a DNS Server or DNS Provider?
- Where should I point my nameservers to manage DNS?
- How do you properly configure DNS Records?
If you have feedback about anything covered here, please let me know in the comments, and I’ll be sure to update what you think will help. Hopefully, this article can be one of the most useful reference points for anyone dealing with DNS in WordPress.
What does DNS mean?
DNS stands for Domain Name System.
The purpose of DNS is to “translate” your server’s IP address into your domain name, which is something much easier for humans to remember than a string of numbers.
If you’re interested, you can read about the guy who created DNS in 1983, Paul Mockapetris.
What are DNS Records?
When you register a domain name at a Domain Name Registrar, the first step is to configure DNS Records.
The purpose of DNS Records is to route different types of traffic for a domain to the proper server(s).
For example:
- A records are used for “hosts” and standard website traffic.
- CNAME records are used as “Aliases” or Canonical records.
- MX records direct email traffic.
- TXT records provide many useful verification options, like domain ownership and prevention of email spoofing.
This is not a complete list – there are many more DNS Record Types and their use cases are wide ranging, but those listed above are some of the most common to WordPress and building websites in general.
Why are Nameserver Records important?
The most important DNS Record is the Name Server (NS) record because it specifies the “DNS Zone” for a domain.
You should manage DNS records in the DNS Zone where your Name Server records are pointing. Here’s a basic diagram of how it works:
What is a DNS Server or DNS Provider?
When buying a domain name, the Domain Name Registrar will let you manage DNS Records using their DNS Server, which means that your Registrar and your DNS provider are the same when you first buy the domain.
However, you can specify your DNS Records/Zone to be elsewhere, and there are often good reasons to do so.
Your DNS provider may be any of these types of service providers:
- Domain Name Registrar (Namecheap, Domain.com)
- Web Hosting company (InMotion Hosting, GoDaddy)
- Content Distribution Network (CDN – CloudFlare, AWS)
- Standalone DNS providers (CloudDNS)
In the past, my agency clients have been confused by the fact that many companies offer overlapping services, so the terminology is really important to understand. One company might provide all these services for you, or you might work with a different company for each one.
Some registrars and hosting companies allow you to manage NS records and other DNS records in the same admin interface, so if you aren’t familiar with the purpose of NS records, you might be configuring DNS Records that won’t have any impact because your Name Server records are pointing to a different DNS Zone.
To state it differently, a DNS Zone is set to be “authoritative” by NS records, which means other DNS records won’t mean anything unless they’re located in the DNS Zone specified by the Name Server record. Make sure you’re editing DNS Records in the DNS Zone specified by your Name Servers!
In the beginning of my WordPress career, I honestly had little idea what I was doing with all this, so it was often trial by error. It took a while to figure out DNS works because the guides I would read online were too technical or theoretical.
Another important thing to consider with DNS is propagation time. When you change your DNS Records, it takes up to 24-48 hours for all ISPs and DNS Servers on the internet to recognize the change, which means your site/services can be down for up to 24-48 hours after changing DNS records depending on where the source of the traffic is coming from.
From my experience, propagation usually only takes a few minutes or hours to work globally, but this is definitely something to be aware of if you’re in the middle of changing your DNS Records.
Imagine – you’re struggling to make the right changes to your DNS Records, testing the changes, and wondering what could be going on when you’re getting mixed signals!
Where should I point my Nameserver records to manage DNS?
There are a few reasons why you would want to point your Name Servers to one provider over another.
Let’s go through the most common options.
Managing DNS with a Domain Name Registrar
If you buy a domain, and you don’t change your Name Servers, you’ll manage all DNS Records with your Registrar. In many cases, this is the easiest way for newcomers to WordPress and it’s completely fine to structure it this way for standard blogs or other small projects.
Managing DNS with a Hosting Company
If you set your nameservers to your hosting company, your hosting company will be the DNS provider, and they often have portals to easily allow you to adjust the records.
Some hosting companies don’t allow this, especially managed hosting companies like WP Engine that only allow you to host your site and don’t provide other services (like email). In the case of managed hosting, you would have to manage DNS with your Registrar or one of the other providers mentioned below.
Hosting companies have all kinds of server management portals, and I’m most familiar with good ol’ cPanel. I love it’s flexibility and simplicity, and with a VPS you can optimize it amazingly well for WordPress. The best part: It’s super-cheap compared to managed hosting.
This article isn’t about hosting, so I won’t go down this road any further, but I will say that it’s extremely easy to manage DNS Zones with cPanel if your web host provides it.
Managing DNS with a Content Distribution Network or CDN
Pointing your nameservers to a CDN can be a great idea to improve your site speed and security around the world.
If you’re a savvy WordPress site builder, you’re using a CDN on all your projects because CDNs are awesome.
I love managing DNS Records with the CDN CloudFlare because it enhances your site security and speed out of the box and gives you other features, like caching, URL forwarding, and more. I’m not affiliated or paid by CloudFlare – I genuinely love their platform, and the only reason I might consider moving away is if they started charging for their free plan 🤣
When you join CloudFlare, they ask you to type in your domain, and they automatically scan for your existing DNS records so that you’ll have continuity of any records you may have already set up. This feature is great, but it frequently pulls in records that I don’t want anymore, so be aware of that if you start using CloudFlare in the long-term or you’re transitioning any of the service providers for your site, as you should clear out any unused DNS records.
More importantly, during the onboarding process, CloudFlare provides the nameservers you’ll need to set at your Domain Name Registrar to start using CloudFlare as your DNS provider.
Whatever CDN you choose, you’ll need their nameservers in order to manage DNS Records with their platform.
Managing DNS with a Standalone DNS Host
I’ve personally never used a dedicated DNS host, but I know that DNS hosting companies can add extra layers of security and other benefits to your domain. Just like CDNs, you’ll need their nameservers in order to manage DNS Records on their platform and have them serve as your DNS provider.
How do you properly configure DNS Records?
Once you’ve set your nameserver records with your Domain Name Registrar and established who your DNS provider will be, you’ll need to properly configure your DNS Records.
But what records do you need for a successful WordPress website, to ensure email deliverability, or do things like verify your domain with Google Webmaster Tools?
I’ll cover the records that I know are important based on my experience, but I won’t cover all of the record types, as you probably won’t need many of them anyway unless you’re running an advanced project of some kind.
Having knowledge about the DNS record types below will prepare you for many common situations when managing WordPress sites.
A Records
A Records specify your hosting server for domains or subdomains and that’s the main record you’ll need for any website. Once you’ve added an A Record, you can set up a WordPress site at the corresponding server (provided by a hosting company) if you haven’t already.
WordPress.com and many other sites do this automatically with a subdomain when you set up a free blog on their site. But, when you’re building your own standalone WordPress site, you’ll need to set this up yourself.
A Records can point to any server, but there is only one A Record for the primary domain.
An A Record should always point to a server IP address and not a hostname. This is what it should look like:
Important note: Many DNS providers use the `@` symbol in replacement of your domain name when setting DNS Records.
CNAME Records
CNAME Records can be helpful for creating “aliases.” The most common alias is to use `www` so that your users visiting your primary URL with or without the `www` in front of it will still get to your site. This is what it should look like:
Other CNAME Records aren’t super common in WordPress projects from my experience unless you’re using managed hosting like WP Engine, which offers a feature called “CNAME flattening” where a customer can set WP Engine’s internal subdomain for their server behind the alias of a site’s primary domain to avoid issues in case the server IP address changes.
That use-case is a bit complicated – but worth mentioning if you’re using a managed host.
MX Records
MX Records direct mail traffic to your mail server. If you won’t be using any email services to receive email for a domain, then you don’t need MX records.
The most common MX Records I’ve used are to set up email hosting on a website server or for businesses using services like Google Workspace or Microsoft Office 365.
If you’re using the same server for hosting your website and your email (which I don’t recommend for different reasons), most hosting companies let you create an A record for `mail` and then an MX record that points to that same location. You’ll need to ensure your email accounts are configured properly via cPanel, etc.
This is what that type of MX record will look like:
MX Records always have some alphanumeric hostname associated with them, and not an IP address.
In some cases, like Google Workspace, you’ll have to add multiple MX records based on priority.
TXT Records
TXT Records can be used to verify your domain with services like Google Search Console, which requires DNS verification.
The DNS verification process simply means you have to add a TXT record that verifies you are the administrator and/or owner of that domain.
It looks something like this:
google-site-verification=ySOjBXDNrsM-mhllhhKq3--rfuaXiAeVOgODjf-7IacEmail Deliverability
A really common problem is trying to get your WordPress site to send emails without email deliverability issues – e.g. – Emails not getting sent to spam or rejected by the servers they’re sent to.
If you have a contact form that auto-replies to the user who fills it out – how do you ensure that email doesn’t get sent to their spam folder? The same goes for product order emails.
And for the admin emails that get sent to the site admin – how do you ensure that they get to the right place every time and not rejected because they’re coming from a different server using your domain?
Any Agency owner that deals with email will tell you that it’s not always easy to get that deliverability issue solved for every domain. Sometimes it can be extremely tricky because multiple servers and services can be at play, and the key is that every single one of them needs to be verified on your domain or deliverability issues can be caused (not to mention server-side issues).
SPF Records
The first way that email deliverability can be improved is to ensure that you have the proper SPF Record in place, which is simply a TXT Record that identifies all the servers that are “approved” to send email for your domain.
If someone tries to spoof your domain and send email using an email address that appears to be from your domain, email services use the SPF record to verify that the server sending the email is approved by the domain administrators.
You might be using a few different servers to send email on behalf of your domain. Every single server should be included if you want to ensure those emails aren’t going to spam.
Here’s an example of what a properly formatted SPF record looks like that is using two different servers with static IPs, SendGrid, MailGun, and Google Workspace to send email for that domain.
v=spf1 +a +mx +ip4:123.456.789 +ip4:456.789.123 +include:sendgrid.net +include:mailgun.org +include:_spf.google.com ~allIt’s important to review SPF best-practices to ensure you implement everything properly for your situation.
DKIM
DKIM Records allow for encryption of emails from the sending to receiving server. DKIM is not supported in all situations, but when possible, it greatly enhances email deliverability and security. You’ll enter DKIM as another TXT record, and the DKIM entry is provided by the sender server. Read more about DKIM here.
DMARC
DMARC is a public record that is used to inform the server receiving email from your domain what to do with an email based on the “tests” of the SPF and DKIM records.
There are 3 possible responses for what a server might do with an email that FAILS the SPF and DKIM record tests: quarantine, reject, or do nothing.
Setting up DMARC ensures that recipient servers know what to do with an email that fails those tests, and you can make the DMARC policy more or less strict with some fine-tuning. Read more about DMARC here.
Thanks for reading!
Having the DNS records mentioned above properly configured should give you everything you need to handle your WordPress project, while ensuring domain security, speed, and email deliverability.
I hope this article was helpful for putting DNS in the context of WordPress and managing your domains. Feel free to ask any questions below!
