Email is delayed to Yahoo/AOL
Since May when we send email to Yahoo/AOL we get "delayed" messages and it can take up to 24 hours for the email to arrive, but it's in their spam folder. I am sure this issue started when someone sent 7 thousand emails a day to Yahoo, which got us put on this "delayed" list. I have run through all the tests with my exchange server to verify I am not blacklisted, and that my DKIM and PTR are setup correctly. I have filled out the Sender Support Request with Yahoo about 6 times now and they are no help. Does anyone have any suggestions on how I can get us removed from this "Delayed" list they seem to have us on?
ASKER
Thank you so much.
How do I go about writing my custom MTA code? And once I do that this problem with stop?
How do I go about writing my custom MTA code? And once I do that this problem with stop?
The way I approach sending to any Verizon property.
1) Set SMTP backoff resend period to 10x days, so message never resend, as almost all MTAs expire messages after 7x days.
2) Set initial send delay to 1x hour.
3) Stripe/Categorized each Verizon property into it's own mail queue... well... really every Mailbox Provider gets their own mail queue, as every single Mailbox Provider has their own internal policies... and all their policies violate the SMTP RFC. Period. 100% of all Mailbox Providers violate the RFC, so any off the shelf MTA will get your first internally blacklisted, then globally blacklisted.
4) Now sort each Mailbox Provider by highest engaged addresses first.
5) Now send 1x message + if it goes through (is accepted with a 250 success), then wait 1x hour to send the next message.
Continue sending messages, decrementing send delay by 1x minute till a delayed/throttled message occurs, then reset delay to 4x hours (per Yahoo TOS which says, once you get a certain message, you must wait 4x hours to send any message from your domain, else you're a spammer).
6) Then set the final threshold to time determined in #5 + 5 minutes.
7) Now resend starting at 4x hours - 1 minute till #5 + 5 minutes reached, then stay at this level.
The way to somewhat optimize this process is never use an opt-in box... ever... for lead acquisition.
Instead use an actual email address like... real-nifty-info@foo.com where people send an email to real-nifty-info@foo.com to get... something... really nifty...
This means Yahoo tracks that their users are sending foo.com email, hence foo.com trust increases.
Almost all problems with Verizon properties traces back to the incorrect leadgen approach of using an opt-in form.
1) Set SMTP backoff resend period to 10x days, so message never resend, as almost all MTAs expire messages after 7x days.
2) Set initial send delay to 1x hour.
3) Stripe/Categorized each Verizon property into it's own mail queue... well... really every Mailbox Provider gets their own mail queue, as every single Mailbox Provider has their own internal policies... and all their policies violate the SMTP RFC. Period. 100% of all Mailbox Providers violate the RFC, so any off the shelf MTA will get your first internally blacklisted, then globally blacklisted.
4) Now sort each Mailbox Provider by highest engaged addresses first.
5) Now send 1x message + if it goes through (is accepted with a 250 success), then wait 1x hour to send the next message.
Continue sending messages, decrementing send delay by 1x minute till a delayed/throttled message occurs, then reset delay to 4x hours (per Yahoo TOS which says, once you get a certain message, you must wait 4x hours to send any message from your domain, else you're a spammer).
6) Then set the final threshold to time determined in #5 + 5 minutes.
7) Now resend starting at 4x hours - 1 minute till #5 + 5 minutes reached, then stay at this level.
The way to somewhat optimize this process is never use an opt-in box... ever... for lead acquisition.
Instead use an actual email address like... real-nifty-info@foo.com where people send an email to real-nifty-info@foo.com to get... something... really nifty...
This means Yahoo tracks that their users are sending foo.com email, hence foo.com trust increases.
Almost all problems with Verizon properties traces back to the incorrect leadgen approach of using an opt-in form.
ASKER
The emails we are sending are normal business emails to clients/customers, we are not lead generating in any way. We do not have subscribers, so I am not sure we use an opt-in form?
We have been sending emails to Yahoo/AOL for 20 years with no problems, we have made no changes to any exchange server to cause these issues. Is this the only way to make this work?
We have been sending emails to Yahoo/AOL for 20 years with no problems, we have made no changes to any exchange server to cause these issues. Is this the only way to make this work?
ASKER CERTIFIED SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
The ways to handle this more easily.
1) Only do leadgen via email, never any opt-in form.
2) On your... opt-in page (with the email address), state right up front something like this...
Tip: I've been using this message now... since... sometime around 2000, because all Yahoo/AOL addresses have had this problem for years.
1) Only do leadgen via email, never any opt-in form.
2) On your... opt-in page (with the email address), state right up front something like this...
If you use a Yahoo or AOL email address, expect all or most of email from us + any order tracking (FedEx/UPS/USPS) to never arrive.
To receive 100% of your mail from us + most other sites, switch to a better email service.Tip: I've been using this message now... since... sometime around 2000, because all Yahoo/AOL addresses have had this problem for years.
Random Note: Many projects I manage, site owners have just opted to delete all Yahoo/AOL addresses, because when you're reported to global RBL lists by Verizon, then all Mailbox Providers either block you or throttle you.
ASKER
That is great advice about them but the problem is we deal with thousands of trucking companies who only seem to use Yahoo/AOL.
We do not have subscribers these are actual business emails addresses of companies and clients that we are providing service to.
We do not have subscribers these are actual business emails addresses of companies and clients that we are providing service to.
Then you'll have to interact with one by one to deal with this problem.
Suggested sequence.
1) First, Email != Money...
2) Determine which Email == Money, then start by interacting with these companies by phone.
3) Explain the problem to work out an alternative. For example, likely they have a Gmail address or run their own in-house IMAP server for trusted email sources. Your goal is to change over to using this trusted source email address.
4) For all Email != Money addresses, just delete them from your list... as these are just ticking time bombs... waiting to destroy your business income via RBL'ing your sending domain.
Suggested sequence.
1) First, Email != Money...
2) Determine which Email == Money, then start by interacting with these companies by phone.
3) Explain the problem to work out an alternative. For example, likely they have a Gmail address or run their own in-house IMAP server for trusted email sources. Your goal is to change over to using this trusted source email address.
4) For all Email != Money addresses, just delete them from your list... as these are just ticking time bombs... waiting to destroy your business income via RBL'ing your sending domain.
Just letting you know, witnessed the same issue delayed behavior was not 24 hours, but heavy unusual delivery with both and delays, just started last week with AOL and Yahoo. Have you looked at this, "throttling" article:
- Usually, it is a dead-end contacting Yahoo and AOL support, from what I've heard from fellow colleagues in the past. :(
- I'll let you know if I discover anything further as well
- Sometimes there are custom fixes or solutions as David suggested above.
- Interesting also if you read some fellow AOL and Yahoo customers feedback on DownDetector
ASKER
David, Thank you I am looking into all of these options right now to find the best solution.
Jazz, Thank you and yes they are not helpful. I will take a look at your link, I will try anything to get this problem solved. It is driving me crazy.
Jazz, Thank you and yes they are not helpful. I will take a look at your link, I will try anything to get this problem solved. It is driving me crazy.
The big consideration here is you simply can't use normal SMTP backoff anymore.
Well... you can... and this is a primary source of sites being RBL'ed right now.
Likely this will become worse over time.
If you get completely stumped, best to hire someone to work through how best to deal with your specific use case, as each case is unique.
Well... you can... and this is a primary source of sites being RBL'ed right now.
Likely this will become worse over time.
If you get completely stumped, best to hire someone to work through how best to deal with your specific use case, as each case is unique.
SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
Hiring Trick.
For this complexity of topic... likely best to search through GitHub for people who've worked on email systems for many years... preferably a decade or more... look at their GitHub project... then pitch your project to them...
This... approach... generally provides access to a far different... experience level type of consultant...
Trick #2: Search https://Meetup.com for experts speaking about Email Delivery/Inboxing to access other high quality consultants.
For this complexity of topic... likely best to search through GitHub for people who've worked on email systems for many years... preferably a decade or more... look at their GitHub project... then pitch your project to them...
This... approach... generally provides access to a far different... experience level type of consultant...
Trick #2: Search https://Meetup.com for experts speaking about Email Delivery/Inboxing to access other high quality consultants.
ASKER
Jazz and David, Thank you so much for your help.
You're welcome!
1) Once you send a message to Yahoo... then...
2) Yahoo sends a delayed message...
3) Only a custom written MTA takes to correct action of... never, ever, ever running the normal SMTP RFC backup resending sequence.
Running any common MTA - Sendmail, Postfix, EXIM, OpenSMTPD, or any relay like SendGrid or Mailgun... all SMTP code is the same.
When a 4XX temp failure returns, SMTP backup resending starts, which is... well... correct per RFC + will get you blacklisted internally inside Verizon (current owner of all Yahoo + AOL addresses)... so is RFC correct + logically incorrect.
4) You'll either write your own custom MTA code to...
a) Never do any form of auto-resending...
b) Never send any new message, till the actual send delay can be derived.
c) Send delay probing/derivation covered next...