Forum Discussion
messg spam from my office email to yahoo
when i send a mesg from my office to yahoo , the message enter to inbox folder , then after 1min or 2min , the message fall to junk folder , can someone help me with this , or explain to me what goi...
It seems like until someone at Microsoft wakes up and fixes their reputation or whatever else is causing this issue, we are all stuck in the middle of the end users complaining their emails aren't getting delivered and hoping the recipients will add the sender to their address book (which kind of works).
Has anyone found a reputable smtp relay service that is compatible with 365/Exchange Online? I had thought I'd just route outbound mail through SendGrid till this gets resolved, but that requires a password on the send connector and I'm not aware of any way to specify a password on the send connector with Exchange online.
I suppose the problem with a service that works without a password is that in theory is a quasi open relay and it would take anything from your domain and deliver it. If that service was more basic and didn't touch the email, DKIM signing from MS should continue to work to differentiate legitimate from illegitimate email, I think.
I'm actually about to set up with SendGrid as their salesperson stated that, people have used their services as an SMTP smart host with O365 services in the past..
Though a sales person from SMTP.com said the same exact crap, and I ran into a similar issue where IP Auth can only be used with O365 with their services. Though they also don't take DNS entries or IPv6.. Their support team also don't seem to have a handle on how email works either, and don't understand the concept of what we are doing here. Hopefully, I don't have a repeat with SendGrid.
But I think our only option is to setup this client with proofpoint or a 3rd party outbound spam filtering service, to circumvent this issue. As it seems like these SMTP relay companies are pretty old school with their methods, and were developed with email marketing in mind, not as a true SMTP Smart Relay.
It is extremely unfortunate that no one on Yahoo or Microsoft(even though I don't this its their problem) is taking accountability for this issue. Nor is this issue getting the attention that it deserves. For an entire month, this has been going on, with no resolution in sight. Wish I could be this incompetent at my job.
Though a sales person from SMTP.com said the same exact crap, and I ran into a similar issue where IP Auth can only be used with O365 with their services. Though they also don't take DNS entries or IPv6.. Their support team also don't seem to have a handle on how email works either, and don't understand the concept of what we are doing here. Hopefully, I don't have a repeat with SendGrid.
But I think our only option is to setup this client with proofpoint or a 3rd party outbound spam filtering service, to circumvent this issue. As it seems like these SMTP relay companies are pretty old school with their methods, and were developed with email marketing in mind, not as a true SMTP Smart Relay.
It is extremely unfortunate that no one on Yahoo or Microsoft(even though I don't this its their problem) is taking accountability for this issue. Nor is this issue getting the attention that it deserves. For an entire month, this has been going on, with no resolution in sight. Wish I could be this incompetent at my job.
- NLart, please keep us posted if SendGrid is able to support this, as they told me they don't have any possibility to accept a connection without credentials. The alternate way is to connect my "application" with Zapier. If someone from SendGrid is reading this, see ticket 8823518.
As you mentioned these smtp relay services were setup to send messages from applications, not a full scale smtp smarthost.
Of everyone I reached out to, smtp2go had the best response and gave me an immediate solution.
Proofpoint or something is certainly an option as well, but likely at additional per user costs. We've used services like that in the past, but have been trying to get all in on 365. However, if Microsoft doesn't even care to address a huge problem like email deliverability, it does make you wonder if we are moving in the correct direction.- Unfortentually we didn't go with sendgrid.
They flagged my signup as suspicious, and after wasting 2 days with their support, and them coming back with, "Please provide your LinkedIn info to verify your identity" made me just switch to proofpoint. SMTP2GO was another option, and they "said" you can use their API with O365, their documentation was very generic, and just went over the API on their side without vetting any configuration with O365. I don't think the rep fully understood what I was trying to accomplish since why would anyone normally would want to send all their email out O365 through a SMTP relay service.
Just switched mail flow to proofpoint not too long ago for our client. Here what was found.
Sending from our mailbox in the customer's domain, that we previously stated not as spam in our att mailbox, ended up in the spam folder.
Sending email from a new or a mailbox we haven't tested with in the past, from the customer domain, does not end up in the spam folder to our att test mailbox.
We created a new mailbox at aol.com
Found that all emails went through without issues.
Coworker's yahoo mailbox also received the messages without issues from the customer's domain. At first it did end up in the spam, but appeared to clear up without his interaction with the second email. At this time I also stopped DKIM signing from Microsoft, and did it directly from proofpoint.
Had the CEO of the client email those three mailboxes, all went through, nothing ended up in spam.
(not related but for the lulz)
Emailed from my AOL test box and to my att test one, and vice versa. both ended up in spam lol
I don't have the complete warm and fuzzies considering how mail I once flagged as not spam, ended back up in the spam box. I'll take this improvement through. Will have to monitor it over the next few days.
Why do I think this isn't a Microsoft problem?
Because the client also uses a 3rd party website used for volunteer signup.
While I do have to address this with the end-user who manages it. While the From domain, sends out with the website's domain name, the reply to is set to the customer's domain. This voulentier sign up a website also doesn't support DKIM, thus I see the fails in my DMARC reports for DKIM from yahoo.com, and co.
But yet.. all of that mail goes through and gets to yahoo.com's inbox, even though its failing DKIM. I only have DMARC in reporting mode at this time until I can clean it up.
So scottchester it seems like we were able to get around this problem using a spam filtering service that can filter/relay outbound. While more costly than a SMTP relay service, I at least have emails that would of ended up in the spam folder, in the inbox now.
Though while I don't think it would be the case here. Are all of you that are having issues signing DKIM outbound from O365? As at first, I figured I was going to have mix results with this until I removed DKIM signing on microsoft's side and just had Proofpoint doing it. It actually made a difference. Could be nothing and just things straightening its self out from the changeover, as I can't see why a DKIM signature from Microsoft in the message headers would trip yahoo mail services to flag it as spam..
But at this point, if mail gets to the inbox for yahoo mailservices domains. I really don't care what it was lol- NLart glad to see you found a workaround.
My first thought is that the IP of your website must be better than Microsoft's, but that's an interesting data point about emailing from att to yahoo and it ending up in the spam.
It seems like probably yahoo and microsoft both have something they could learn here. I kept thinking MS reputation was the issue since that's the clear error we get when some emails fail to charter.net.
Our emails going through smtp2go are dkim signed from both MS and smtp2go and making it into the inbox. I didn't test not signing messages from Microsoft.
I'm with you, I'm kind of over troubleshooting this problem when no one at Microsoft or Yahoo seems to care. It's unfortunate!
NLart I think most of us know and understand that MS is not to blame here, but that being said, this is an issue with deliverability between platforms, and the platforms should work together to get this resolved. It is in both parties best interests to do this. This is why I and others keep calling on MS to step in from a Product Level with the Exchange Team to deliver us timely updates on what is being done through platform intercooperation to solve the issue.
