NsLookup logo
Email

The Ultimate Guide to Email DNS Records

Email may look simple from the outside, but a lot happens behind the scenes before a message reaches its destination. DNS is one of the systems that makes this possible. It helps mail servers find where messages should be delivered and provides information that receiving servers use to verify and trust email.
A person at a control desk facing a glowing email icon inside a secure DNS chamber

This is where email DNS records come in. These records are settings stored in your domain’s DNS that tell mail servers how to handle email for your domain. Some records direct incoming messages to the right mail server, while others help verify that messages are coming from authorized sources.

In this guide, we’ll cover the most important DNS records used for email, including MX, SPF, DKIM, DMARC, PTR, TXT, CNAME, SOA, A, AAAA, NS and SRV records. You’ll learn what each record does, how these records work together, and why keeping them correctly configured matters for email delivery and security. By the end, you’ll have a clear understanding of how DNS supports the sending, receiving, and authentication of email.

What are Email DNS Records?

Email depends on DNS to help mail servers find the right destination and understand how a domain handles its messages. Email DNS records are DNS entries that provide this information. They are stored on your domain and specify which servers to send email to, which systems are allowed to send messages for your domain, and how those messages should be checked.

When someone sends an email to your domain, the sending mail server queries your domain's DNS to find the correct mail server. For example, an MX record tells it where incoming messages should be delivered. Other records, such as SPF, DKIM, and DMARC, provide information that helps verify whether an email is legitimate.

Not every DNS record is related to email. DNS can also store records for websites, applications, and other online services. DNS record email configurations are specifically concerned with sending, receiving, authenticating, or securing email.

If these records are missing, outdated, or configured incorrectly, email may not reach its destination. Messages can be rejected, authentication checks can fail, or legitimate emails may end up in spam. That is why keeping your email-related DNS records accurate is an important part of maintaining reliable email delivery.

Types of Email DNS Records You Should Know

Different DNS records handle different parts of the email process. Here are the ones you should know.

MX Records

MX, or Mail Exchange, records tell other mail servers where to deliver incoming email for your domain. When someone sends a message to [email protected], the sending mail server checks the domain's MX records to find the server responsible for receiving that message.

An MX record contains a mail server hostname and a priority value. A lower number means higher priority. If several MX records are available, the sending server will usually try the server with the highest priority first. If that server is unavailable, it can try another one.

SPF Records

Sender Policy Framework (SPF) helps receiving mail servers determine whether an email was sent from an authorized source. It works by publishing a list of approved sending servers or IP addresses in your domain's DNS.

An SPF record is published as a TXT record and must start with v=spf1. It can include mechanisms such as ip4, include, and a to identify authorized senders.

For example:

v=spf1 include:_spf.example.com -all

Common SPF problems include having multiple SPF records, exceeding the 10 DNS lookup limit, forgetting to authorize a legitimate email service, or using incorrect syntax.

DKIM Records

DomainKeys Identified Mail (DKIM) adds a digital signature to outgoing email. This allows the receiving mail server to check whether the message was signed by an authorized domain and whether important parts of the message were changed during transit.

DKIM uses a public and private key pair. The sending mail server uses the private key to create the signature, while the receiving server retrieves the public key from DNS to verify it. The public key is published in a DKIM DNS record under a specific selector. The selector helps receiving servers find the correct key. For example, a selector called google may use a DNS hostname such as google._domainkey.example.com.

DMARC Records

Domain-based Message Authentication, Reporting, and Conformance (DMARC) builds on SPF and DKIM. It tells receiving mail servers what to do when an email fails authentication and alignment checks.

A DMARC record is published at _dmarc.example.com and can use three main policies:

  • p=none: Monitor messages without taking enforcement action
  • p=quarantine: Treat failing messages as suspicious, often sending them to spam
  • p=reject: Reject messages that fail DMARC checks

DMARC also supports reporting. Domain owners can use these reports to understand who is sending email on their behalf and identify authentication problems or potential spoofing attempts.

PTR Records

PTR records are used for reverse DNS, which maps an IP address back to a hostname. For email, this can help receiving servers understand which hostname is associated with the IP address of a sending mail server.

For example, a mail server sending from an IP address may have a PTR record pointing to mail.example.com. Receiving servers can perform a reverse DNS lookup to check this information.

