Essential DNS Records for a Mail Server

When setting up a Mail Server, installation is only half the work. The other crucial step is configuring the correct DNS records for your domain. Without proper DNS records, your emails may end up in the spam folder, fail to deliver, or be rejected by major providers like Gmail or Outlook.

In this article, we will walk you through all the essential DNS records you need to configure for a fully functional and reliable Mail Server.

MX Record (Mail Exchanger)

Purpose: The MX record specifies which server is responsible for receiving emails for your domain. Whenever someone sends an email to [email protected], the global mail system checks the MX record to locate the correct destination server.

Example:

@    IN MX 10 mail.domain.com.

• Always point the MX record to a hostname (e.g., mail.domain.com) instead of a raw IP address.
• That hostname must have a valid A record pointing to your server’s IP address.
• The priority number (10, 20, 30) determines which server to try first if multiple MX records exist.

A Record (Address Record)

Purpose: The A record maps a hostname to an IP address. For mail servers, this ensures that the hostname used in your MX record (such as mail.domain.com) can be resolved to a specific IP so that other servers can connect to it.

Example:

mail    IN A    123.45.67.89

• An A record is required for your MX record to function correctly.
• If you are using IPv6, you can also configure an AAAA record.

PTR Record (Reverse DNS)

Purpose: The PTR record provides reverse DNS lookup, resolving an IP address back to a hostname. If your server’s IP is 123.45.67.89, a reverse lookup should return mail.domain.com.

Why is PTR important?

• Major email providers like Gmail, Outlook, and Yahoo check for reverse DNS.
• Without a proper PTR record, emails sent from your server are highly likely to be marked as spam or rejected.

Important notes:

• PTR records are usually set up by your hosting provider or ISP, not in your own DNS zone.
• Make sure the PTR record matches your A record (IP → Hostname → IP consistency).

SPF Record (Sender Policy Framework – TXT Record)

Purpose: SPF is a TXT record that declares which servers or IP addresses are authorized to send emails on behalf of your domain. This helps prevent spammers from forging your email address.

Example:

@   IN TXT   "v=spf1 ip4:104.156.246.237 ?all"

Explanation:

• ip4:104.156.246.237 → Authorizes this IP to send emails.
• In an SPF record, all combined with a prefix symbol (-, ~, ?, +) determines how to handle emails from sources not listed in the SPF:
  • -all → Fail: Reject emails from unlisted sources.
  • ~all → Softfail: Suspicious, usually marked as spam but may still be accepted.
  • ?all → Neutral: No strong assertion, leaves the decision to the receiving server.
  • +all → Pass: Accept all sources (not recommended, defeats SPF’s purpose).

Best practices:

• Use -all instead of ~all if you want to strictly reject all other sources.
• Remember, SPF only verifies the sending IP; it should be combined with DKIM and DMARC for stronger protection.

DKIM Record (DomainKeys Identified Mail – TXT Record)

Purpose: DKIM works by adding a digital signature to your outgoing emails. The server signs each email with a private key, and the recipient server validates it using the public key published in your DNS record. This ensures that emails have not been tampered with.

Example:

default._domainkey   IN TXT   "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

Benefits:

• Protects against email spoofing and tampering.
• Improves domain reputation and inbox delivery rates.

Best practices:

• Your mail server software (e.g., Postfix, Exim, Zimbra) typically generates the DKIM keys.
• The public key is often very long, so make sure you copy it exactly as generated.

DMARC Record (Domain-based Message Authentication, Reporting & Conformance – TXT Record)

Purpose: DMARC builds on SPF and DKIM by providing domain owners with a way to specify a policy for handling emails that fail authentication. It also enables reporting, giving you visibility into attempted email spoofing.

Example:

v=DMARC1; p=reject; rua=mailto:[email protected]

Explanation:

• p=none → Monitor only, no enforcement.
• p=quarantine → Suspicious emails are delivered to the spam folder.
• p=reject → Emails that fail are rejected outright.
• rua=mailto:[email protected] → Email address for receiving DMARC reports.

Best practices:

• Start with p=none to monitor results.
• Once your system is stable, gradually move to quarantine or reject for stronger protection.

Additional Recommended Records

While not mandatory, the following records improve deliverability and user experience:

• CNAME for Autodiscover / Autoconfig: Helps email clients like Outlook and Thunderbird auto-configure mail settings.
• MTA-STS and TLS-RPT records: Enhance security by enforcing TLS encryption for mail transport.
• BIMI record: Displays your brand logo next to your emails in the recipient’s inbox, boosting trust and recognition.

Conclusion

A reliable email system requires more than just installing a mail server. Properly configuring the essential DNS records is key to ensuring your emails are delivered securely and trusted by other providers.

To summarize, your domain should have:

• Core records: MX, A, PTR
• Authentication records: SPF, DKIM, DMARC

When configured correctly, these DNS records not only allow your mail server to function smoothly but also improve security, reduce spam risks, and build a stronger domain reputation with providers like Gmail, Outlook, and Hotmail.