Bluesoft Website . Login -   Home
External Receiving Rules for our Mail Server

Table of Contents

  1. Introduction
  2. How to Fix the Problem
  3. External Receiving Rules
  4. Sequence of Lookups done by Mail Servers
  5. Quick Check using DNSReport.com

1. Introduction

To prevent spam, we check that mail servers that send us mail are properly registered. This is the new industry standard. If the server is not properly registered, the sender will get a clear error message from our server. In the past 6 months, our experience has been that we have detected 5 situations where legitimate servers did not have their reverse domains properly registered. In most cases, we were able to help the sender get their server properly registered, but in a couple of cases we specifically put the server onto a "white List" which allows us to receive mail from it, even though it is not properly registered.

2. How to Fix the Problem

If one of your customers phones you and says their email is getting rejected by our server, the first thing to do is ask exactly what error message they got back from our server. Don't assume every email problem is because of the reverse registration check. In the majority of cases, it is some other problem. In one case recently, the problem was that the sender mis-spelled the email address!

Assuming you verify the error message, what they are going to have to do is contact the person running their outbound mail server and get it properly registered. Here's what they can do to verify the problem:
 
  1. Ask what outbound mail server they are using. Eg: "mail.panfish.com".

2. "Ping" the mail server name to find its IP Address
Start up a command line window. Type
  "Ping mail.telus.net"

This will return the corresponding IP address. For example, mail.panfish.ca resolves to 216.127.78.25. Or "mail.pacificCoast.net" is 216.86.100.5

3. Check Reverse Lookup for that address There are various websites that will check reverse lookups. Here is one I have been using:

Remote.12DT.com
Type in the address of the mail server. If properly registered it will come back with the name of the domain associated with that address. Eg: 216.187.67.135 will give you "Mail.Millsoft.ca".

If the IP address is NOT properly registered, you will get back a message such as:


  Unable to resolve 216.127.78.25

4. Register the reverse DNS (What they must do) The only organization who can register the reverse address of a given address is the ISP who "owns" that range of addresses. Eg: Telus or Shaw Cable, or Peer 1. Therefore the person running the mail server has to contact their ISP to get the registration done.

3. External Receiving Rules

Here are the rules we enforce. "External Receiving" means the rules that our mail server enforces when receiving messages from external SMTP servers. Eg: If we receive a message from WhiteHouse.com. The general idea is that any sending email server must be properly registered, such that it is possible to verify that they are who they say they are. Most servers ARE already properly registered, so you probably won't run into any problems, however, if someone contacts you and says their email is bouncing, you can send them the list of standard registration requirements below, which they can forward to their Email administrator. We will assist with troubleshooting this if someone can't receive mail from an external domain although I'll expect the sender to add the reverse DNS record if they don't have one.

The External Receiving rules on our system are now:

- Sending smtp service IP must have an mx record
 - Sending smtp service IP must have a reverse DNS record
 - Sending smtp service IP cannot send more than 10 messages per minute to non-existant mail accounts on our system or they get blacklisted for 8 hours.
 - Sending domain cannot be in blackholes.mail-abuse.org Note: We do not yet require that the reverse DNS name or IP match the smtp service settings but this is coming. The Internal Sender / Relay rules are:

- Must verify with SMTP AUTH prior to sending messages or
 - Must have passed POP authentication within the last 15 minutes

4. Sequence of Lookups done by Mail Servers

Here is the sequence of lookups that a receiving SMTP server does when it is properly set up. For example, suppose our mail server receives a message from WhiteHouse.com, with IP address 111.111.111.111, which I will refer to as "111".

- when our server first receives a message, it looks up the reverse domain for 111, to see if it is really Whitehouse.com.

- If there is no reverse domain registered for 111, it rejects the message. (unregistered IP address)

- If the reverse registration for 111 is not "whiteHouse.com", it rejects it. Eg: Suppose the result of the reverse lookup shows that 111 is really registered to darkHorse.com.

- Assuming the reverse lookup validates the address, we then do a "forward lookup" on "whiteHouse.com" to make sure it is intended to have a mail server on 111. This is called an "MX" record for 111. This prevents someone or a virus from temporarily using one of their addresses to send spam.

5. Quick Check using DNSReport.com

The website dnsreport.com allows you to check a whole bunch of things on the DNS Records for a given domain. (Unfortunately it is sometimes down). In particular, you can use it to check the domain name of the mail server used by someone who is trying to contact you. For example, if someone is sending mail through "mail.PanFishCanada.com" and it is getting rejected, you can check "PanfishCanada.com".

The report does dozens of checks, not all of which are relevant to reverse DNS lookup. A more understandable approach might be to use the IP address method in the previous chapter.

Don't get confused by checking domains that do not specify do not run a DNS server.

Readers of this Page
2023.112023.122024.012024.022024.032024.04Total
181420111624103