PTR records do not authenticate individual emails like SPF or DKIM. However, major mailbox providers such as Gmail and Yahoo require sending IPs to have valid reverse DNS, so a missing or mismatched PTR record can get your mail rejected.

TXT Records

TXT records allow domain owners to publish text-based information in DNS. They are especially important for email because several email security and verification technologies use them.

SPF and DMARC records are both published as TXT records in DNS. DKIM also relies on DNS to publish its public key, which receiving mail servers use to verify email signatures. Beyond email authentication, TXT records can store information used for domain verification and other email-related services. Since a domain can have multiple TXT records, it is important to keep them accurate and avoid conflicting or outdated entries.

CNAME Records

CNAME, or Canonical Name, records create an alias that points one hostname to another hostname. Email service providers can use CNAME records to connect a domain's DNS configuration to their own infrastructure.

For example, a third-party email provider may ask a customer to create a CNAME record for DKIM or another email service. The provider can then manage the destination while the customer's domain uses the required hostname.

This is common with third-party email platforms that handle sending on behalf of a domain. Following the provider's DNS instructions carefully is important because an incorrect CNAME target can prevent the related service or authentication mechanism from working properly.

A Records

A records map a domain or hostname to an IPv4 address. For email infrastructure, an A record can point a mail server hostname to the server's IPv4 address. For example, if an MX record points to mail.example.com, that hostname may have an A record that maps it to the server's IP address. This gives the sending server the actual network address it needs to connect to the mail server.

A records are not email authentication records, but they can be an important part of the DNS setup behind your mail infrastructure.

AAAA Records

AAAA records function similarly to A records, but they map a hostname to an IPv6 address rather than an IPv4 address. If your mail server supports IPv6, an AAAA record can provide its IPv6 address. This allows mail servers and other systems that use IPv6 to connect to it.

Like A records, AAAA records do not authenticate email. They simply provide the address needed to reach a server.

NS Records

NS, or Name Server, records identify the authoritative DNS servers responsible for a domain's DNS information. When another mail server needs to find your MX, SPF, DKIM, or DMARC records, it ultimately relies on the authoritative DNS servers for your domain to provide that information.

NS records, therefore, do not directly control email delivery, but they are part of the DNS infrastructure that makes email-related records available to other servers.

SOA Records

SOA, or Start of Authority, records contain important information about a DNS zone. This includes the primary authoritative name server, the domain administrator's contact information, and values that control how DNS changes are synchronized and cached.

An SOA record does not tell a mail server where to deliver email or whether a message is legitimate. However, it provides essential information about how the domain's DNS zone is managed.

SRV Records

SRV, or Service, records specify where a particular service is available. They can provide information such as the hostname and port associated with a service. Some email-related services and protocols can use SRV records to help clients discover the appropriate server. For example, certain email clients or messaging services may rely on SRV records for automatic service discovery.

SRV records are not normally part of the basic setup for sending and receiving email, so they are less central than MX, SPF, DKIM, and DMARC. However, they are still worth understanding when managing a more complex email environment.

How Email DNS Records Work Together

These records work together to keep email moving and help receiving servers decide whether a message can be trusted.

Imagine you send an email from [email protected] to someone at another domain. Your mail server first uses DNS to find the recipient's mail server. This is where the MX record comes in. It tells the sending server which mail server is responsible for receiving messages for the recipient's domain.

Once the message is sent, the receiving server can perform several checks before accepting it. SPF helps determine whether the server that sent the message is authorized to send email for the domain. The receiving server checks the domain's SPF record to compare the sending server against the domain's approved sources.

DKIM record provides another layer of verification. The sending server adds a digital signature to the email using a private key. The receiving server retrieves the matching public key from DNS and uses it to verify the signature. This helps confirm that the message was sent by an authorized system and that its signed content was not altered in transit.

A DMARC record brings SPF and DKIM together. It checks whether authentication results align with the visible From domain and tells the receiving server what to do when a message fails DMARC, such as taking no action, sending it to spam, or rejecting it.

Finally, PTR records support reverse DNS checks by connecting the sending server's IP address to a hostname. While PTR does not authenticate an email, consistent reverse DNS can help establish trust in the sending infrastructure.

Together, these records create a DNS-based framework that supports email delivery, authentication, and trust.

How to Check Your Email DNS Records

Here is how to check your email DNS records to spot configuration problems before they affect delivery:

Use a DNS Lookup Tool

