Reverse DNS with email server with multiple domains (1 IP)

What makes you think the reverse DNS is the problem? It is a normal and expected case that the domain of the reverse DNS will not match the domain of the email being sent. All that is likely to be checked by email receivers is that you have a reverse DNS entry for the IP and maybe that that name resolves back to the same IP.

Do you have SPF & DKIM set up?

Thanks for the reply.

Ive tried several online email checking websites and thats the only thing they complain about. SpammAssassin doesnt complain, SPF is fine, Sender ID is fine and im not in any email black list. They just complain about reverse DNS and not having DKIM (ive read its not a cause of problem, even though im not really sure. In a few hours ill try to set it up).

Allso just read something about DNS PTR, wich i cant yet get to understand cause its a new concept for me, but seems to be be able to affect email "health".

Hope to hear any good ideas for fixing this issue :-)

Thanks !!

When you connect to a remote machine it will look at your IP address (eg 1.2.3.4) and do a PTR lookup (equivalent of "nslookup -type=ptr 4.3.2.1.in-addr.arpa"). That will get a name "machine.example.com". It will then do a lookup of that name ("nslookup machine.example.com") and expect to see "1.2.3.4" as one of the results.

If this fails then you have a rDNS lookup issue.

(The same thing also happens for IPv6 if you make an IPv6 connection).

This name need not match the email domain name. It's perfectly fine to send mail with "fred@example.com" from a server not in the example.com domain; e.g. from a google server.

Thanks again for the efford in helping me :-)

Reverse DNS set up correctly but still having the same issue. Ill try to get DKIM working (i guess in dovecot) and hopefully it will work … if not im out of ideas.

Thanks !

PS- maybe its me, but it seems that getting email to work 100% is like trying to make a dinosour move.

In addition to what's been said about PTR/A lookups (if these don't match, mail will often go straight to /dev/null), there's this bit about HELO/EHLO names:

RFC 5321, section 4.1.4:

"An SMTP server MAY verify that the domain name argument in the EHLO command actually corresponds to the IP address of the client. However, if the verification fails, the server MUST NOT refuse to accept a message on that basis."

While this "MUST NOT" end up in /dev/null (assuming the receiving server is RFC compliant), it certainly may be tagged as spam based on this check alone.

Personally I find that insane but I've seen it happen.

To the OP:

Check that the HELO/EHLO reported by your mail server matches the forward (A) and reverse (PTR) records of its IP address, like so:

server.domain.tld > IP address (A record)

IP address > server.domain.tld (PTR record)

