Domain Name Servers tend to confuse a lot of people. If you are one of them, don’t feel bad.
I have had full-time IT professionals tell me that you can’t have email on a different server than your website, and that is obviously not the case. That is the whole point of mail exchange records (MX), a type of DNS record.
Not everyone understands the ins and outs.
Your business needs professional email.
In this article, we’ll cover:
- Common types of DNS records.
- Spam filters and email authentication.
- Other DNS records that matter for online communication.
- How email messages are exchanged between servers.
- Configuring email-specific DNS records.
Let’s dive in!
What is DNS and why does it matter for email?
DNS stands for Domain Name System or Domain Name Server. They’re responsible for connecting domain names to web servers. Anytime you connect to the internet and go anywhere, you’re using them.
Here is how it works:
Your browser: Go to godaddy.com.
Your computer: Connect to DNS server and tell me which server godaddy.com is on.
DNS server: godaddy.com is on this IP address: XX.XXX.XX.XXX
Your browser: Go to this IP address and ask for the godaddy.com website.
The DNS records translate the domain into the IP address of the server that hosts it. So in this case, you asked for godaddy.com, and it told you where it was hosted. (The web server is then responsible for loading the site that matches the requested domain, but that’s beyond what we’re covering here.)
DNS is also responsible for routing email from a sender to the recipient. If these records aren’t configured correctly, emails could be spam-filtered, bounced back, or your domain’s reputation could be harmed. Understanding DNS is key to avoiding these issues.
For this article, we’ll be covering A records, CNAME records, MX records, and SPF/DKIM records. I’ll be using your_company.com as the example domain.
Essential DNS records for email delivery
Now that we’ve briefly covered what DNS is, let’s discuss the specific DNS records involved with email services.
A records and CNAME records: Connect the domain to a mail server
The CNAME and A records are the most basic and common records. They are probably the easiest to explain.
A record: This tells you where the default domain is. Often, the main domain is represented by an @ symbol. The @ symbol just means your_company.com.
CNAME record: Is an alias for something. In the case below, the CNAME is telling you that the “www” part of “your_company.com” is on the same server, which is represented by the @ symbol.
Do you need more information? Check out these links:
MX records: Directs incoming email messages
MX records in the DNS server allow us to specify where email should be delivered. A GoDaddy help article about MX records states that “MX records specify and prioritize the incoming mail servers that receive email messages sent to your domain name.”
Many email providers now only require a single MX record to set up a domain for email. Google Workspace, for example, uses the following format:
| Name | Priority | Value | TTL |
|---|---|---|---|
| @ | 0 | smtp.google.com | 1 hour |
This MX record tells the sending email server, when sending an email to this domain name, deliver to smtp.google.com.
DNS records required for authentication and spam filters
To combat email spam, spoofing, and phishing, most major email providers require authentication records in order to successfully deliver email messages. These records include:
SPF record: This TXT DNS record makes sure that any email sent from a particular domain comes from an authorized server.
DKIM: A DKIM record provides a digital signature for outgoing emails. This signature verifies that the outgoing email hasn’t been altered and confirms the sender’s identity.
DMARC: The DMARC record builds on both SPF and DKIM records to allow you to set policies for unauthenticated emails. These policies include how you’d like suspicious emails handled, including monitoring, quarantine, or blocking the message entirely.
Let’s take a closer look at each record’s role below.
SPF records: Authorizes mail servers
SPF asks, “Is this IP address allowed to send mail on behalf your_company.com?”
There are three responses: Accept, Reject, and Accept but send to spam.
You need a record for any service that sends email on your_company.com’s behalf. For example, if you have an email provider already for your domain, but you’d like to use a separate service for sending email newsletters, you’ll need to have SPF records for both services (your primary email provider and the newsletter provider).
DKIM records: A digital email signature
DKIM asks, “Can I check your digital signature? I need to check the signature against the sending server.”
A sender creates the DKIM by signing the email with a digital signature. This signature is located in the message’s header. The sending mail transfer agent (MTA) generates the signature by using an algorithm applied to the content of the signed fields. This algorithm creates a unique string of characters, or a hash value.
DMARC records: Enforces email policy
DMARC asks, “Did SPF and DKIM pass? Let’s run through the policies that tell us what to do if the email is accepted or rejected.”
Other DNS records you’ll need for online communication
We’ve covered the basic requirements for sending and receiving email, but there are a few other records that you might need.
PTR records
A PTR record is a DNS record that does the reverse of what normal DNS does: it maps an IP address back to a domain name. Many mail servers check to see if your sending IP address has a valid PTR record, so it’s an important record for email deliverability.
This reverse DNS record is typically managed by your email service provider, not your regular DNS provider, so this record is likely already automatically set for you.
TLSA records
A TLSA record is a DNS record type used for DANE (DNS-based Authentication of Named Entities). It allows you to specify which TLS/SSL certificates are valid for your domain by publishing certificate information directly in DNS.
These records allow for enhanced email security by preventing man-in-the-middle attacks on mail servers.
Note that TLSA records only work with DNSSEC enabled on your domain name.
BIMI records
A BIMI record is a TXT record that allows you to display your company logo next to your emails in supported email clients. It’s a very new email authentication standard, so not all email providers or email clients support it yet.
SRV records
An SRV record is a DNS record that specifies the location (hostname and port) of servers for specific services. It's like a phonebook entry that says "for THIS service, connect to THAT server on THIS port."
These records are typically used for services like FTP, telephony, or instant messaging.
Step-by-step: Configuring DNS for your mail server
With those basics out of the way, let’s look at configuring DNS for email.
Setting up MX records
Your email provider will provide your MX records for you. Once you’ve got those records, you can add them to your DNS settings.
- Access your domain portfolio.
- Click on the domain name you’d like to configure.
- Select the DNS tab under your domain name.
- Choose Add New Record and then MX from the Type menu.
- Enter your new MX record information:
- Name: This will typically be @ for most configurations.
- Priority: Select the option specified by your email provider.
- Value: The domain of your mail server.
- TTL: Default is 1 hour.
- Select the Save option to save your record.
Related: Add an MX record
Making spam filters happy
Unlike A Records and MX Records, DKIM and SPF do not have their own prefix or type of record. They use TXT records. When adding them, you will select TXT, and then within the value, you will specify which type. GoDaddy has an article about adding an SPF record.
Adding SPF records
For my domain, this is what a plain SPF record looks like:
| Name | Value | TTL |
|---|---|---|
| @ | v=spf1 mx -all | 1 hour |
"v=spf1 mx -all" allows the domain to send mail from the specified MX records for the domain only, prohibiting all others. For example, if your email service is Google Workspace, then this will allow email from Google’s servers to send, but no other servers would be able to.
If you also need to send mail through your CRM, AWS SES, SendGrid, or some other service that you use, you will have to add those records. Your SPF Record could look like this:
v=spf1 a mx include:teamworkdesk.com include:spf.mandrillapp.com ~all Just add another “include:service_name.com” to the same record. To be safe, always read the instructions for the service you are using.
Adding DKIM records
Now that you have your SPF records, you might need to add a DKIM record. It should be pretty simple; find the service, and you will want to copy and paste your DKIM record from the service.
Note: The DKIM record is a whopping 216 characters (hence the ellipses in the screenshot). You should be able to have a separate DKIM for each service (as opposed to SPF records, which combine the domains).
Troubleshooting common email DNS issues
What if you’ve added all of your email DNS records and your email still isn’t working? Below, we’ll cover some of the typical diagnostic steps you can take to resolve the issue.
The good news here is, email issues are almost always configuration issues. Let’s go over some of the common issues you might encounter here.
Note: DNS propagation can take 24-48 hours, so be sure that you’ve allowed for the full propagation period before moving on to these steps.
Email bouncing or rejected
Email bounces will typically tell you what the error is, but here are the two most common DNS issues that would cause a full bounce (versus routing to a spam/junk folder):
- Missing or incorrect MX records: Check to be sure that you’ve added the MX records exactly how your email provider requires.
- Missing or misconfigured SPF records: Your SPF record needs to include your email server information to work properly.
If those two records are correct, then you may need to check your domain reputation. Sites like mail-tester.com can help you track down whether this is the issue.
If you’ve tried all of these options and are still getting bounced messages when trying to send, check out our guide for tips to reduce bounce rate.
Related: What is an email bounce?
Messages landing in spam folders
If your emails are going to the spam folder instead of the inbox, you’ll want to check your SPF/DKIM/DMARC records. These records are becoming increasingly required by email providers, so having them correctly configured is crucial.
Email filters may also read messages as spam if the contents are suspicious. For more information on how to avoid sending spammy emails, our guide can help.
Emails being sent to spam folders can also be caused by recipients marking your messages as spam. Check out our help center for tips on how to prevent emails being marked as spam.
Website forms not sending email
If the forms are sending from your website, but the emails never arrive, this is typically an issue with the SPF record. When another server is involved with your email (outside of your email server), you need to ensure that your SPF record includes the IP address for your web server.
DNS propagation delays
While there’s not much you’ll be able to do yourself if DNS propagation is delayed, there are a few factors involved that you can control:
- Use a lower TTL time when setting or updating DNS records.
- Use fast DNS providers with short cache times.
- Plan to make DNS changes during low-traffic periods.
DNS can be complex. Hopefully, this helps get you started.
DNS for email sounds complicated, but if you take it piece by piece, it’s definitely manageable. Proper DNS configuration is a one-time investment that pays you back with security, deliverability, and professional credibility.
