1. 2
  1.  

  2. 2

    Separate your transactional and bulk sending streams using different domains or subdomains

    I’ve seen this advice frequently regarding transactional email, but I’m not sure I’ve seen a technical description of what problem it is solving. The implication has always seemed to be that you might burn that IP or domain and you wouldn’t want that to happen to a domain you’re “really” using. Is that why sending from a different source is recommended?

    1. 2

      Yes. It’s also more likely that GMail or a spam list gets enough spam flags from people who forgot they signed up to your list that they blacklist your bulk IP without contacting you. If they’re on the same IP, your first warning is that your support queue explodes because people don’t get password reset emails or core collaboration features are broken. If you contact a blacklist, the standard response is that they ignore you because their median response is a spammer lying to them. This outage can go days, weeks, or permanently. An extra IP or different service for transactional email is a very cheap insurance policy to save a business from maiming.

      1. 2

        This matches another realization I had around email on the Internet: given the nature of abuse reporting and blacklisting, an email provider needs to control their network down to the Autonomous System (AS) level. Abuse reporting and resolution is more effective between network operators than between domain name owners.

        That said, it seems your ‘cheap insurance’ decision would still apply even when you were a network operator. Faster resolution is not instantaneous resolution. It makes me wonder if my realization is true. Are there transactional email providers that don’t run their own network?