Hostname Choice

This is a typical web server, hosting several websites, it doesn't receive emails ( I use Google Apps to receive email for these domains). It only sends out notification emails like this forum.

1. I always use mail.mydomain.com as my hostname, but I'm wondering if mydomain.com is a better choice in case of best practice of email delivery.

2. If the server hosts the following websites:

firstdomain.com
seconddomain.com
thirddomain.com

Hostname: mail.firstdomain.com

When the server sends out emails, the receiving email server only knows they are from mail.firstdomain.com, if a email was sent by a script on seconddomain.com, the SPF record for seconddomain.com doesn't matter at all, am I understanding it correctly?

Thanks!
 
Code:
1. I always use mail.mydomain.com as my hostname, but I'm wondering if mydomain.com is a better choice in case of best practice of email delivery.
Yes. it is. Otherwise, some of your emails may not delivered at their destinations.
Code:
When the server sends out emails, the receiving email server only knows they are from mail.firstdomain.com, if a email was sent by a script on seconddomain.com, the SPF record for seconddomain.com doesn't matter at all, am I understanding it correctly?
I used to think it does not matter. That is, SPF only works at the point of receipt but that is not always true. Your SPF must have it that the (sub-)domain is allowed to send emails just as the recipient's SPF will check that the domain is valid.
 
1. I always use mail.mydomain.com as my hostname, but I'm wondering if mydomain.com is a better choice in case of best practice of email delivery.
I wouldn't use either. The hostname should be some name below your domain, and IMHO, mail would only be appropriate for a single-purpose machine, that only sends mail. If this isn't the case, I'd pick a hostname to my liking and maybe configure mail (and, for web, the plain domain-name itself) as either a CNAME or an additional A record.
When the server sends out emails, the receiving email server only knows they are from mail.firstdomain.com, if a email was sent by a script on seconddomain.com, the SPF record for seconddomain.com doesn't matter at all, am I understanding it correctly?
This depends very much on the "envelope from" you're using (whatever is put in MAIL FROM: in the SMTP dialog). For any domain used there, the domain should have an SPF record allowing the IP address of your sending machine to send mail for that domain.

Additionally, you should also provide a way to receive mail for that domain, as some MTAs do sanity checks on the envelope-from addresses before accepting mail. So, add MX records for all your domains as well.

For best results, it's adviced to configure DKIM as well, see your MTA's documentation for how to sign your outgoing mails (and you need to configure the public signing key in DNS for all your domains as well).
 
I wouldn't use either. The hostname should be some name below your domain, and IMHO, mail would only be appropriate for a single-purpose machine, that only sends mail. If this isn't the case, I'd pick a hostname to my liking and maybe configure mail (and, for web, the plain domain-name itself) as either a CNAME or an additional A record.

This depends very much on the "envelope from" you're using (whatever is put in MAIL FROM: in the SMTP dialog). For any domain used there, the domain should have an SPF record allowing the IP address of your sending machine to send mail for that domain.

Additionally, you should also provide a way to receive mail for that domain, as some MTAs do sanity checks on the envelope-from addresses before accepting mail. So, add MX records for all your domains as well.

For best results, it's adviced to configure DKIM as well, see your MTA's documentation for how to sign your outgoing mails (and you need to configure the public signing key in DNS for all your domains as well).
All of these are correct. But an FQDN is best used for "sending" email servers.

Don't forget setting DMARC and s few other things too. The hostname must resolve to a valid IP address and vice versa (reverse) for all your emails to go through.
 
But an FQDN is best used for "sending" email servers.
To avoid any confusion, I think we mean the same thing here:

Let's say in this scenario, the server sending mails is called foobar.firstdomain.example, with CNAMEs mail.firstdomain.example and firstdomain.example. Then, you will have an A record for foobar.firstdomain.example and a PTR record mapping the IP address to foobar.firstdomain.example. In this case, the MTA should only use this primary hostname (FQDN) (and not "mail", for example) in any SMTP dialogs. Receiving MTAs do sanity checks on this as well, so if the hostname used in the SMTP dialog doesn't match forward and backward DNS resolution, this could easily add to a "spam score" or even have the mail rejected.
 
Thank you so much for your helpful replies, the email thing has always been very confusing to me.

I use Google APP to receive emails for all these domains, what a relief! The server only needs to send emails, because it hosts a few quite big forums, it does send a lot of emails. It worked well most time, every time I move to a new server, there may be a couple of weeks chaos, I need to contact some ISPs to unblock the IP due to its abusing history. Fortunately they always took quick actions.

Here is how I setup the whole thing:

hostname: mail.first.com: IP 1.2.3.4

Websites:

first.com: using IP 1.2.3.4 -> reverse IP to mail.first.com
second.com: 1.2.3.5 -> reverse IP to mail.first.com
third.com: 1.2.3.6 -> reverse IP to mail.first.com
fourth.com: 1.2.3.7 -> reverse IP to mail.first.com
fifth.com: 1.2.3.8 -> reverse IP to mail.first.com

All domains have the same MX and SPF records:

MX @ aspmx.l.google.com 1
MX @ alt1.aspmx.l.google.com 5
MX @ alt2.aspmx.l.google.com 5
MX @ aspmx2.googlemail.com 10
MX @ aspmx3.googlemail.com 10

v=spf1 a:mail.first.com include:_spf.google.com ~all

When domain third.com sends out emails, it's from "forum@third.com".

It worked well for many years, the only thing which didn't work is vBulletin contact page (since a couple years ago), when someone fills out a yahoo/AOL email address, the forum will try to send me the contact message:

