3 ms·
Part 2 is a lot more useful (http://zohrob.com/posts/entrepreneurs-guide-to-email-delivery-part-2.html http://zohrob.com/posts/entrepreneurs-guide-to-email-deli
by mdasen 18y ago
Part 2 is a lot more useful (http://zohrob.com/posts/entrepreneurs-guide-to-email-delivery-part-2.html http://zohrob.com/posts/entrepreneurs-guide-to-email-deliver...). Part 1 basically says, if you want to run a mail server, use a dedicated IP for it. Part 2 actually goes into the anti-SPAM technologies that will make your messages appear as non-SPAM.
One thing that I would add to the section on SPF: don't say that any mail not coming from your domain is SPAM. It's a bad plan. Use it as a way to gain non-SPAM points if it does validate, but don't say that mail not coming from your servers is SPAM definitionally. Why? Because more and more people are forwarding mail and most mail forwarders do NOT rewrite the chain in a way that preserves SPF. Basically, if you deny all other domains, many people who forward their mail will see your emails as SPAM.
- jbyers 18y agoWe had the same experience when setting our SPF records to FAIL ("-all"). It turned out many more people than we expected forwarded our messages and had spam-flagging problems as a result. I'm curious if anyone who uses SOFTFAIL ("~all") can comment on how well it works? I see it in wide use now despite warnings that it's not appropriate for production use. Curiously, Microsoft's SenderID wizard calls the SOFTFAIL level "Discouraged" (meaning, mail from non-matching domains is discouraged) with no mention of its intended use for debugging.