6

I'm trying to implement (or make sure that I'm correctly following) email sending best practices to improve deliverability, but the role of the smtp server's host name vs the domain name of the From: email address seems to be unclear, even after reading dozens of people's articles/input.

Specifically, I understand that to satisfy the reverse DNS check, there must be a PTR record for the IP address of the sending machine that yields a domain name that matches the host name of the sending machine / SMTP server. Some say it needs to match the one given by the "hostname" command, most say it's the one provided with the HELO / EHLO statement, and this guy even says they MUST be the same (according to / enforced by what, I don't know; that's only a minor point of confusion, anyhow).

First, what I can't find anywhere is whether or not the domain name of the From: email address needs to match the domain name of the SMTP server.

So in my case, I have a VPS with linode. It primarily hosts a particular domain of mine, example.com, but I also sometimes do work on other projects: foo.com and bar.com.

So what I'm wondering is if I can just leave the default linode PTR record (which resolves to abc.def.linode.com), make sure that abc.def.linode.com is what my mail server (qmail) is configured to say at HELO, and then proceed to use it to send out emails for example.com, foo.com, et al.

If so, then I am confused by the advice given here, specifically (in a listing of bad case scenarios):

No SPF record for the domain being used in the HELO command

Why would THAT domain need an SPF record? And if it does, which domain should it provide whitelisting for: the HELO domain, or the domain of the From: email address (envelope sender)? Also, which domain would need to accept mail sent to postmaster@domain.com?

If the domains must be the same, that would seem rather limiting to me, because then for every domain you wanted to send email from, you'd have to get another IP address for it. It would also compromise or ruin one's ability to do non-email sending things (e.g. wget) relatively anonymously. However, the upside--if this is the case--is that it would make for a far less confusing setup.

I'm currently using the linode.com SMTP+PTR domain and example.com From: address combination without much of any deliverability issue, but my volume is very low and I'd like to know if someone out there has experience with larger volumes and has specifically tested the difference and/or has inside knowledge and/or has an authoritative answer (and source) for this particular question. I'm happy to clarify anything, let me know. Thanks in advance.

Jared Duncan
  • 61
  • 1
  • 2

3 Answers3

8

Note: There's some opinionated ranting in this. You're free to ignore it :)

Ok, this is email we're talking about, so we should start by saying there is simply no way to guarantee deliverability of a message. SMTP was devised in a quieter, more trusting time. Since then, many people have implemented what they see as the final solution to spam, only to be amazed that it hasn't worked; or that the spammers have figured out how to defeat it; or that it relies on everyone having done it to be effective. (or dozens of other reasons). What we have now is mess of balkanized systems and half-implemented ideas that mean that it's practically impossible to ensure your message will get through.

My opinion is that most of the best practice should be centred around receiving email, rather than sending it. As as sender, it's not your job to ensure it meets whatever random measures the recipient has in place. It's their job to ensure their filtering doesn't block legitimate mail based on assumptions about what a mail message should look like; many of which don't take full account of the interesting ways in which mail can be routed and delivered.

First, what I can't find anywhere is whether or not the domain name of the From: email address needs to match the domain name of the SMTP server.

In principal, no. There are many legitimate reasons why an MTA will send mail from addresses that have nothing to do with its own domain. You might come across systems that reject your mail for this reason, but this is not your problem. It doesn't hurt to have your PTR records match your domain and for the HELO announcement to match those, at least at the TLD; but anything that rejects purely because the From: domain doesn't match the PTR TLD is broken.

If so, then I am confused by the advice given here, specifically (in a listing of bad case scenarios):

No SPF record for the domain being used in the HELO command.

SPF records are another of these "it sounds right in principal" ideas (See here for another rant on that subject) that has gained a lot of weight. The main problem for me is that a lot of MTAs unfairly punish domains that simply don't publish any SPF at all. Again, this is not your problem.

That said, I've put one in place for our domains, because it's not done to get mardy with customer sysadmins too frequently. It ends up being a political decision, rather than a technical one.

If you're going to use SPF and leave your PTR and HELO as abc.def.linode.com; then the SPF record for all of your From: domains should list that server as a sender. If you don't have control over foo.com and bar.com DNS, then you'll have to talk to someone who does.

