5 Replies Latest reply on Dec 4, 2015 9:30 AM by e8559477114a8c1df792e5ae2515db1558e484aa

    Guidelines around sending large amounts of email at once

      Hi all,


      We are a very high-volume email shop sending upwards of 30-50K a day to opt-in, registered users all via Trigger Campaigns and various automated nurture streams. With that in mind are there any best practices around sending batch emails on top of that, say 100K, for an additional promotion? We're somewhat struggling with maintaining our reputation in part due to the incredibly high volume of emails we send already and don't want to in any way jeopardize that by sending huge waves on top of that.


      Thanks, Dan

        • Re: Guidelines around sending large amounts of email at once
          Jamie Lewis

          Well, I can suggest that you use a dedicated IP for additional sends if you do not want to jeopardize your sender score.


          Also, make sure you have opted in email addresses.  Double opt in is the gold standard


          Thirdly, make sure you have warmed up your dedicated IP if you are using one by sending out smaller batched at first and then more and more on a daily basis after you have had success with the smaller batches.

          • Re: Guidelines around sending large amounts of email at once

            Good suggestions Jamie. Dain, I believe you might already know my points about another angle. But here are my 2 cents...


            Don't get Throttled...

            ISPs typically limit the amount of email they accept from a particular sender during a specified period of time. If you try to send email above their acceptable threshold, they will reject your email resulting in a high number of bouncebacks. Some times, it can lead to temporary block and some times even blacklisting. One of the ways a company can get placed on a blacklist is by sending too many e-mails from a particular IP address to particular servers.


            I had this issue with a customer who have their target audience as (small) institutions, based on what I learned that time, individual companies and smaller ISPs may set that threshold between 1,000 and 10,000 messages within a 10-hour period, while larger ISPs might have much higher limits, such as 50,000 per day per IP. For small institutes, it was even smaller.


            Some tips that might help,

            • Schedule emails to deploy over an extended period of time instead of all at the same time.
            • Segment your emails by domain or split your lists into multiple parts
            • If possible, separate your marketing and transactional email traffic between your 2 IPs to keep their reputations independent.
            • If there is a deadline date, start sending earlier so that all emails can be sent by your deadline date.
            • Monitor bounce responses in Marketo by creating a 'Leads by Email Invalid Cause' that will give what SMTP errors you are getting.



            Hope this helps



            Rajesh Talele

            1 of 1 people found this helpful
            • Re: Guidelines around sending large amounts of email at once
              Sanford Whiteman

              Beyond the great comments from Jamie and Rajesh, there's an (admittedly far-out) approach: sending some emails through a relay server that is under your control, i.e. not a Marketo-owned IP. 


              We have a client with a few obstinate customer domains, where individual end users (double-opted-in existing customers) are cool with receiving emails -- but their MX nevertheless deletes any emails submitted via Marketo IPs, period. So we route mail to those domains via an in-house mail relay on an IP range owned by the client. (We also rate-limit those sends using Postfix rate limiting.)


              In this particular case, we must send to those domains via the relay only.  You could adapt that model to do a initial send via the relay, then move people back to direct Marketo connections based on behavioral profiling.  For a simple example, if someone clicks on a Marketo email link, you could use that trigger to move them back.  This way, if you have IT staff capable of setting up a relay, but the they are -- understandably -- reluctant to support an in-house box for what's supposed to be a SaaS solution, you can give the relay a specific shelf life and then bring it down.  Naturally, the relay should be on its own subnet to not endanger the reputation of the corporate mail server!