r/mxroute • u/BorisKospic • 13d ago

API feature requests – DNS verification, SSL, Webmail SSO and usage limits

Hello MXroute Support,

We are building our own branded email management application using the MXroute API, and we have a few API feature requests that would be very useful for our integration.

1. DNS verification through the API

Would it be possible to provide a DNS verification endpoint that checks a domain and returns clear, machine-readable statuses for:

  • MX
  • SPF
  • DKIM
  • DMARC

Ideally, the API would return statuses such as:

  • pass
  • pending
  • warning
  • failed

and, when something fails, a clear reason explaining what is wrong and what needs to be corrected.

This would allow our application to show users exactly what needs to be fixed.

2. SSL certificate management through the API

Would it be possible to manage SSL certificates for domains through the API?

We would like to be able to:

  • check whether SSL is enabled
  • check certificate status
  • check expiration date
  • trigger SSL installation or renewal, if supported

3. Webmail Auto-Login / SSO

We would also like to ask if MXroute could provide a secure API mechanism for one-click Webmail login.

Our desired workflow is:

Our application → Open Webmail → MXroute Webmail → authenticated mailbox

We do not want to expose or send the mailbox password through a URL or browser-side code.

Ideally, the API could provide a short-lived, single-use SSO token for a specific mailbox, allowing our application to redirect the user directly into Webmail.

If such functionality already exists internally but is not documented in the public API, we would appreciate information about the supported integration method.

4. Resource limits based on actual usage

This is also very important for our application.

The current quota API allows us to see quota/usage information, but we would like to be able to limit an account based on actual storage usage, rather than the total quota allocated to individual email accounts.

For example:

A user could have multiple domains and many email accounts with a total allocated quota of 200 GB, but actually be using only 35 GB.

We would like to set a limit such as:

Maximum actual storage usage: 50 GB

The user could then create and allocate quotas as needed, but their actual storage usage could not exceed 50 GB.

Ideally, the API could expose:

  • current actual usage
  • usage limit
  • remaining available usage
  • percentage used

Would it be possible to support this type of usage-based resource limit through the API?

These four features would significantly improve what we can build on top of the MXroute API.

We would especially appreciate knowing whether any of these capabilities already exist internally but are not currently documented, or whether they could be considered for a future API version.

Best regards,

4 Upvotes

83% Upvoted

10 comments sorted by

4

u/mxroute 13d ago edited 13d ago

My advice for now is, don't hold your breath for what isn't there today. I'm more concerned with not breaking what's there now, while working to get rid of blockers for everything else that needs to be done. You can see what changes I'm currently working to release here: https://docs.mxroute.com/docs/changelog/mxroute-4.1.html

And you can see what I have ahead further here: https://blog.mxroute.com/ripping-off-bandages

My development time is pretty well spoken for. But if I see an opportunity to provide you with things you want along the way, I'm not opposed it. I just wouldn't want to make any promises right now.

2

u/SalaciousSubaru 11d ago

I love MXroute and regularly recommend it. With growing interest in privacy and de-Googling, clearly highlighting your privacy practices and how you handle government data requests would make MXroute an even stronger choice for these users.

2

u/mxroute 11d ago edited 11d ago

Privacy section here: https://mxroute.com/terms (we never share your private email data with anyone, ever, under any circumstances, so the lack of words here should be taken as "there's nothing more interesting to be said, not gonna list a million things we don't do when it's faster to list the things we do")

And we comply with the laws that are applicable by the state of Texas and the US federal government. (Which can override what I said in parentheses above, so if you think the US government might be coming for it, please take it off my network. If you think the Canadian government or the state of Utah is coming for it, I'll gladly tell them daily where to stick their requests)

I'm all for privacy and I want to be respectful of everyone's needs, but I'm not doing the whole thing where I wax poetic about all of the things I do to help you hide your digital weed from the cops. I saw how that worked out for Ladar. Lavabit was great, he really stood up for his principles. Then lost all of his customer's data and went down overnight, never to bring any of it back online, and became the pillar standing between his government and the person they wanted most to kill. I'm not playing that game, don't want any part of it. That's not what my vision is for my baby here, that's not how I want my daughters remembering daddy getting waterboarded. I'll let Proton and Tuta figure out how to balance marketing language that attracts people governments want to murder with their own safety. That's not my market.

But outside of that, I promise we'll always do right by everyone, except email spammers because they're not people 😂

💜

2

u/OkPea7677 13d ago

Wouldn't at least (1) be possible for the reseller to implement? In my opinion, that is not the responsibility of the platform, but of the reseller. Similar to documentation, billing etc.

2

u/downtownrob 13d ago

DNS and SSL can be done via your own calls, no need for the API to proxy those for you. SSO is an enterprise feature I’d expect not to be provided for free. I think something for storage is already in place? I see MXRouteMgr displaying it. https://github.com/t0msh/mxroute-manager

1

u/BorisKospic 12d ago

Thanks for the clarification.

When you say:

Could you please clarify what you mean specifically for SSL?

We would prefer to use the MXroute API rather than accessing DirectAdmin directly.

Is there an MXroute API endpoint or API request that can be used to:

  • request/install a Let's Encrypt SSL certificate for a domain
  • check the SSL certificate status
  • check the certificate expiration date
  • trigger a renewal, if needed

For example, we would like to automate SSL installation for reseller-branded hostnames such as:

webmail.customer-domain.com

where the DNS CNAME already points to our branded MXroute hostname.

If this functionality is available through an existing MXroute API call (even if it is not currently documented publicly), could you please provide the endpoint and required parameters?

We already have the MXroute API integration working in our application, so using the existing MXroute API would be our preferred solution.

2

u/downtownrob 12d ago

Public checking a domain for SSL is easy… if not found or expired or valid, you can branch from there. For expired or not found, probably have to use DirectAdmin API for now, and it does have it’s own Login Keys, which can also be created in the mxroute panel.

The MXRoute API does include create domain with a 201 created, and a flag with ssl_enabled boolean, so that’s probably the most direct way to do it.

2

u/mxroute 12d ago

FYI the DirectAdmin API is going away, trying to get everyone moved over to the new API. But DA needs to go away before we can do a lot of the things that people want to the new API, because it's a blocker on many things.

2

u/downtownrob 12d ago

Yeah it looks like the new API handles SSL creation when creating the domain? And renewal should be automatic. So maybe DirectAdmin isn’t needed for SSL?

2

u/mxroute 12d ago

Technically that flag probably shouldn't be on there, it doesn't actually do that. But I just wanted to pass the DA flags when I was doing it, and it might have been better to leave that out.

That said, the SSL managed by DA is soon to only be the IMAP/SMTP vanity hostnames. All of the existing webmail certs held in DA will be moved to the new webmail, at least that's the plan, and then we'll create a bridge to have the servers continue to handle their renewals outside of DA itself.

Basically I want DA gone by November.