From: someone@yahoo.com
To: forum@third.com (Receive by Google APP, gmail)

GMail will bounce the message because of DMARC policy, the bounced email goes to root@mail.first.com, and was forwarded to my personal email, I still get the email 😀, although it's a bit inconvenient to reply. So, I have been living with this problem. I'm moving the forums to xenForo, not sure if it can be fixed at the script level.

As you guys pointed out, I need to learn to setup DMRAC/DKIM. Before that, what should be changed in my above configuration?
 
first.com: using IP 1.2.3.4 -> reverse IP to mail.first.com
second.com: 1.2.3.5 -> reverse IP to mail.first.com
third.com: 1.2.3.6 -> reverse IP to mail.first.com
fourth.com: 1.2.3.7 -> reverse IP to mail.first.com
fifth.com: 1.2.3.8 -> reverse IP to mail.first.com
You mean all these IP addresses have a PTR record pointing to mail.first.com? Well, why? If I understand you correctly, only the machine on 1.2.3.4 will ever send mail, so that's the only one that needs such a PTR record. (Side note: for example names, use the TLD .example, it is reserved for such usage)

v=spf1 a:mail.first.com include:_spf.google.com ~all
[...]
As you guys pointed out, I need to learn to setup DMRAC/DKIM. Before that, what should be changed in my above configuration?
If I interpret this SPF record correctly, it means mail for the same domain is sent from google servers as well? Then it could be a bit tricky, AFAIK you can only have one public key for DKIM in your DNS -- but I might be wrong.
 
You mean all these IP addresses have a PTR record pointing to mail.first.com? Well, why? If I understand you correctly, only the machine on 1.2.3.4 will ever send mail, so that's the only one that needs such a PTR record.
You are absolutely right, I did this when I didn't understand reverse IP much, after that I just do it the same way without giving it a second though every time I get a new server. But, it should be good to have a reverse IP for each IP, right?

If I interpret this SPF record correctly, it means mail for the same domain is sent from google servers as well?
No matter which website sends out emails, to the receiving email server it's only mail.first.com. But if the receiving server check the from field, it goes to third.com, to 1.2.3.6, reverse to mail.first.com, from this point it seems good to reverse all IPs to mail.first.com.

From the email header:
google.com: best guess record for domain of root@mail.first.com designates 1.2.3.4 as permitted sender
 
Why don't you use a forwarding agent or an outbound SMTP? You would not need troubling yourself as you move from one provider to the other. There are many providers out there. Gmail, Yahoo, etc block emails from a number of private servers - new IP addresses etc.
 
But, it should be good to have a reverse IP for each IP, right?
Of course, and it should always point to the primary hostname. So, having multiple IP addresses resolve to the same name would only be correct if it's actually the same machine, having multiple network interfaces or alias addresses.
No matter which website sends out emails, to the receiving email server it's only mail.first.com. But if the receiving server check the from field, it goes to third.com, to 1.2.3.6, reverse to mail.first.com, from this point it seems good to reverse all IPs to mail.first.com.
I think there's some misunderstanding here:
  • What's relevant about reverse DNS is the name used by your MTA in SMTP dialogs. This has nothing to do with addresses used in mails. The receiving MTA will only do a reverse lookup on the IP address of the incoming connection and check whether the name matches what the sending MTA claims as being its name.
  • SPF comes into play when the "envelope from" address is checked (which is the address given in a MAIL FROM: SMTP command). The domain for this address is queried for an SPF record (so, you need SPF records on all domains that appear in an "envelope from"), and using the data from this record, it's decided whether the connecting machine is allowed to send mails for that domain.
  • The "From: header" isn't relevant at all, except for spam filtes checking whether it matches the "envelope from" -- but it doesn't strictly have to.
 
Why don't you use a forwarding agent or an outbound SMTP? You would not need troubling yourself as you move from one provider to the other. There are many providers out there. Gmail, Yahoo, etc block emails from a number of private servers - new IP addresses etc.
That's a good idea, the fewer tasks the server has to do, the better. I have 'outsourced" email receiving and dns server over the years. I will look into these options if they are free and reliable.

It just never occurred to me, as a working-alone amateur admin, if I didn't think of something, I just don't, no matter how obvious it is. I should read this forum more.

Of course, and it should always point to the primary hostname. So, having multiple IP addresses resolve to the same name would only be correct if it's actually the same machine, having multiple network interfaces or alias addresses.

I think there's some misunderstanding here:
  • What's relevant about reverse DNS is the name used by your MTA in SMTP dialogs. This has nothing to do with addresses used in mails. The receiving MTA will only do a reverse lookup on the IP address of the incoming connection and check whether the name matches what the sending MTA claims as being its name.
  • SPF comes into play when the "envelope from" address is checked (which is the address given in a MAIL FROM: SMTP command). The domain for this address is queried for an SPF record (so, you need SPF records on all domains that appear in an "envelope from"), and using the data from this record, it's decided whether the connecting machine is allowed to send mails for that domain.
  • The "From: header" isn't relevant at all, except for spam filtes checking whether it matches the "envelope from" -- but it doesn't strictly have to.
Many thanks for the detailed reply, it cleared up many confusing concept for me. I finally understand the purpose of reverse DNS.

I just compared the email headers sent from this forum and my own forums, very interesting. In the email header from my forum, it contains this:

spf=pass (google.com: best guess record for domain of

It seems to suggest that my SPF record is OK but not ideal.
 
Back
Top