TinkMail LogoTinkMail
Back to Blog

Email DNS Records: The Essential Guide to Proper Configuration

2025-04-22•10 min read•Email Technology

Introduction

DNS (Domain Name System) records are crucial components of email infrastructure that often operate invisibly behind the scenes. When configured properly, these records help ensure your emails reach their intended recipients, protect your domain from spoofing, and enhance your email deliverability reputation. This guide will walk you through the essential DNS records for email, why they matter, and how to configure them correctly.

Tired of managing complex DNS records for your business email? Let TinkMail handle your SPF, DKIM, and DMARC configuration with our enterprise-grade business email solutions. Explore TinkMail for Business →

The Core Email DNS Records

MX Records: Directing Email Traffic

MX (Mail Exchange) records are the foundation of email delivery. These DNS records tell the world where to deliver emails sent to your domain.

How MX Records Work

When someone sends an email to [email protected], their email server performs a DNS lookup to find your domain's MX records. These records point to the servers that should receive emails for your domain, along with priority values that determine which server to try first.

Proper MX Configuration

A typical MX record configuration looks like this:

yourdomain.com.    IN    MX    10    mail1.yourdomain.com.
yourdomain.com.    IN    MX    20    mail2.yourdomain.com.

The lower number (10) indicates higher priority. Email servers will try to deliver to mail1 first, and only if that fails, they'll attempt delivery to mail2.

If you're using a third-party email provider, they'll supply the MX records you should use. For example, Google Workspace MX records look like:

yourdomain.com.    IN    MX    1     aspmx.l.google.com.
yourdomain.com.    IN    MX    5     alt1.aspmx.l.google.com.
yourdomain.com.    IN    MX    5     alt2.aspmx.l.google.com.
yourdomain.com.    IN    MX    10    alt3.aspmx.l.google.com.
yourdomain.com.    IN    MX    10    alt4.aspmx.l.google.com.

SPF Records: Preventing Email Spoofing

Sender Policy Framework (SPF) records specify which mail servers are authorized to send email on behalf of your domain. This helps receiving mail servers verify that incoming email claiming to be from your domain is coming from a server authorized by you.

How SPF Records Work

SPF works by publishing a list of authorized sending IP addresses or hostnames in a TXT record. When a receiving server gets an email claiming to be from your domain, it checks the sending server's IP against this list.

Proper SPF Configuration

SPF records are published as TXT records and follow a specific syntax:

yourdomain.com.    IN    TXT    "v=spf1 ip4:192.0.2.0/24 include:_spf.google.com ~all"

