Hello Bubble community 
,
I observe that all my users who are having emails ending with “@outlook.com” are not receiving any emails from “send email” action in workflow.
I can confirm that & I even check the “junk email” section too (which is like spam folder of gmail) but no email is received.
Is it a bug or Am i missing any thing ?
Any idea 
All of the Microsoft owned email addresses (@outlook.com @hotmail.com @live.com and @msn.com) are notoriously strict at filtering out emails and blocking sender IPs, especially those coming from large shared IP addresses from email providers like Sendgrid (or other large email API services)…
we’ve had issues over the years sending emails to those addresses, even from some of the largest and most well known email services and CRMs…
The only sure-fire way to get round the problem and maximise deliverability is to use your own IP address (or addresses) for sending your emails…
Alternatively, many people seem to have solved the issue using smaller email API service providers (like postmark or send-in blue) which tend to have less users on a single IP address, therefore the likelihood of sharing an IP with someone sending problematic emails is lower, so the IP address is less likely to get blocked by the Microsoft email accounts… They also seem to update and change their shared IPs (and remove blocked ones) more often than some of the larger companies, which might also explain the higher deliverability compared to services like Sendgrid…
@adamhholmes Thanks 
Can’t bubble dev team resolve this ?
It’s not really a Bubble issue… it’s an issue with the way Microsoft assesses and blocks emails it considers spam (or maybe it’s an issue with the way Sendgrid monitors and updates their shared IPs… but probably more just a consequence of the fact they’re one of the largest email API services)…
Bubble could change their native integration (to postmark for example), but that still doesn’t guarantee deliverability… if you’re using a shared IP for your emails (regardless of what provider you’re using) then you’re never fully in control of your deliverability (if someone else on the same IP starts sending spam emails, then ISPs will block the IP and your emails won’t get delivered, at least until your email service provider removes that IP from their pool).
But, from what I’ve read on this forum over the years, people seem to get much better deliverability with Postmark (probably because they’re a much smaller service provider), so changing the native integration from Sendgrid to Postmark (or something similar) might help a lot of users.
Personally, I always use dedicated IP addresses for our emails, so have never had any deliverability issues with Sendgrid.
@adamhholmes ok i got it now
Thanks a lot
@viquarahmed07 @adamhholmes
Thanks
You saved my time
I was facing same issue.
Thanks @adamhholmes 
@sam.morgan I believe this answer should also be documented in bubble docs (at-least brief summary)…
Today, My project manager while giving demo to one of our potential paid client he used “@live.com” email & he didn’t received “Account confirmation email.”
Which really gives a bad impression 
As a developer I agree, its my mistake to test thoroughly but i never had any clue it won’t work with other popular email provider beside gmail.
If this information already exists (I apologize but i didn’t find it).
What a bad scenario 
I agree with this 
Hi All -
We do have a small section at the end of our email documentation that makes reference to some of these concepts:
However, its clear from this thread that things can be a lot more clear. @mdburhan3 - I’m particularly sorry to hear about the issue you faced as part of a client demo, and I sympathize with your pain and frustration here!
I’ll be sharing this thread with our product team so that we can think about how we may want to be more explicit about email deliverability rates and expectations with SendGrid. Thank you all for the feedback here.
@sam.morgan Thanks
Yes shared IPs on Sendgrid are useless, I’d encourage Bubble to provide more flexibility when sending emails natively, as the current solution gives a bad impression of Bubble, when it’s actually Sendgrid’s problem.
