Mail DNS Records

Posted on 15 2026

DNS is the foundation of email deliverability. The mail server itself can be perfectly configured, but if the DNS records are missing or incorrect, outbound mail will be rejected or classified as spam by receiving servers, and inbound mail may not arrive at all.

This page covers every DNS record needed for a self-hosted mail server: the required records that make basic delivery work, and the authentication records that tell the world your mail is legitimate.

Required records

MX record

The MX record tells other mail servers where to deliver mail for your domain. Without it, nobody can send you email.

; Mail exchanger for yourdomain.net
yourdomain.net.    IN    MX    10    mail.yourdomain.net.

The number 10 is the priority. Lower numbers are preferred. If you have a backup mail server, add a second MX record with a higher priority number:

yourdomain.net.    IN    MX    10    mail.yourdomain.net.
yourdomain.net.    IN    MX    20    mail-backup.yourdomain.net.

For a single-server setup, one MX record is sufficient.

A and AAAA records for the mail server

The MX record points to a hostname, not an IP address. The hostname must resolve to an IP:

; Mail server hostname
mail.yourdomain.net.    IN    A       your.wan.ipv4.address
mail.yourdomain.net.    IN    AAAA    your::ipv6::address

PTR record (reverse DNS)

The PTR record maps an IP address back to a hostname. Many receiving mail servers check that the sending IP’s reverse DNS matches the mail server’s hostname (Forward Confirmed Reverse DNS, FCrDNS). A missing or mismatched PTR record is a common cause of mail being rejected or spam-classified.

PTR records are set by your ISP or hosting provider, not in your own DNS zone. Contact your ISP to set:

your.wan.ipv4.address    →    mail.yourdomain.net
your::ipv6::address      →    mail.yourdomain.net

Verify the PTR record is correct:

dig -x your.wan.ipv4.address +short
# Expected: mail.yourdomain.net.

Authentication records

The following records are technically optional but practically mandatory. Receiving mail servers increasingly reject or spam-classify mail from domains without SPF, DKIM, and DMARC.

SPF record

Sender Policy Framework (SPF) specifies which mail servers are authorised to send mail for your domain. Receiving servers check the SPF record to verify that inbound mail claiming to be from yourdomain.net actually came from an authorised server.

; SPF record for yourdomain.net
yourdomain.net.    IN    TXT    "v=spf1 mx a:mail.yourdomain.net -all"

Breaking this down:

  • v=spf1: identifies this as an SPF record
  • mx: authorises the servers listed in the MX records
  • a:mail.yourdomain.net: also authorises the A record of mail.yourdomain.net
  • -all: reject mail from any server not listed (hard fail)

Use -all (hard fail) rather than ~all (soft fail) once you are confident the SPF record is complete. Soft fail still allows mail through and marks it as suspicious rather than rejecting it.

Important: only one SPF TXT record is allowed per domain. Having two SPF records causes both to be ignored by many receiving servers.

If you also send mail from other services (a newsletter service, a transactional mail provider), add them to the SPF record:

yourdomain.net.    IN    TXT    "v=spf1 mx a:mail.yourdomain.net include:sendgrid.net -all"

The SPF record has a limit of 10 DNS lookups. Each include: and mx mechanism that requires a DNS lookup counts toward this limit. Keep the record lean.

DKIM record

DomainKeys Identified Mail (DKIM) uses cryptographic signatures to verify that mail was not tampered with in transit and was sent by an authorised server. The mail server signs outgoing messages with a private key. The DNS record publishes the corresponding public key for receivers to verify the signature.

The DKIM keys are generated by the mail server software (Postfix with OpenDKIM or rspamd). The public key is then published in DNS.

The DNS record format uses a selector, which is an arbitrary name you choose. Using the year and month (e.g. 2026-01) makes key rotation easier to track:

; DKIM public key record
2026-01._domainkey.yourdomain.net.    IN    TXT    "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w..."

Replace the p= value with the actual public key generated by your mail server. The process for generating DKIM keys is covered in the OpenDKIM or rspamd configuration sections.

DKIM key rotation

DKIM keys should be rotated periodically. The selector-based approach makes this clean: generate a new key pair with a new selector, publish the new public key in DNS alongside the old one, update the mail server to sign with the new key, then remove the old DNS record after a few days.

A sensible rotation schedule is every six to twelve months.

DMARC record

Domain-based Message Authentication Reporting and Conformance (DMARC) builds on SPF and DKIM. It specifies what receiving servers should do with mail that fails SPF or DKIM checks, and where to send reports about authentication failures.

DMARC is published on the _dmarc subdomain:

; DMARC policy record
_dmarc.yourdomain.net.    IN    TXT    "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.net; ruf=mailto:dmarc-failures@yourdomain.net; fo=1; adkim=s; aspf=s"

Breaking this down:

  • p=none: policy for failing mail (none = monitor only, quarantine = send to spam, reject = reject)
  • rua=: address for aggregate reports (summary of authentication results)
  • ruf=: address for forensic reports (individual failure reports)
  • fo=1: generate forensic reports when either SPF or DKIM fails
  • adkim=s: strict DKIM alignment (the DKIM domain must match the From domain exactly)
  • aspf=s: strict SPF alignment (the SPF domain must match the From domain exactly)

DMARC policy progression

Start with p=none and monitor the aggregate reports for several weeks. The reports reveal whether legitimate mail is passing authentication and whether any illegitimate mail is using your domain.