This record breaks down as:

  • v=spf1: Specifies this is an SPF record using version 1
  • ip4:192.0.2.0/24: Authorizes the IP range 192.0.2.0 through 192.0.2.255
  • include:_spf.google.com: Includes all IPs authorized by Google's SPF record
  • ~all: Soft fail for all other sources (suggests rejection but doesn't require it)

Common SPF mechanisms include:

  • ip4: and ip6: for specifying IP addresses or ranges
  • include: for including another domain's SPF record
  • mx for authorizing your MX servers to send mail
  • a for authorizing your domain's A record IP to send mail

The policy specifiers at the end are:

  • -all: Strict policy (unauthorized sources should be rejected)
  • ~all: Soft fail (suggest but don't require rejection)
  • ?all: Neutral (no policy statement)
  • +all: Allow all (not recommended as it defeats the purpose of SPF)

SPF Record Limitations

SPF has some limitations to be aware of:

  1. DNS lookup limit: SPF allows a maximum of 10 DNS lookups
  2. No support for forwarded email: SPF checks can fail when email is forwarded
  3. Only checks the Return-Path: It doesn't verify the "From" header that users see

DKIM: Digitally Signing Your Emails

DomainKeys Identified Mail (DKIM) adds a digital signature to your emails that verifies they haven't been tampered with in transit and that they genuinely came from your domain.

How DKIM Works

When your email server sends a message, it uses a private key to create a digital signature of select parts of the email headers and body. This signature is added to the email headers. The public key is published in your DNS records, allowing receiving servers to verify the signature.

Proper DKIM Configuration

DKIM requires two steps:

  1. Generate a public/private key pair
  2. Configure your email server to sign emails with the private key
  3. Publish the public key in your DNS as a TXT record

A DKIM DNS record looks like:

selector._domainkey.yourdomain.com.    IN    TXT    "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3QEkUm..."

Where:

  • selector is a name you choose to identify this particular key
  • _domainkey is a required component of the record name
  • v=DKIM1 indicates this is a DKIM version 1 record
  • k=rsa specifies the key type (usually RSA)
  • p=... contains your public key

Many email service providers will handle DKIM signing for you and provide the DNS records to add. For example, if you're using Amazon SES, they might ask you to add a record like:

ses._domainkey.yourdomain.com.    IN    TXT    "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAhWEJ..."

DMARC: Bringing SPF and DKIM Together

Domain-based Message Authentication, Reporting, and Conformance (DMARC) builds upon SPF and DKIM to provide clear instructions to receiving servers about how to handle authentication failures and where to send reports about email activity.

How DMARC Works

DMARC requires either SPF or DKIM (preferably both) to be in place first. It then provides a policy that tells receiving servers what to do when an email fails these authentication checks. Additionally, it establishes a reporting mechanism so you can monitor who is sending email as your domain.

Proper DMARC Configuration

A DMARC record is published as a TXT record at a specific subdomain:

_dmarc.yourdomain.com.    IN    TXT    "v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected]"

This record includes:

  • v=DMARC1: Specifies this is a DMARC version 1 record
  • p=quarantine: Policy to apply (quarantine suspicious emails)
  • pct=100: Apply policy to 100% of suspicious emails
  • rua=mailto:[email protected]: Where to send aggregate reports

The policy options are:

  • p=none: Monitor only, take no action against failing emails
  • p=quarantine: Suggest placing failing emails in spam/quarantine
  • p=reject: Suggest rejecting failing emails entirely

Implementing DMARC Gradually

It's wise to implement DMARC gradually:

  1. Start with p=none to monitor without affecting delivery
  2. Review reports to identify legitimate sources you might need to authorize
  3. Once confident, move to p=quarantine with a percentage (pct=10, then increase)
  4. Finally, move to p=reject when ready for strict enforcement

Additional Helpful DNS Records for Email

PTR Records: The Reverse Lookup

PTR (Pointer) records provide reverse DNS lookup, mapping an IP address back to a domain name. Many email servers check PTR records as an anti-spam measure.

How PTR Records Work

When your email server connects to another server, the receiving server can perform a reverse lookup on your IP address. If this lookup returns a domain that matches (or is associated with) the domain you're sending from, it helps establish legitimacy.

Proper PTR Configuration

PTR records must be set up by the owner of the IP address block, typically your hosting provider or ISP. If you have a dedicated IP, you can request your provider to set the PTR record to your domain.

A proper PTR record configuration would point something like:

43.21.123.45    IN    PTR    mail.yourdomain.com.

BIMI: Brand Indicators for Message Identification

BIMI (Brand Indicators for Message Identification) is a newer standard that allows you to display your logo alongside your emails in supported inboxes, enhancing brand recognition and trust.

How BIMI Works

BIMI works by publishing a record that points to your logo in SVG format. When receiving servers get properly authenticated emails from your domain (using DMARC, SPF, and DKIM), they can display your logo to recipients.

Proper BIMI Configuration

BIMI requires:

  1. SPF, DKIM, and DMARC with at least a policy of p=quarantine
  2. An SVG logo in the required format
  3. A BIMI DNS record

The BIMI record looks like:

default._bimi.yourdomain.com.    IN    TXT    "v=BIMI1; l=https://yourdomain.com/logo.svg; a=https://yourdomain.com/certificate.pem"

Where:

  • v=BIMI1 specifies the version
  • l= points to your logo file
  • a= (optional) points to a Verified Mark Certificate (VMC)

Common DNS Configuration Mistakes

1. Improper SPF Syntax

One of the most common mistakes is incorrect SPF syntax, such as:

  • ❌ Multiple SPF records (only one is allowed per domain)
  • ❌ Including too many lookups (exceeding the 10 lookup limit)
  • ❌ Using outdated syntax like "v=spf1 +mx +a +ip4:192.0.2.1 -all"

2. Missing or Incorrect DKIM Configuration

Common DKIM issues include:

  • ❌ Incorrect selector names
  • ❌ Line breaks or spaces in the public key
  • ❌ Not enabling DKIM signing on your mail server

3. DMARC Implementation Errors

Watch out for these DMARC mistakes:

  • ❌ Implementing DMARC without SPF or DKIM in place
  • ❌ Starting with a policy that's too strict (p=reject) before testing
  • ❌ Not monitoring reports to identify legitimate email sources

4. General DNS Configuration Issues

Other common problems include:

❌ DNS propagation delays not accounted for when testing ❌ TTL (time to live) values set too high, slowing down changes ❌ Not using DNS validation tools to verify your records

Implementing and Testing Your Email DNS Configuration

Step-by-Step Implementation Guide

  1. Start with MX records

    • Set up your mail server or get your provider's MX record values
    • Add them to your DNS with appropriate priority values

  2. Implement SPF

    • Identify all services that send email on your behalf
    • Create your SPF record with the appropriate mechanisms
    • Start with ~all (soft fail) before moving to -all (hard fail)

  3. Set up DKIM

    • Generate your DKIM key pair
    • Configure your mail server to sign outgoing emails
    • Add the public key to your DNS

  4. Add DMARC

    • Start with a monitoring policy (p=none)
    • Set up an address to receive reports
    • Gradually increase enforcement as you gain confidence

  5. Consider additional records

    • Work with your hosting provider on PTR records
    • Implement BIMI if you want logo display capabilities

Testing Your Configuration

Always test your configuration before considering it complete:

  1. Use validation tools like:

  2. Send test emails to:

    • Gmail, which displays authentication results
    • Your own domain to check internal handling
    • Services that provide detailed headers analysis

  3. Review your DMARC reports to identify:

    • Legitimate sources you need to authorize
    • Potential spoofing attempts
    • Authentication failures that need addressing

Conclusion

Properly configured DNS records are essential for good email deliverability and security. By implementing MX, SPF, DKIM, and DMARC records correctly, you create a robust email authentication system that protects your domain from abuse and improves your chances of reaching the inbox.

Remember that email authentication is not a set-it-and-forget-it task. Regular monitoring of DMARC reports and periodic reviews of your DNS configuration will help you maintain a healthy email sending reputation and adapt to changing requirements.

Your email DNS configuration is the foundation of your domain's email reputation and security posture. Taking the time to set it up properly will pay dividends in improved deliverability and reduced risk of email-based fraud.