Relay mail servers configuration

As documented on our postfix page, relay servers send email out to the world. This page provides additional information about how they are configured.

Domain Names and IP addresses

Since these servers rely on dozens of IP addresses to send email in parallel, adding and removing IP addresses to the configuration files is an on-going task.

Unlike most IP addresses, special DNS records are required for our outgoing relay IPs.

  1. Do not assign the IP address to the host - that will interfere with our ability to ssh into the server if we temporarily disable the IP address on the server.

  2. A record to the relay type domain: Assign an A record linking the IP address to the domain name representing it’s type, e.g. bulk.relay.mayfirst.org, priority.relay.mayfirst.org, or filtered.relay.mayfirst.org. This allows us to send email to the relay type and, using round robin DNS, get a long list of IP addresses that will be randomly used in a way that spreads the load.

  3. PTR record to the relay type domain: Each IP must also have a corresponding PTR record back to the relay type domain.

    Why? When postfix contacts the recipient mail server to deliver email, it identifies itself with it’s relay type domain.

    The recipient mail system typically checks the IP address, uses a reverse DNS lookup to confirm it points to the domain name that the sending server identifies as, and lastly does a direct lookup of the domain name to see if it also corresponds to the IP address. If any of these checks fail, the server may reject the email.

  4. A record to spf.mayfirst.org: You must assign the IP address to our SPF record to alert the world that this IP address is allowed to relay email on behalf of any domain that specified a:spf.mayfirst.org for their domain name.

Repeat bouncers

Protecting the reputation of our outgoing relay servers is critical to ensuring good deliverability rates.

One way our reputation is damanged is by sending a lot of email messages to email addresses that don’t exist.

Using Mr. T, we can generate a list of frequent bouncers and refuse to accept email with a known-to-bounce recipient before it even enters our queue.

By pre-bouncing these records, we can reduce the number of message attempts to addresses we know will bounce.

See our Mr. T page for more details.

Are we landing in the spam box?

Via pigeon, we regularly use filter-check to send messages to the three major providers Yahoo and see if we are landing in the spam box or the inbox. Gmail and Microsoft seem to send email to the spam box for unknown reasons.

While this doesn’t demontrate that all messages should land in the inbox, it does provide us with an alert if suddenly messages start going to spam.

DKIM Signing

The relay mail servers pass all email through opendkim, which adds a digital signature to the email header.

More info on how DKIM works is available on our dkim page.

Warming up an IP address

[triptick](https://code.mayfirst.org/mtmt/triptick] is the best tool for warming up an IP. It is installed on all our mail relay servers, but is not configured to run by default.

  1. Check the A record for warm.relay.mayfirst.org. Ensure it is reporting all our currently warmed up IP addresses.

  2. Pick a mailrelay that is not currently running an instance of triptick. Edit /etc/systemd/system/triptick.service. Set --interval 1h to limit deliveries to once an hour for each destination mail service. Include a --bind address and port for every instance that will be warmed up. Lastly include --fallback warm.relay.mayfirst.org so send all traffic to our warmed up IPs.

  3. In ansible, configure the Postfix instance with:

    check_recipient_mx_access: tcp:mailrelay001.mayfirst.cx:1724

The domain should match the mail relay you setup triptick to run on (note the .cx domain which resolves to our private IP range) and the port should match one of the ports configured for triptick.

  1. Restart the postfix instances you are warming up: systemctl restart postfix@postfix-bulkNNNN