Once you are confident that all legitimate mail sources pass both SPF and DKIM:

  1. Move to p=quarantine: failing mail goes to spam rather than being rejected
  2. Monitor for several more weeks
  3. Move to p=reject: failing mail is rejected outright
; DMARC quarantine policy (intermediate step)
_dmarc.yourdomain.net.    IN    TXT    "v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@yourdomain.net"

; DMARC reject policy (final state)
_dmarc.yourdomain.net.    IN    TXT    "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.net"

The pct=10 option applies the policy to only 10% of failing mail, which lets you test the impact of a stricter policy before applying it fully.

Reading DMARC reports

DMARC aggregate reports arrive as XML files attached to email. They are not human-readable by default. Several free services parse and visualise DMARC reports:

  • https://dmarc.postmarkapp.com/ (Postmark’s free DMARC report parser)
  • https://dmarcian.com/ (has a free tier)

Point the rua= address at one of these services during the initial monitoring phase.

Additional records

MTA-STS

Mail Transfer Agent Strict Transport Security (MTA-STS) tells other mail servers that your server supports TLS and that connections must use it. This prevents downgrade attacks where an attacker intercepts the SMTP connection and strips TLS.

Publish a DNS TXT record:

; MTA-STS policy indicator
_mta-sts.yourdomain.net.    IN    TXT    "v=STSv1; id=20260101000000Z"

Create the policy file at https://mta-sts.yourdomain.net/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: mail.yourdomain.net
max_age: 86400

This requires the mta-sts.yourdomain.net subdomain to have a valid TLS certificate and serve the policy file via HTTPS.

TLS-RPT

TLS Reporting (TLS-RPT) sends reports about TLS connection failures to the specified address:

; TLS reporting
_smtp._tls.yourdomain.net.    IN    TXT    "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.net"

BIMI

Brand Indicators for Message Identification (BIMI) displays your logo next to email in supporting clients (Gmail, Yahoo Mail, Apple Mail). It requires a verified DMARC p=reject policy and a Verified Mark Certificate (VMC) from an approved certificate authority, which carries a cost. BIMI is optional and primarily relevant for domains with a recognisable brand.

If the requirements are met:

; BIMI logo record
default._bimi.yourdomain.net.    IN    TXT    "v=BIMI1; l=https://yourdomain.net/logo.svg; a=https://yourdomain.net/vmc.pem"

Complete DNS record reference

A complete mail DNS configuration for yourdomain.net:

;; Required records
yourdomain.net.                         IN    MX     10    mail.yourdomain.net.
mail.yourdomain.net.                    IN    A           your.wan.ipv4.address
mail.yourdomain.net.                    IN    AAAA        your::ipv6::address

;; SPF
yourdomain.net.                         IN    TXT    "v=spf1 mx a:mail.yourdomain.net -all"

;; DKIM (replace key value with actual generated key)
2026-01._domainkey.yourdomain.net.      IN    TXT    "v=DKIM1; k=rsa; p=YOUR_PUBLIC_KEY_HERE"

;; DMARC
_dmarc.yourdomain.net.                  IN    TXT    "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.net; fo=1"

;; Autoconfig (from previous section)
autoconfig.yourdomain.net.              IN    CNAME       mail.yourdomain.net.
autodiscover.yourdomain.net.            IN    CNAME       mail.yourdomain.net.
_autodiscover._tcp.yourdomain.net.      IN    SRV    10 10 443    autodiscover.yourdomain.net.

;; MTA-STS
_mta-sts.yourdomain.net.               IN    TXT    "v=STSv1; id=20260101000000Z"
mta-sts.yourdomain.net.                IN    CNAME       mail.yourdomain.net.

;; TLS-RPT
_smtp._tls.yourdomain.net.             IN    TXT    "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.net"

Verifying the records

Check all records are correctly published:

# MX record
dig MX yourdomain.net +short

# SPF
dig TXT yourdomain.net +short | grep spf

# DKIM
dig TXT 2026-01._domainkey.yourdomain.net +short

# DMARC
dig TXT _dmarc.yourdomain.net +short

# Reverse DNS
dig -x your.wan.ipv4.address +short

# MTA-STS
dig TXT _mta-sts.yourdomain.net +short

Use an online mail authentication checker for a comprehensive check:

https://mxtoolbox.com/emailhealth/
https://toolbox.googleapps.com/apps/checkmx/

Send a test email to check-auth@verifier.port25.com and review the authentication report that comes back. It checks SPF, DKIM, and DMARC alignment and reports the result clearly.

Common problems

Mail going to spam: check SPF alignment and DKIM signing. Verify the PTR record matches the mail server hostname. Review the DMARC aggregate reports.

Duplicate SPF records: having two TXT records starting with v=spf1 on the same domain causes both to be ignored. Merge them into a single record.

SPF lookup limit exceeded: if more than 10 DNS lookups are needed to fully evaluate the SPF record, some servers will fail the check. Use include: directives sparingly and flatten SPF records where possible.

DKIM signature mismatch: verify the public key in DNS matches the private key on the server. Check that the selector configured in the mail server matches the selector in the DNS record.

DNS changes take time to propagate. After adding or changing DNS records, allow up to 48 hours (depending on your TTL values) before concluding a record is not working. Use a low TTL value (300 seconds) when making changes and restore it to a higher value (3600 seconds or more) once the records are confirmed correct.