The more SaaS applications that self-host email the better. It forces the big guys, ie Microsoft, to improve their blocklists and not lazily block entire ranges. Yes its work contacting them occasionally, but it keeps the internet open. The alternative is an internet where they control it all.
Fair. Don't disagree with anything you're saying here.
I should probably tighten up that line. What I really meant to say is that the average self-hoster who just wants to enable a few services to send email doesn't want to run a mail server. Different audiences, different (and both correct) answers.
I set out to solve some pretty specific problems of my own but I'm genuinely curious how others have tackled these things. Posthorn and Postal don't compete in my head. Postal makes you into your own provider, which is something I personally deeply want to avoid. Posthorn assumes you've already picked a provider (which might be Postal, actually, it would work just fine pointed at a self-hosted Postal instance).
I really want to try this, but I'm afraid my DNS will be blacklisted if I do. Can someone guide me and others, if this is the case? E-Mail is the most complex of everything I know in sysadmin/DNS/Server stuff.
My current provider since almost two decades without any issues, except speed and storage limitations is all-inkl.com, but I really just use it for email and nothing else, therefore most likely overpriced at ~6€/month.
I would love to switch to some VPS/root or anything where I can SSH and install, compile my own services, but something where security is high and support is 24/7 available.
1) Posthorn doesn't host email - no inbox, no IMAP so it doesn't replace what it sounds like all-inkl is doing for you. All it does is take the outgoing messages from any of your hosted/local apps and take care of the plumbing of handing them off to a transactional provider (like Resend or Postmark). Those servers are the ones sending the mail, using their IPs and their sending reputation. Any blacklist concern is really tied to your sending domain and not a new risk from Posthorn. Just the same setup you'd do if you were calling something like Resend directly. If you're following their guidelines, you'll be fine.
2) On the VPS side, if your goal is to be able to ssh in, install some stuff and run your own services, something like Hetzner is a well regarded EU centric option with solid technical support baked in. Security is mostly on you and down to what you install and how you configure it. That can be a huge learning curve and a whole other kettle of fish, definitely not without risk.
Personally, I have used nullmailer in the past to provide a sendmail compatible local install that immediately forwards email to the SMTP server of my choice. Has worked flawlessly.
Obviously, that doesn't come with HTML form support, but then I am also not sure I would like the same binary to handle both a HTTP(S) endpoint and email submission :)
Nullmailer's a good call for a single-app use case. It's basically what I was doing.
Posthorn ended up the way it did because I had three different things all hitting Resend at the same time: a contact form, a couple of apps that only had SMTP email support and some scripts I wanted to email results from. I didn't want to have to maintain three different things doing functionally the same routing. Putting them in one binary helped me consolidate credentials and logs.
You're not wrong about the split though, I thought about breaking the two out. I'd originally written the http form handler as a caddy module (which I called caddy-formward to be cute) but ultimately I went the other way because the code after the ingress is the same regardless of how you come into the service and I didn't want to rewrite all that logic.
Have you encountered a similar issue with multiple apps where nullmailer hasn't been enough? Curious how you handled it if so.
Personal mail is the one case I think where hosting your own MTA still makes sense when you want to own the addresses and the data. You still have to solve for deliverability, which is something I hope to never have to do.
Posthorn is built for the opposite end of that, you've already decided you want to use a transactional provider for app mail and you just want to stop having to deal with wiring it into all of the things. Obviously for a big production app you build your own mail service, but for gluing together a bunch of different apps you're self hosting, I think this makes sense and addresses a real issue.
If you want an API piece to augment what you already have, Posthorn might still be useful regardless of how the rest of your mail is set up. A Posthorn JSON endpoint is just a POST with Bearer auth and an idempotency key. Example from my docs:
> […]You still have to solve for deliverability, which is something I hope to never have to do. […]
This is the exact case where I'd be really afraid of running it on my own and this I VERY STRONGLY BELIEVE should NOT be the case. Participating in email should be easy.
Correct, but not all apps can talk directly to an HTTPS API. Ghost, Gitea, Mastodon, NextCloud, Authentik, Matrix to name a few all only have built in SMTP support. Posthorn listens for that connection from those apps locally and translates it into whatever your transactional mail provider needs.
If all the apps you're running can already integrate via HTTPS API, Posthorn doesn't solve anything for you in that case, unless the unified credential, single retry policy and logging meaningfully simplifies things for you.
And honestly, SES was the easiest integration for me to write (even if it ended up being the most LOC), their documentation, examples and error responses gave me a really easy time setting it up. Additionally, because it does need such a verbose implementation SES ends up being a great case study for Posthorn and not needing to maintain the same 200 line signing routine in multiple different places.
> Nobody wants to run a mail server in 2026.
We do, and thats why we use Postal [1].
The more SaaS applications that self-host email the better. It forces the big guys, ie Microsoft, to improve their blocklists and not lazily block entire ranges. Yes its work contacting them occasionally, but it keeps the internet open. The alternative is an internet where they control it all.
1. https://docs.postalserver.io/
Fair. Don't disagree with anything you're saying here.
I should probably tighten up that line. What I really meant to say is that the average self-hoster who just wants to enable a few services to send email doesn't want to run a mail server. Different audiences, different (and both correct) answers.
I set out to solve some pretty specific problems of my own but I'm genuinely curious how others have tackled these things. Posthorn and Postal don't compete in my head. Postal makes you into your own provider, which is something I personally deeply want to avoid. Posthorn assumes you've already picked a provider (which might be Postal, actually, it would work just fine pointed at a self-hosted Postal instance).
I really want to try this, but I'm afraid my DNS will be blacklisted if I do. Can someone guide me and others, if this is the case? E-Mail is the most complex of everything I know in sysadmin/DNS/Server stuff.
My current provider since almost two decades without any issues, except speed and storage limitations is all-inkl.com, but I really just use it for email and nothing else, therefore most likely overpriced at ~6€/month.
I would love to switch to some VPS/root or anything where I can SSH and install, compile my own services, but something where security is high and support is 24/7 available.
Two things to unpack here:
1) Posthorn doesn't host email - no inbox, no IMAP so it doesn't replace what it sounds like all-inkl is doing for you. All it does is take the outgoing messages from any of your hosted/local apps and take care of the plumbing of handing them off to a transactional provider (like Resend or Postmark). Those servers are the ones sending the mail, using their IPs and their sending reputation. Any blacklist concern is really tied to your sending domain and not a new risk from Posthorn. Just the same setup you'd do if you were calling something like Resend directly. If you're following their guidelines, you'll be fine.
2) On the VPS side, if your goal is to be able to ssh in, install some stuff and run your own services, something like Hetzner is a well regarded EU centric option with solid technical support baked in. Security is mostly on you and down to what you install and how you configure it. That can be a huge learning curve and a whole other kettle of fish, definitely not without risk.
Nice project, nice initial subset of options.
At work I'm using Apprise (https://appriseit.com/) to deliver notifications.
Are you planning to add more services or to limit Posthorn to emails?
An interesting combination of features.
Personally, I have used nullmailer in the past to provide a sendmail compatible local install that immediately forwards email to the SMTP server of my choice. Has worked flawlessly.
Obviously, that doesn't come with HTML form support, but then I am also not sure I would like the same binary to handle both a HTTP(S) endpoint and email submission :)
Nullmailer's a good call for a single-app use case. It's basically what I was doing.
Posthorn ended up the way it did because I had three different things all hitting Resend at the same time: a contact form, a couple of apps that only had SMTP email support and some scripts I wanted to email results from. I didn't want to have to maintain three different things doing functionally the same routing. Putting them in one binary helped me consolidate credentials and logs.
You're not wrong about the split though, I thought about breaking the two out. I'd originally written the http form handler as a caddy module (which I called caddy-formward to be cute) but ultimately I went the other way because the code after the ingress is the same regardless of how you come into the service and I didn't want to rewrite all that logic.
Have you encountered a similar issue with multiple apps where nullmailer hasn't been enough? Curious how you handled it if so.
> Nobody wants to self host email server.
I do. Though I am self hosting it to have my personal email, being well... personal. Not for my company so maybe I am not the target.
Interesting project though. I always felt missing API to just send emails from some script in my mail server.
Personal mail is the one case I think where hosting your own MTA still makes sense when you want to own the addresses and the data. You still have to solve for deliverability, which is something I hope to never have to do.
Posthorn is built for the opposite end of that, you've already decided you want to use a transactional provider for app mail and you just want to stop having to deal with wiring it into all of the things. Obviously for a big production app you build your own mail service, but for gluing together a bunch of different apps you're self hosting, I think this makes sense and addresses a real issue.
If you want an API piece to augment what you already have, Posthorn might still be useful regardless of how the rest of your mail is set up. A Posthorn JSON endpoint is just a POST with Bearer auth and an idempotency key. Example from my docs:
curl -X POST https://posthorn.yourdomain.com/api/transactional \ -H "Authorization: Bearer $WORKER_KEY_PRIMARY" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: reset:user-123:$(date -u +%FT%H)" \ --data '{ "to_override": "bob@example.com", "subject_line": "Reset your password", "message": "Click here: https://app.example.com/reset/abc" }'
Could run alongside your existing mail server. It's a small enough overhead that the juice might be worth the squeeze.
> […]You still have to solve for deliverability, which is something I hope to never have to do. […]
This is the exact case where I'd be really afraid of running it on my own and this I VERY STRONGLY BELIEVE should NOT be the case. Participating in email should be easy.
Is Posthorn a reference to W.A.S.T.E.?
Not intentionally, but TIL that this turned into an apt reference. The pynchon connection is excellent.
My (intentional) reference was to the older mail courier horn.
Not OP but I read it as reference to just https://en.wikipedia.org/wiki/Post_horn
Don't services like SES already operate over 443/TLS and aren't blocked?
Correct, but not all apps can talk directly to an HTTPS API. Ghost, Gitea, Mastodon, NextCloud, Authentik, Matrix to name a few all only have built in SMTP support. Posthorn listens for that connection from those apps locally and translates it into whatever your transactional mail provider needs.
If all the apps you're running can already integrate via HTTPS API, Posthorn doesn't solve anything for you in that case, unless the unified credential, single retry policy and logging meaningfully simplifies things for you.
And honestly, SES was the easiest integration for me to write (even if it ended up being the most LOC), their documentation, examples and error responses gave me a really easy time setting it up. Additionally, because it does need such a verbose implementation SES ends up being a great case study for Posthorn and not needing to maintain the same 200 line signing routine in multiple different places.