

Entrepreneur's Guide to Email Delivery - rantfoil
http://zohrob.com/posts/entrepreneurs-guide-to-email-delivery-part-1.html

======
mdasen
Part 2 is a lot more useful ([http://zohrob.com/posts/entrepreneurs-guide-to-
email-deliver...](http://zohrob.com/posts/entrepreneurs-guide-to-email-
delivery-part-2.html)). 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
We 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.

------
CalmQuiet
The world email system is broken... Makes me wonder about proposed "solutions"
such as the mini-charge per email sent. I'm not sure I see _the_ fix in this
post, but at least it's forewarning us about some temporary workaraounds - and
some helpful education. Just one more issue for providers of web services to
get up to speed on :(

------
bprater
AuthSMTP was mentioned at Y!Hack a few weeks ago and I'm using it now in a
webapp with great success.

~~~
mdasen
AuthSMTP is a nice idea and I would pay their rates if they were metered like
Amazon's Web Services. The problem is that I often don't know how many emails
I'll need to be sending. For example, let's say they had a simple charge of
$0.001 (one tenth of a cent) for each email sent plus $0.005 (one half of one
cent) per MB sent. That would work nicely (and be in line with what they
currently charge).

The problem is that I have to decide on what plan to buy. AWS' model works
nicely in that it works for a tiny bit or a lot.