HELO/EHLO: server.domain.tld (placebo to please google's, hotmail's and other's asinine anti-spam configs)

For Postfix, the EHLO is set with the myhostname directive: myhostname = server.domain.tld

SPF/DKIM… yeah I use them, but they don't really have a lot of impact on whether your mail will be classified as spam or not.

IF you use them, make sure you got them right, or else they'll really hurt you. Badly. With a vengeance.

Other than that, well don't get blacklisted (which very rarely happens by accident) and don't hang around in bad neighborhoods (Linode's IP blocks have excellent reputation, for which I congratulate them).

That "MUST NOT" may allow the message to be sent to /dev/null. What it means is that the SMTP server can't reject the connection based on the HELO/EHLO value.

DKIM didnt do the trick either :(

Ill try to dig into the info draoidh gave (thanks) … Host name, DNS, Etc. By far i think this is the most complex daemon to set up in Linux. Pisses me off because it really works like a charm, sendeng and recieving emails really quick. Basically its just hotmail and gmail that send the emails to the Spam folder, tried with other email servers and they are cool with my emails. Maybe hotmail/google have a public email policy that i can get hold of to make things work.

THANKS.

https://support.google.com/mail/answer/81126

… interesting over all info from google gmail ….

@azarug:

Basically its just hotmail and gmail that send the emails to the Spam folder

Did you view the raw message in Gmail / Hotmail to see what the headers say? Sometimes there's a clue there.

Sorry for leving the post un attended ….

Things are working now. The three keys here are SPF, DKIM and DNS. SPF is easy to set up, DKIM is "weird" but following howtos found in google you can get it to work and DNS is easy to set from Linode. In my case DNS records was the key to make my setup work.

1- Make reverse dns to mail.domain1.com

2.- Create 2 entries as mx in domain1.com: mail.domain1.com and mail.domain2.com

3.- in each domain add this txt values:

name / value

v=spf1 a mx ~all

default._domainkey / v=DKIM1; k=rsa;p=((your key here))

adsp.domainkey / dkim=unknown

Hope this helps :-)

This rDNS setting is not enough. I've set that up for my linode domain─ and done SPF and DKIM, but one particular email filtering company is blocking my emails as spam. They are saying this below. Any comments very welcome

The listing is due to invalid or generic PTR (reverse DNS) Record for the IP. The PTR record designates ownership and authorized use of the IP. The IP needs to be given a fully qualified domain name which resolved back to that IP. lxxx-160.members.linode.com is a generic PTR. (x's added to mask the name)

For Example: mail.domain.com
Also, if the PTR starts with either: mail, mts, mx, out, smtp, that will help resolve the issue.
Please feel free respond to this message once the PTR record has been fixed, and the IP will be re-evaluated by the Threat Operations Team.

It looks like what the site is telling you that they want you to change your reverse DNS hostname. Essentially, they seem to be saying that your existing reverse DNS responds with a name that looks generic and/or not what they would expect to see for the domain(s) you're sending mail from. They are even suggesting that you use a primary hostname that indicates that the primary purpose of the system is a mail server. My personal experience is that the last request is probably optional, but the others probably are not.

So, if your email comes from the address dave@example.com, they are suggesting you make the primary hostname mail.example.com. To do this with Linode, go to the networking tab of your Linode and edit your reverse DNS names to the values you've picked. You should do this for both IPv4 and IPv6 (unless you have disabled one of them in your OS).

You will then need to go to your forward DNS server and add an A record for mail.example.com to your IPv4 address and an AAAA record for mail.example.com to your IPv6 address. (These should not be other record types, like CNAME.)

I would then suggest that you do whatever is needed in your OS to make your host think its primary hostname is the same thing that you just defined on your DNS servers. This probably involves editing your /etc/hosts file and your /etc/hostname file, although some distributions will have a slightly different process to do this. Essentially, you want the output of the 'hostname' command to be your hostname (e.g. mail.example.com). (Note that most distributions have a way to temporarily change your hostname that does not survive a reboot, so you may want to do a test reboot.)

Depending upon what you previously put in your SPF and/or DKIM records, you may need to change them to match the changes you just made.

All of these changes may not work right away if other sites already have one or more of your forward or reverse DNS entries cached. If that is the case, there isn't much you can do other than wait for the cache entries to expire. Shortening your DNS TTL values will help with this in the future, but that usually doesn't help you if an old/bad entry is already cached somewhere.

Hello and thanks for the detailed response.

Those are pretty much the same conclusions I have made. I'm really annoyed though - no other filter (so far) has made such demands. I mean the linode name is a FQDN, which is what they're after. Did their system automatically detect the linode name as 'generic'?

I also really don't want to call my server mail.xxxxx. I mean it's just not. I agree with you it looks like they'll be happy with mydomain.com as the servername.

However, it will be very very annoying if they then have a problem with mail from mydomain2.com going through mydomain.com. It's impossible to not have that with one IP address right?

It doesn't seem reasonable though, since most other places (including SMTP checkers) just do IP -> FQDN -> Reverse matches IP as their check.

I guess I'll rename my server then. I'd be interested to hear any other opinions on this though. The filter is Proofpoint, by the way

thanks for your help

I agree that a remote site shouldn't be able to dictate your network's host name strategy, but the error message you showed sure looks like that's what they are doing.

While I've usually setup aliases like 'mail', 'smtp', and 'imap' for my email servers, I've never used that as the primary hostname. (The hostname of my current mail server on Linode is from my "wild animals" name class.)

My guess is that the generic hostname test is based upon the fact that several large ISPs encode the IP address into the hostnames that they assign to home systems. In general, these home hosts should not be sending mail directly to arbitrary remote mail servers. So, much of the email that originates directly from these hosts (without going through a provider's mail server) is generated by various malware spambots. Some of these ISPs did little to deal with this problem, so I could see why such systems might get blacklisted. I've usually seen these blacklists implemented by manually-maintained lists that track the IP ranges of these systems, but it looks like Proofpoint may be trying to identify these hosts algorithmically rather manually maintaining these lists.

Most of the major mail systems have forms you can submit to report mail delivery problems due to overactive spam blockers. (Although getting to an actual human can sometimes be difficult.) I haven't personally had delivery problems with Proofpoint, but I have gotten problems delivering to other vendors fixed after I've filled out these forms. (Microsoft seems to be the provider my Linode host has had the most issues with.) Proofpoint is a big enough vendor that I would expect them to have such a system, so you may want to contact them. https://ipcheck.proofpoint.com/ or https://help.proofpoint.com/Proofpoint_Essentials/Email_Security/Administrator_Topics/110_logs/How_to_Report_False_Positive_and_False_Negative_messages may be useful.

Hi,
Thanks for that. Yes, I take your point about home systems, although it wouldn't be hard to distinguish linode servers since home systems (in my experience) get the full IP address whereas my linode one just has one octet.

I don't really mind changing the server name, and I've done that, but I have been in touch with them by email and ticket, and they've ignored most communication and just repeated what their blacklist text says. It's now three days since I 'fixed' and reported back to them, and I'm still blocked. Their form for messages probably wouldn't work with a banned email server, but I'll give it a try, especially if they don't fix soon.

regards
Dave

I have been working with a similar issue for over 6 months.
I am likewise seeing this issue with ProofPoint ( nowhere else).
I have also found that they do not respond to Support requests.
I had a little more luck when I sent them a message on Facebook.
They responded to that.
So far the issue is not resolved. I don't want to add 'mail' to my server name.

Just sent ProofPoint this email ( ID info hidden):

IP xxx.xxx.xxx.xxx has reverse DNS lixxxx,members.linode.com
I have tested it with various tools ( e.g. WhatIsMyIP.com) and it looks fine.
I do not want to change the host name ( e.g. adding mail.)Because the server is not just a mail server.
Also, I notice someone else using linode has been reporting the same issue.
Looks like you could have an issue with your logic that is causing this blocking?The IP does have a fully qualified domain name which resolves back to that IP.

Let's see what response I get ( if any :) )

IP xxx.xxx.xxx.xxx has reverse DNS lixxxx,members.linode.com

I personally assign a hostname for each of my servers under my own domain name (andysh.uk) - e.g. winter.andysh.uk. This is just any naming scheme I want (planets, cities, dictionary words, whatever) so it isn’t tying the server to a particular use. I run web, git, databases and mail services on the same Linode.

I then set my reverse DNS record to resolve back to my own hostname which is not seen as generic or default.

It is picky of Proofpoint, but I can understand it. I guess most spammers wouldn’t go to the hassle of configuring reverse DNS.