Josh CTO of Mailgun here - In this example, there is no actual sharing of domain reputation with other customers. Most inbox providers base reputation on the DKIM domain, which in this case is "sandbox.mgsend.net" not the header from address.
Each message is uniquely signed by the sending domain belonging to the account owner, meaning that the domain reputation cannot be borrowed/shared between customers.
Josh/CTO of Mailgun here - I took a look at this case and these messages were being sent from the sandbox feature of our service. The sandbox only allows messages to be sent to "authorized recipients" through an opt-in mechanism, which makes it impractical for spamming and phishing. The purpose of this feature is to allow customers to get comfortable with the interfaces and test the product in a safe way without having to add DKIM/SPF records. I reviewed these messages and confirmed there is no illicit behavior, likely just a misconfiguration from a user of radiotoolbox.
If this is a recent occurrence, I'd be happy to have our application security team take a look. To be clear, there hasn't been any kind of breach, but our customers are often targeted in phishing schemes that results in the disclosure of account credentials. We're continually adapting our defenses, but this is responsible for the majority of credential leaks.
Thoma Bravo has been a great partner for us. Our management team has maintained a high level of autonomy in driving the vision and strategy of the company including the decision to pursue this acquisition. There is a tremendous network current/past companies with a wealth of experience that we've been able to draw from that already has proven to be incredibly valuable as we continue to scale the company.
We're really excited about MJML. Creating messages that render properly on all email clients is challenging and MJML solves the problem in a very developer friendly way. You should expect MJML and the Passport editor to be integrated into Mailgun in the near future!
Can you email your ticket number to [email protected] and I'll take a look? This definitely isn't typical and I'll get this resolved immediately for you.
It depends. Most hosting providers will either discourage you or prevent you from relaying messages from your servers, so that is something you need to check for. Also, you'll want to make sure that your dedicated IP is persistent and won't be lost across reboots. Once you establish a good sending reputation, that's valuable in making sure your messages reach the Inbox.
In the case of Mailgun, you should be assigned an IP with a neutral reputation. For example, before dedicated IPs are reassigned we leave them dormant for at least a month, usually much longer, before assigning to a new customer.
IP reputation continues to be the most important factor that impacts deliverability. Providers are slowly moving to domain-based reputation systems that leverage DKIM. Gmail seems to weight domain reputation in their calculations higher than most currently.
This is an area that we're actively working to improve. The system is designed so that customers who are sending high quality messages get moved into better IP addresses. We look at metrics like complaint, bounce, and engagement rates to help make these decisions. This works much of the time, but is imperfect, especially when you start using Mailgun for the first time. We're developing and iteratively rolling out several machine learning classification systems that look at various features when you signup for Mailgun and place your account into better IP pools based on our internal risk calculation.
If you are seeing continuous problems, I'd love to take a look! My email address is on my profile.
We are working on SSL support now. While this has drawbacks, you can terminate on a service like Cloudflare and we can enable HTTPS link writing for your sending domain. Otherwise, hangtight for a more integrated solution.
2fa is on its way. Encoding is a real pain. We went ahead and put more details about quoted printable encoding and updated our docs with some examples on how to handle this properly.
This is (and probably always will be) a work in progress for us. Our systems promote you into higher quality IP ranges as you send better e-mail. The downside is that this is a reactive process. We have some experiments that we're starting to run to help improve onboarding and IP assignment for legitimate users. In the meantime, support is always happy to review your account and expedite this process for you.
I'm not sure why there was a disconnect with our sales team, but I'm happy to help. Could you e-mail me with more details? josh [at] mailgun [dot] com
The model clause process is not trivial and often requires work between the legal teams from Mailgun and the respective EU company. We've gone through the process and can definitely help any of our existing or prospective customers get through it, though. Every business is a little different, so we'd need to talk through the specifics.
On issue #1, we're going to update the language around this in our control panel and put together better documentation. In reality, having MX records are important to allow for sender address verification [1], which many SMTP servers require.
On issue #2, Thanks and apologies for the slow response, This ticket slipped under our radar.
To give you a quick answer: we'll look into the approach you described in your blog post as well as RFC 6376. It seems legit but we'll need to do some more testing to ensure that deliverability does not suffer due to changing how we sign messages. If deliverability does suffer, we can always make this something that is an optional security setting that can be toggled, like how you can enable and disable TLS certificate validation now.
Our security engineer will take a look and reach out to you with more details in the ticket.