Hi Mark, I think you are encountering the current state of play when sending to the big email providers from new IP addresses.
Microsoft in particular seems to throw you on the bad list straight away, but from the server responses you can see this and request de-lists. This is a bit like grey-listing to make sure those sending the mail are paying attention, one you skip through these hoops a few times if your mail is good it's good to go. I have seen this even from reputable domains using a new IP so if you're looking to send "mission critical email" from the off it's not a good idea, use the IP t send other reputable email which can accept a small bounce % first before moving over the more important email. As well as controlling the ramp up make sure your server is handling backoff, if your get certain responses don't keep knocking at the door. Stop, wait, retry. It all takes a lot of time we had to migrate 200 Million emails a month to a new /24 this was done over many months and not spinning an IP up for a weekend. Good luck Dave On Thu, 3 Sep 2020 at 20:23, L. Mark Stone via mailop <mailop@mailop.org> wrote: > Thanks Laura and Chris for your replies, and sorry if I wasn't as precise > in my language as perhaps I should have been. I've been in the email > business since 2005 and have been impressed with the general high > experience level of the posters on this list. I didn't think I needed to be > as specific as I think you wanted me to be -- especially because I was > asking for guidance regarding an optimal MTA IP "warm up" process, and just > using my case as an example of what happens when that process (if one > exists) is not apparently followed. > > 1) So to be clear, none of my nor my customers' domains are on blocklists > presently (nor were they at the time ~2 months ago), nor were/are any of my > MTA's IPs on any public block lists. > > 2) The IP address of the new MTA we attempted to put into limited > production was placed on the internal block lists of Microsoft, Google and > Mimecast (which I resell) the same weekend we put that new MTA into limited > production. Test emails we had sent prior to the production weekend to > those and other service providers all sailed through OK. The outbound email > we fed through the new MTA that weekend was a simply portion of the normal > outbound email we process through our existing MTAs. All of the email > processed through our existing MTAs that weekend was delivered successfully. > > 3) Microsoft's response was that this IP was not eligible for > remediation. I presumed, since none of the bounce messages in the logs > indicated anything regarding email contents, nor anything related to the > sending domains, that this was due to the IP being "new". > > So that was why I titled this thread "MTA Server IP "Warm Up" Reputation > Recommended Best Practices". > > We have other IPs we can use if needed, so again, I am less concerned > about improving this IP's reputation than I am with not repeating this > outcome. > > No one has yet indicated a better process for warming up an IP than > essentially "send some email" -- that's not something we can do with our > customers' production email flows. So if we need first to set up a > separate domain or two, and open a raft of Yahoo, Gmail and Outlook.com > accounts as destinations to create a reputation for an IP where we can > afford to have these emails blocked, and; then deal with any bounce > messages etc., OK. That process seems... sub-optimal at best. > > If anyone has a better process for warming up sending MTA IPs, I would be > grateful. > > With best regards to all, > Mark > ___________________________________________ > L. Mark Stone, Founder > Mission Critical Email LLC > > ----- Original Message ----- > From: "mailop" <mailop@mailop.org> > To: "mailop" <mailop@mailop.org> > Sent: Thursday, September 3, 2020 1:31:03 PM > Subject: Re: [mailop] MTA Server IP "Warm Up" Reputation Recommended Best > Practices > > On 2020-09-03 10:41, Laura Atkins via mailop wrote: > > > What “other block lists” are you on? Knowing that may help identify what > > you did wrong. It’s unusual for IPs to be blocked outright after 3 days > > of mail. What were you sending and to whom were you sending it? Who owns > > the IP? Where is it routed from? How did you acquire the IP address? Is > > it being routed? > > .... > > > This is one of those questions that’s very difficult to actually answer > > in the hypothetical. > > Precisely. We've seen this scenario many times before, new sending IP, > and seems to get listed right away even tho the volumes are kept low at > first. By not paying attention/investigating other listings, you might > not notice the fact that you made a glaring configuration error that > spells "infected!!!!!" to not just DNSBLs, but generalized inbox > filtering as well. But the person thinks it's to do with "new IP", > rather than "new IP with obvious problems". > > We see it all the time, and it's impossible to answer in the hypothetical. > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > -- [image: Instiller Logo] <https://www.instiller.co.uk> Dave Holmes Technical Director d...@instiller.co.uk T 0333 939 0013 | M 07966 013 309 1 Park Farm Barns | Packington Lane | Stonebridge | CV7 7TL Instiller is a trademark of Instiller Limited, registered in England 5053657. This email contains proprietary information, some of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission in error has misdirected this email, please notify the author by replying to this email. If you are not the intended recipient, you must not use, disclose, distribute, copy, print or rely on this email.
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
