Improving Deliverability of Users' Emails Using Reverse DNS

Overview

If your users use virtual servers to send emails, mail servers may treat these emails as spam. In this topic, you’ll learn how to prevent this by enabling reverse DNS management in SolusVM.

Most mail servers use reverse DNS resolution to verify email domains and filter those that are likely to send spam. To do so, mail servers check for DNS PTR records. A PTR record, which is the reverse version of an A record, maps the IP address to the domain name. If the mail server detects no or an invalid PTR record, emails sent from the given IP address will land in spam.

Emails from your users’ domains are likely to be treated as spam because these domains don’t have PTR records by default. To give your users the ability to add PTR records and pass mail server checks, you need to enable reverse DNS management in SolusVM.

To enable reverse DNS management:

  1. Get a server with PowerDNS installed.

  2. Enable the PowerDNS API. To do so, you will need to add the info about an API key to the pdns.conf file. Copy the API key name because you’ll need it later.

  3. Log in to SolusVM and go to Settings > DNS.

  4. Select “PowerDNS” and then specify the hostname of your PowerDNS server and the API key name you copied during step 2. You can keep the Default reverse DNS record template, TTL, and Port fields filled in by default.

    PowerDNS configuration settings in SolusVM

  5. Once you fill in all the required fields, click Save.

  6. Determine which IP block contains IP addresses of the servers whose users send mail. Contact your hosting provider that allocated you this IP block. Ask the provider if they can delegate the IP block to the DNS server of your choice (which is the PowerDNS server in our case) using a reverse DNS zone.

    If the provider can delegate, give them PowerDNS name servers to delegate the reverse zone to. The provider will map the IP block to the reverse DNS zone.

    Ask the provider for the reverse DNS zone name. You’ll need it later. The name ends with in-addr.arpa for IPv4 or ip6.arpa for IPv6, for example, 168.192.in-addr.arpa.

    Note:

    If the provider cannot delegate the IP block, you cannot enable reverse DNS management unless you get an IP block from the provider that can delegate.

  7. Manually create the reverse DNS zone you received from the provider (168.192.in-addr.arpa) in PowerDNS server.

  8. In SolusVM, go to Network and add a new IP block or edit an existing one.

  9. Select Enable reverse DNS management.

    Enable reverse DNS management option in IP block settings

  10. Under Reverse DNS zone selection, choose how SolusVM should determine which reverse DNS zone to write PTR records into:

    • Specify zone manually (fixed) — Enter the name of the reverse DNS zone you received from the provider (for example, 168.192.in-addr.arpa), and optionally adjust the record name template (default {{fourth-octet}}). Every IP address in the block writes its PTR record into this single zone. This is the default for existing IP address blocks. Use it when the block is /24 or smaller and maps to exactly one delegated reverse zone.
    • Determine zone automatically (auto) — Select this option to have SolusVM determine the correct zone for each IP address individually. For every IP address in the block, it builds the IP address’s reverse pointer, finds the most specific matching zone that already exists in PowerDNS, and writes the PTR record there. SolusVM calculates the record name automatically using the reverse pointer minus the matched zone (for example, the 10.67.90.5 IP address in the 90.67.10.in-addr.arpa zone would receive 5 as its record name). SolusVM hides the manual zone and record-name template text boxes in this mode, so you don’t set them.

    Use auto mode for routed blocks larger than /24 (a /22 or /16 block, or an IPv6 block), since reverse DNS delegation happens per /24 (IPv4) or per nibble boundary, such as /64 (IPv6). A single manual zone entry can’t serve a block that spans multiple reverse zones. In auto mode, SolusVM resolves the right zone per IP address, so you don’t have to split the block.

    Reverse DNS zone selection options in IP block settings

  11. Click Save.

Note:

  • SolusVM never creates reverse DNS zones on your PowerDNS server, in either mode. It only writes PTR records into zones that already exist. Before switching a block to auto mode, confirm that every /24 (IPv4) or nibble-boundary (IPv6) zone the block could resolve to already exists in PowerDNS (see steps 6–7). If SolusVM can’t find a matching zone for a given IP address, PTR creation for that IP address fails with a no delegated reverse zone found error, and SolusVM writes nothing for that IP address.
  • Existing IP address blocks use fixed mode by default. Switch a block to auto mode explicitly to have SolusVM resolve the zone per IP address.

You’ve done your share of work by enabling reverse DNS management in SolusVM.

Now your users can add PTR records.

Note:

We call PTR records Reverse DNS entries in the SolusVM user interface.

To add a reverse DNS entry as a user:

  1. Go to https://<management-server-hostname>/login or https://<management-server-IP>/login.

  2. Under the desired project, click “… servers”, for example, “2 servers”.

  3. Click the server name.

  4. Go to the Networking tab and then click Add Reverse DNS entry.

    Add Reverse DNS entry button in server networking tab

  5. Specify the server IP address and the email domain.

  6. Click Save.

    Reverse DNS entry form with IP address and domain fields

You’ve added the PTR record for the server. Emails sent from this server now have higher chances of reaching the inbox.

Note:

Users can add PTR records mapped to the main and additional IP addresses.

Limitations

Reverse DNS management has the following limitations:

  • Auto mode doesn’t change how SolusVM handles network and broadcast addresses (.0 and .255 in an IPv4 block).
  • Auto mode doesn’t support RFC 2317 classless reverse delegation (reverse zones smaller than /24). If your provider delegates using RFC 2317, use fixed mode for that block.