Possibility to transport emails via API

One of my discoure install has particular majority of users using Microsoft outlook/hotmail email accounts and the microsoft spam rejection system does some weird filtering and puts almost every email sent via relay smtp (e.g. services like mailgun, elasticemail etc.) This had been creating a lot of trouble lately. I’ve spent days talking to mailgun support and after all the logs and tests, their final word was to try sending mails via their API instead of SMTP credentials.

I believe this may be an issue with the server’s originating IP. When sending via SMTP, the server that creates the message has its IP added as the “originating IP” into the headers. If the IP is not properly configured for SMTP, the recipient’s filters may flag the messages as Spam. I would recommend sending via our API instead. Messages sent through our API will use the sending IP assigned by Mailgun as the Originating IP, instead of the IP for your server.

as most reputable email services support API, can discourse support emails via their API instead of SMTP?

No, this is not possible. Also I fail to see how it would make any difference; email is email, if it is coming from the same service.

Mailgun support are talking out their rear end. They could just as easily strip this purported “originating IP” information from the headers when relaying via SMTP as via API, and nobody with two braincells to rub together trusts any information added by relaying systems, because (a) it’s all so trivial to forge, and (b) the WHOLE POINT of relaying through a service like mailgun is because the originating system isn’t properly configured for SMTP.


I also didn’t get their point but actually, using their API actually causes the mails to deliver as normal and otherwise the mails end up in spam of specifically one service provider i.e. microsoft.

I don’t really trust microsoft when it comes to reliable spam protection but when there is a majority of users using their service, I thought that maybe it’s worth investing upon some solution to figure this out.

also, the same happens even if the SMTP provider is changed. I’ve replicated this same behaviour with mailgun & elasticemail as senders. Hosting my own SMTP doesn’t seems like a Good idea either.

I’m still waiting for them to diagnose the mail headers and come up with some findings.