A DNS lookup tool lets you check the records published for your domain without manually digging through DNS settings. For a quick check, you can use NSLookup.io’s DNS Lookup to view the DNS records associated with your domain.

Enter your domain and review the records returned by the lookup. You can also use an MX Lookup when you specifically want to check your domain’s mail servers.

What to Check

Start with the records that directly affect email delivery and authentication:

  • MX: Check that the correct mail servers are listed and that their priorities are configured properly.
  • SPF: Make sure there is a valid SPF record and that all legitimate sending services are authorized.
  • DKIM: Check that the required DKIM record and public key are available under the correct selector.
  • DMARC: Verify that the DMARC record exists and that its policy and reporting settings are configured correctly.

You can also check PTR records when reviewing your sending infrastructure, particularly for mail servers with dedicated IP addresses.

Best Practices for Managing Email DNS Records

Good DNS management helps keep your email reliable, secure, and easier to troubleshoot. Below are the best practices to follow:

Keep Records Accurate and Up to Date

Review your email DNS records whenever you add, remove, or change an email service. Outdated records can continue authorizing old services or point mail servers to systems that are no longer in use. Keeping your DNS configuration clean also makes it easier to identify problems when email delivery issues occur.

Document Third-Party Senders

Many organizations use third-party platforms for marketing emails, customer notifications, support messages, and other automated communications. Keep a record of every service that sends email on your domain and how it is authorized.

This makes it easier to update SPF and DKIM when a service is added or removed. It also helps prevent legitimate senders from being forgotten during DNS reviews.

Review SPF Regularly

Your SPF record should include all legitimate services that send email for your domain. Review it whenever your sending infrastructure changes. Pay particular attention to unnecessary include statements and other mechanisms that trigger DNS lookups.

You can use a credible SPF Lookup tool to check your SPF record and identify configuration issues. This is especially useful when reviewing whether your authorized sending sources are correctly published.

Also, avoid creating multiple SPF records for the same domain. A domain should have a single SPF record, and it should remain within the SPF 10 DNS lookup limit.

Rotate DKIM Keys

DKIM relies on cryptographic keys, so regularly rotating your DKIM keys is a useful security practice. When rotating keys, make sure the new public key is correctly published in DNS and that your sending service is using the corresponding private key.

You can use a DKIM Lookup tool to check whether your DKIM record and public key are correctly published. Do not remove an old key too quickly if messages are still being signed with it. Allow enough time for the transition to avoid authentication failures.

Move DMARC Toward Enforcement

Starting with p=none can help you monitor email authentication without affecting legitimate messages. Once you understand your sending sources and resolve authentication issues, consider moving toward p=quarantine and eventually p=reject.

A DMARC Lookup tool can help you check your published DMARC record and review its configuration before making policy changes. The goal is not simply to publish a DMARC record but to use what you learn from monitoring to build confidence and gradually strengthen your policy.

Monitor Authentication Reports

DMARC reports can show which systems are sending email using your domain and whether those messages pass authentication. Review these reports regularly to identify unknown senders, authentication failures, and configuration changes. Also, using a DMARC Report Analyzer helps turn these reports into clearer insights and get a better view of your email authentication activity. This gives you visibility into your email ecosystem instead of relying solely on individual DNS checks.

Avoid Unnecessary DNS Lookups

Keep your DNS configuration as efficient as possible. This is especially important for SPF because SPF processing is subject to a 10 DNS lookup limit. So, remove outdated services and unnecessary mechanisms where possible. A simpler DNS configuration is easier to maintain, troubleshoot, and keep within technical limits.

Email DNS Records: Key Takeaways

Email relies on DNS at almost every stage, from finding the right mail server to checking whether a message comes from a trusted source. There is no single email DNS record that handles everything. Instead, different records have different jobs.

MX records help direct incoming email, while SPF and DKIM support email authentication. DMARC builds on these checks to help protect your domain from spoofing. PTR records can support trust in your sending infrastructure, while other DNS records help connect and manage the underlying services.

Because these records work together, keeping them accurate and up to date is important. Regular DNS checks can help you catch configuration errors, authentication problems, and outdated records before they affect email delivery or security.

A well-managed DNS setup may not be visible to your users, but it plays a major role in keeping your email infrastructure reliable and secure. So, start free DNS monitoring to keep track of changes to your DNS records and get notified when something changes.