Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] TLD for Personal Use - Email

> From: at [mailto:discuss-
> at] On Behalf Of Bill Horne
> I have a question about PTR records: can anyone confirm or deny that
> some ISP's are refusing mail from any domain without a PTR?

Well, since I wrote this reply before I read the rest of your message, here it is anyway.  Even though it doesn't answer your question:

Confirm.  But wrong terminology - A great number of recipient MTA's perform, as one of many validation tests, reverse lookup of the IP of the sending host.  The expected result varies, but the one sure thing, is that the best result is to make the reverse lookup match the forward lookup, match the EHLO, match the name that's on the MX record.

> I know that it's routine to require a PTR record from a sending host:
> that's not the issue. What I think is happening, however, is that emails
> from "bill at" won't be accepted unless there is a PTR record /for/
> "", not just a one-size-fits-all PTR for the "real" address of
> "". In other words, if I use "" as the mailhost for
> "", "", "", and some other domains, will I need to
> have a PTR record in place for each of those domains?

Now that I read the rest of your message, I'll say: should have their MX record set to ""
And resolves to some IP address.
And the reverse lookup of that IP address should be ""

It is common for one domain to use some other domain's mail servers.  Just look at anybody who uses Office365 or Google Apps.  The above configuration is precisely what we do.

BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!

Boston Linux & Unix /