Proper Email Delivery Help with Reverse DNS and Etc.
I looking for advice on getting better email delivery from our companies direct email relays using Sendmail on Red Hat. We've had some recent problems with grey listing and blocking due to reverse DNS on the sending IP address we lease from an ISP, and perhaps other related things.
I have not setup any reverse DNS with my ISP.
We are our own authoritative DNS, and have our own DNS servers.
We masquerade our outgoing emails as our main domain name. Lets say it is "domain.com".
We have SPF TXT records in our authoritative DNS servers for our "domain.com" with IP addresses (subnets) in them to aid in email delivery. I'm not sure how effect this is, but it doesn't hurt to have it there I guess.
We use Microsoft Office 365 Exchange Online for our email service (not sure if that is relevant). I don't really want to use them for a relay from our internal relay, although that is an option I know about and choose against using a good while ago. My preference is to use direct relays not involving them. I guess if in the end it is a viable option after all is taken into consideration, I can switch to using them as the final relay, I guess. We'll see on that.
The IP address the emails go out on is the first IP address in our ISP block. This is the base IP address for the firewall, and the one the recipient email server sees. Lets say it is "67.67.67.4". It does not reverse DNS correctly to "domain.com". I know I will need to do that at some point in all this of course.
The IP address of our main domain ("domain.com") DNS is different from the first IP address in our ISP block. Let's say it is "67.67.67.10" for "domain.com". Unfortunately, that is the way I have it setup (I'm sure I'm not the only one!). That poses a possible problem in doing the DNS lockups in both directions resulting in a full match. I'm sure there are email servers out there that check that. I'm looking for good (or as best as possible) solutions on that.
We also have multiple WAN connections (3) that outgoing emails might go out on, each taking on the characteristics of the above. I know I will need to do a similar thing on each.
Thanks!
I have not setup any reverse DNS with my ISP.
We are our own authoritative DNS, and have our own DNS servers.
We masquerade our outgoing emails as our main domain name. Lets say it is "domain.com".
We have SPF TXT records in our authoritative DNS servers for our "domain.com" with IP addresses (subnets) in them to aid in email delivery. I'm not sure how effect this is, but it doesn't hurt to have it there I guess.
We use Microsoft Office 365 Exchange Online for our email service (not sure if that is relevant). I don't really want to use them for a relay from our internal relay, although that is an option I know about and choose against using a good while ago. My preference is to use direct relays not involving them. I guess if in the end it is a viable option after all is taken into consideration, I can switch to using them as the final relay, I guess. We'll see on that.
The IP address the emails go out on is the first IP address in our ISP block. This is the base IP address for the firewall, and the one the recipient email server sees. Lets say it is "67.67.67.4". It does not reverse DNS correctly to "domain.com". I know I will need to do that at some point in all this of course.
The IP address of our main domain ("domain.com") DNS is different from the first IP address in our ISP block. Let's say it is "67.67.67.10" for "domain.com". Unfortunately, that is the way I have it setup (I'm sure I'm not the only one!). That poses a possible problem in doing the DNS lockups in both directions resulting in a full match. I'm sure there are email servers out there that check that. I'm looking for good (or as best as possible) solutions on that.
We also have multiple WAN connections (3) that outgoing emails might go out on, each taking on the characteristics of the above. I know I will need to do a similar thing on each.
Thanks!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks!
The ISO will need to create delegation for
67.67.67.in-address.arpa zone
0-63 In NS ns1.yourdomain.com.
0-63 In NS ns2.yourdomain.com.
Then for every ip
2 In CNAME 2.0-63.67.67.67.in-address
3 In CNAME 3.0-63.67.67.67.in-address
.
.
62 In CNAME 62.0-63.67.67.67.in-addres
On your side, you would define a zone 0-63.in-address.arpa
2 in PTR hostname2.domain.com.
.
.
62 in PTR hostname62.domain.com.
Some servers rely on DNSRBL lists which are used as honey pots where if your setup does not validate the recipient, (opt-in) when your system delivers an email, that then publishes the sending Ip as a source of spam. Other lists get info and list ip segments in their list.
The other check your txt record, ns lookup -q=txt domain.com.
MS office365 includes info in their setup instruction to add an SPF record, double check that your IPs are listed as permitted to send emails using domain.com.
Certain routers/firewalls allow a configuration to randomize the source IP reflected of packets.
Grey listing is fine as long as your process uses a mail server that will requeue the message and will try again.
I think I covered most aspects of what you raised.