Why Ticket Foundry ships with 4 email providers (and how to pick one)
Ticket Foundry can send email through six different methods:
- PHP's built-in
mail()function - SMTP via PHPMailer
- Mailgun (HTTP API)
- Postmark (HTTP API)
- SendGrid (HTTP API)
- Brevo (HTTP API, formerly Sendinblue)
This sounds like overkill. It's not. Here's why.
The problem we were solving
Email is the single most fragile part of any self-hosted web app. It's the part most likely to break on first install, and it's the part where the failure is silent — users just stop getting notifications and nobody notices for a week.
For Ticket Foundry, email matters more than for most apps. The product is a ticket system. Tickets generate emails. If email is broken, tickets pile up, requesters think they're being ignored, techs don't know they have new work. The whole system degrades.
So we built it to be robust. That means multiple paths to "the email actually went."
Why PHP mail() isn't enough
The default for any PHP app is mail(). It's built into the language, requires zero config, and works fine when... well, when it works.
Problems:
- No authentication. Mails go out as your server's default identity, which usually means they end up in spam.
- No bounce handling. If the address is bad, you find out by your user not getting the email.
- Often disabled. Many shared hosts disable
mail()entirely or rate-limit it aggressively. - No record. Did the email send? Did it bounce? Did it get opened?
mail()shrugs.
It's an OK fallback. It's not something you want to rely on if email is important.
Why we added SMTP
SMTP via PHPMailer is the next step up. You configure a real SMTP server (your Gmail, your O365, your DreamHost mail, whatever), and your app authenticates and sends through it.
This is fine for most installs. Real authentication, real delivery, error messages if something fails. Easy to set up if you already have email service.
But there's a problem with shared hosting: many hosts intercept and block outbound SMTP to prevent their customers from running spam farms.
DreamHost specifically does this. So do a lot of others. You connect to your SMTP server on port 587 and the connection mysteriously hangs or fails. The error is usually unhelpful. Hours of your life evaporate.
This is what made us add the HTTP API providers.
Why we added 4 HTTP API providers
HTTP-based email APIs (Mailgun, Postmark, SendGrid, Brevo) bypass SMTP entirely. You make an HTTPS POST to the provider, they handle delivery. The host can't block this without breaking the entire web.
We added four because no single one is right for everyone.
Picking one is mostly about your situation:
If you're sending under 100 emails/month and you want the nicest dashboard: Postmark. Free tier is generous and the activity log is best-in-class.
If you're sending hundreds to thousands a day and want the cheapest legitimate option: SendGrid. Slightly worse deliverability than Postmark but the price scales better.
If you're European or have EU customers and care about data residency: Brevo. They're a French company, GDPR is in their bones, servers in the EU.
If your team already uses Mailgun for something else: Mailgun. No reason to add a new provider.
In the future, we may add the ability to use custom API's. But these are the ones we tested so far.
What we don't support
Amazon SES. SES is dirt cheap (~$0.10/1k) and reliable, but the new-account approval process is painful (you start in "sandbox" mode and have to apply for production access). For a self-hosted product where the user is doing the setup, putting "wait 24 hours for AWS to approve your account" in the install path was a non-starter. SES gets a "supported via raw SMTP" workaround but no first-class integration.
Outlook/Microsoft Graph API. A lot of M365 shops want to send through their existing Microsoft tenant via Graph instead of SMTP. We considered it. The OAuth setup is complicated enough that we punted it to "post-1.0 if people want it." If you do, send an email to hello@ticketfoundry.net and we'll prioritize it.
Resend, Loops, Plunk, the new generation of email APIs. These are great products but didn't exist (or weren't mature) when we picked. We'll evaluate adding them later.
How config works in practice
Settings → Email tab. Pick your method from the dropdown. Fill in the credentials (SMTP server + auth, or just an API key). Click Send Test. If the test arrives, you're done.
API keys and SMTP passwords are encrypted at rest in the database using AES-256. The encryption key is generated during setup and stored in tf_config.php (outside the web-accessible directory). Anyone who breaches the database gets ciphertext, not your Postmark token.
tf_config.php, you also lose the ability to decrypt your stored credentials. Back this file up alongside your database. We'll write more about backup strategy in a future post.The takeaway
Most products that send email pick one provider and ship. We picked six because email is the part most likely to break for the user, and the cost of supporting multiple options was low compared to the cost of one user being unable to send email because their host blocks the provider we chose.
If you're building anything that sends notifications, do this. Your future customers will thank you.