Best Practices for preventing you from looking like a spammer

Question

I'd like to feel more confident setting up mail for my clients with regards to false positives. Here's what I know:

1. SPF records are good, but not every spam filter service/software (SFSS) uses them.

2. reverse DNS (PTR) records are pretty much a necessity.

3. Open relays are bad.

   (Here's "other tips" I've read):

4. the reverse lookup of the IP address of your mail server should resolve to the domain that you're sending mail out from.

5. your server should say HELO FQDN.of.your.mail.server.com when speaking to other mail servers.

6. the A host records in MX records should be (or resolve to to the IP address) your FQDN.of.your.mail.server.com

Feel pretty good about 1 and 3. Here's where I'd like some clarification/suggestions:

2 and 4: I did alot of digging and this seems to be incorrect as most spam-filters are looking for a PTR in general and one that's not generically-assigned by the ISP; it doesn't appear that the domain you send mail out as has anything to do with this (i.e. if you owned two domains you used for mail, you'd need to send out from two IP addresses with PTRs for each?)

5. This makes sense, but does it care what that FQDN resolves to? Should it resolve to the IP address that's currently sending said HELO?

6. Again, another one from various Google searches; don't see how this would work if you used Postini as your gateway service (or any other smarthost for that matter).

And what about sending on behalf of another domain that you're not authoritative for? I have some clients (some.branchdomain.tld) that are required to send mail out as @some.corporatedomain.tld, even though said corporate HQ won't setup a relay/smarthost for them to use. corporatedomain.tld can create SPF records to show that some.branchdomain.tld is allowed to send mail, but would that still be considering "spoofing", especially if said SFSS doesn't check SPF records? Should I be concerned about this?

Solution 1

I can vouch for #2 (reverse PTR) being important, but not #4 (mail server domain matching "from"). We set up mail servers all the time, and most mail hosts don't really even care about #2.

The main thorn is always AOL, and they list standards you can check off.

Solution 2

Aside from your HELO string and the DNS PTR records as mentioned, the bulk of the things that will help are going to be content related, not sending-sever related.

• Don't send out HTML email if you can at all avoid it.
• Don't include suspect phrases ("click to unsubscribe","privacy is important" and the like)
• Don't use "reply-to" headers, send from the address you wish responses to go to
• ...and more. Read the SpamAssassin ruleset for more good examples.

As to your question of "does it care what that FQDN resolves to?", this is entirely dependent on what the receiving mail server does, and it of course can vary, but you typically won't find too many mail servers relying on the FQDN lookup as a hard and fast rule, since it's possible to have multiple machines configured in a round-robin setup.

Solution 3

How about content guidelines? Keeping email sensible will help keep you from getting flagged as a spam producer in various systems. Train your clients to avoid forwarding "funny stuff" to everyone in their contact list, not signing up for email digests or newsletters, and using sensible malware protection mechanisms to keep from becoming part of a spam botnet...

Solution 4

4 is actually totally false. You might be thinking more along the lines of Sender Policy Framework, in which the DNS for a domain contains a record that states which SMTP servers are allowed to send mail with a From: header with that domain name. But the fact of the matter is that hosted domains usually have outgoing mail servers that are not the same as the domain name, but the ISP of the sender. For example if you have myvanitydomain.com and the e-mail address [email protected], but you use Sprint for your internet provider, you generally have to use Sprint's outgoing mail server to send e-mail. There are ways around this (like webmail, or POP-then-SMTP authentication), but that's a good example.

As for "how to make e-mail not look like spam", well... you don't make it look like spam, of course. The fact that you'd even consider using an open relay sounds... suspicious. I can't think of a single legitimate reason why you'd even want to, when every ISP has an SMTP server. If you're paying for server hosting from which you send mail, the way you don't get your IP address listed by various authorities is by not sending spam.

View more solutions

Comments

[Rowland Shaw]

The PTR should match the HELO, but not the sender (how else would virtual hosting cope?)

[Zoredache]

serverfault.com/questions/48428/…

[Cian]

Also, your PTRs should resolve forward to the same IP (i.e. if you have a PTR for 192.168.0.1 to mail.example.com, mail.example.com should have an A record pointing at 192.168.0.1

[gravyface]

Yup, that's how I usually do it.

[gravyface]

Haven't received any clarification on my "spoofing" scenario yet.

[user1124702]

Don't worry about spoofing. It is natural...get yourself added to the SPF record. But spoofing happens all the time, especially with residential Internet accounts where the ISP forces everyone to use their SMTP server.

[gravyface]

Yeah, good point; I never thought about that.