I'm currently using the linode.com SMTP+PTR domain and example.com From: address combination without much of any deliverability issue

and neither should you have. If you publish SPF at all and the linode.com seerver isn't listed, then you'll get bounced a lot. However, if you have listed it, or if example.com doesn't publish any SPF records at all, then you should be fine. (I repeat my earlier point that MTAs rejecting mail because there's no SPF published at all are broken and probably bouncing a lot of legitimate mail).

SmallClanger
  • 8,947
  • 1
  • 31
  • 45
  • Thanks for the time you took to type all of that up. I appreciate the affirmation that the MTA domain needn't match the `From:` domains. However, it seems you misunderstood my SPF question which was `why would THAT domain (in this case, linode.com) need an SPF record?` It would seem the advice of the person I linked to was bogus and that I wouldn't, in fact, need one for the MTA's domain at all. Also, I never said anything about guaranteeing whatsoever, just improving deliverability. Ideology, morally rich as it may be, ultimately carries little weight, so one is left to control what one can. – Jared Duncan Mar 09 '11 at 09:18
  • Specifically, `linode.com`'s DNS does not need to publish an SPF record on your behalf. SPF is about matching the envelope sender domain with a list of approved servers, the SPF records only need to be published by the DNS of the sender domains. I think what the post you linked was suggesting was the same idea, but referring to having the domain name of the MTA in the SPF record, since they can be listed by IP or domain. – SmallClanger Mar 09 '11 at 10:07
  • Also, I'm entirely with you on the deliverability front. You do end up having to jump through certain hoops to get the job done; I was ranting mostly just to give you some ammunition when a mail vanishes/bounces and people who think email should be perfect and instant want to blame you for it :) – SmallClanger Mar 09 '11 at 10:17
5
  • The domain in the From: address does not need to match the domain (if given any) in the SMTP HELO dialog. SMTP HELO serves a specific purpose.
  • It seems that some receiving server demands SPF on your domain. This is not mandatory though. However you cannot do much for policies and misconfigurations on the receiving side. If you want to publish SPF records, they should be for the sending domain and include the linode server that you are using.
adamo
  • 6,867
  • 3
  • 29
  • 58
  • +1. Good points (and good link.) – SmallClanger Mar 07 '11 at 11:28
  • Thanks adamo! Very direct and pertinent (if I could vote you up, I would). I understand that if an SPF record were to exist, it would be for the sending domains -- that's why I was confused by the person's advice that I linked to which said that one should exist for the **MTA's** domain (in this case, linode.com). Seems that person was wrong about that. Do you know at which domain (MTA's or sender's) the `postmaster@domain.com` would apply to? – Jared Duncan Mar 09 '11 at 09:26
  • I am not sure I understand your question: postmaster@domain.com is the *only* email address that RFC5321 requires to exist for all domains that send and receive email – adamo Mar 10 '11 at 10:53
  • 1
    Actually, [it serves two purposes](http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/smtp-avoid-helo.html). The second is not well known. – JdeBP Mar 26 '11 at 02:34
  • Updated my post to include a link to yours – adamo Mar 26 '11 at 20:38
1

Many large mail providers - Google are the obvious example - send email where the domain of the From address in the header does not match the PTR-record, and any provider that enforces (some kind of) a match between those two tokens will likely reject a lot of valid-email. Therefore, no, the domain name of the From: email address does not need to match the domain name of the SMTP server.

I would strongly recommend ensuring that the PTR-record matches the name that the server announces when it says HELO; the reason that spam-filters filter on this is that there's almost-certainly no reason for them not to match. You can set this explicitly in <qmail-control-dir>/helohost if you need to override <qmail-control-dir>/me.

nickgrim
  • 4,336
  • 1
  • 17
  • 27
  • Excellent point, I hadn't thought of that. D'oh! Of course. (and yep, I do have reverse DNS going for the MTA, so I'm set there.) Thanks for pointing that out! Sometimes it just takes another [thoughtful] mind. =) – Jared Duncan Mar 09 '11 at 09:33