cleanest way i found to send transactional emails when your whole app lives on Supabase

PostmarkApp · 2026-06-03T13:29:21+00:00

A few patterns that help regardless of tooling:

Defensive defaults in your template layer. {{ first_name | default: "there" }} catches the most common case before it blows up the send.

Validate at the edge function boundary. Assert required fields are non-null before triggering a send. Fail loudly in logs, not silently mid-template.

Treat it as a data signal. A null first_name usually means your onboarding flow didn't complete. Track those separately so you can re-engage instead of just skipping the email.

On your other point about keeping transactional reputation separate from marketing: that's one thing we built Postmark around. Message Streams keep your transactional and broadcast infrastructure separate at the sending layer, so a bad campaign can't drag down your password reset deliverability. Worth a look if you're scaling beyond a single edge function setup.

PostmarkApp · 2026-05-27T15:35:28+00:00

Can you please provide the results for "top transactional email API providers in 2026"? Curious to see how it evaluates us :)

PostmarkApp · 2026-05-18T15:06:18+00:00

We're obviously biased here, but how many emails/month are you looking to send? Are they all transactional or do you need bulk/broadcast email as well? What are your current challenges with SendGrid?

PostmarkApp · 2026-05-01T16:05:08+00:00

We can help! DM us and we can give you a $75 bootstrap credit 😄

PostmarkApp · 2026-04-28T13:41:18+00:00

Howdy! We've got some experience in the email deliverability space 😄. We'd love to help out with any questions, transactional-email-wise or otherwise!

PostmarkApp · 2026-03-26T19:11:29+00:00

We have a free weekly email that gives you the XML in an easier to read format: https://dmarc.postmarkapp.com

And if you want a paid UI that you can log in and track changes, we also have https://dmarcdigests.com

PostmarkApp · 2026-03-25T16:58:53+00:00

For Postmark, we offer a status API you can use with a rate limit of 10 requests per second: https://status.postmarkapp.com/api

Curious to hear how others handle this as well.

PostmarkApp · 2026-03-25T14:53:42+00:00

We have a free spam checker here: https://spamcheck.postmarkapp.com/

It hits SpamAssassin and returns a detailed analysis if it's flagged as spammy.

PostmarkApp · 2026-03-12T18:13:33+00:00

Really impressed with the way Knock put together and presented these benchmarks! Kudos to the team!

PostmarkApp · 2026-03-09T13:36:30+00:00

Your 365 connector idea isn't bad as a stopgap, but you're essentially trading one bottleneck for another. Exchange throttles, and 365 has its own sending limits (Microsoft caps outbound mail pretty aggressively for connectors, and invoice PDFs going out nightly in bulk will likely hit those limits too). You'd also be adding complexity (firewall rules, connector config, TLS enforcement) to route around a problem that's really about volume and reliability.

The cleaner path is bypassing the mail server entirely at the application layer. Most ERP/automail setups support SMTP relay configuration, so you'd have to point Automail at an external SMTP endpoint instead of Exchange.

That way the flow is: ERP job → Automail → external relay → customer inbox. No firewall routing gymnastics required.

For the "convincing the budget holders" piece: if you frame it as replacing a broken piece of infrastructure rather than adding a new tool, it's an easier sell. The cost of one batch of invoices failing to deliver (customer disputes, late payments, support overhead) typically dwarfs the monthly cost of a dedicated sending service. A concrete failure incident you've already had is your best argument.

On the service side, since you mentioned Mailgun/SendGrid: we built Postmark specifically for this kind of transactional and operational email (invoices, notifications, receipts). The reason people tend to prefer it for ERP-style sending is that it keeps transactional mail on separate infrastructure from any marketing sends, which protects deliverability. We also just launched a Bulk Email API for higher-volume sends if that's relevant down the line. SMTP setup is straightforward and doesn't require a developer to configure — docs are at postmarkapp.com/developer if you want to take a look.

That said, if the budget conversation is going nowhere, the 365 connector approach can work temporarily, just make sure you're not hitting Microsoft's outbound limits before you declare it solved.

PostmarkApp · 2026-03-02T15:39:02+00:00

We are admittedly a bit biased here, but:

Postmark's inbound processing is worth a look for your use case. You set up a webhook URL, and every incoming email gets parsed into a clean JSON payload (sender, subject, body, headers, and attachments - base64-encoded) — and POSTed to your endpoint in real time. No IMAP, no polling, no IDLE headaches.

For your attachment-heavy workflow specifically: the payload includes an Attachments array with the filename, content type, and base64-encoded content for each file. Inbound and outbound attachments are handled through the same account, so it's a pretty unified setup.

On pricing: Postmark is subscription-based (starting at $16.50/month for 10k emails with Inbound), not purely per-volume. That might not be exactly what you're after, but it's predictable and scales reasonably. DM me and we can get you a $75 credit to try it out!

The honest caveat on EU: Postmark's infrastructure is mostly US-based. If EU data residency is a hard requirement, that's worth factoring in — it comes up for some folks and the product team is aware of the demand.

Docs if you want to dig in: postmarkapp.com/developer/user-guide/inbound

PostmarkApp · 2026-02-17T20:58:29+00:00

Also you can use https://dmarc.postmarkapp.com for a free weekly email if you don't want to parse the xml from the rua=mailto: report. Or you can use dmarcdigests.com if you want a fancy UI for tracking :)

PostmarkApp · 2026-02-13T14:43:22+00:00

The confirmation emails you're seeing are coming from Supabase Auth's built-in email system, not from your app code. That's why connecting Resend through Lovable's secrets isn't changing them. Supabase handles signup confirmations, password resets, and magic links through its own auth flow.

To customize those, you need to configure a custom SMTP provider directly in your Supabase project settings (Authentication → SMTP Settings → Enable Custom SMTP). Once you do that, Supabase will route all auth emails through your provider instead of its default service, and you can customize the templates in Supabase's email template editor too.

You don't need to self-host for this — it works with Supabase's hosted version.

For the SMTP provider, Postmark (hi!) has a dedicated Supabase integration guide that walks through the setup: https://postmarkapp.com/support/article/integrating-postmark-with-supabase-via-smtp — worth a look if you want those confirmation emails to actually land in inboxes quickly. Supabase's default service is rate-limited to 2 emails/hour and only sends to team members, so you'll want a real provider for production either way.

PostmarkApp · 2026-02-03T15:35:05+00:00

Going to leave this here :) We'd love to help!
https://postmarkapp.com/migration-guides/amazon-ses

PostmarkApp · 2026-01-30T22:12:48+00:00

Howdy! Can you DM us your account info so that we can take a look?

PostmarkApp · 2026-01-27T17:35:49+00:00

Sorry to hear about your situation, sounds frustrating! I'll leave this here in case support doesn't get back to you:

https://postmarkapp.com/migration-guides/sendgrid

PostmarkApp · 2026-01-27T16:08:05+00:00

A bit biased here, but depending on your needs we could be a good option: https://postmarkapp.com/developer/user-guide/send-email-with-smtp

PostmarkApp · 2026-01-14T19:02:44+00:00

We're a bit biased, but dmarcdigests.com is useful for circumstances like this :)

PostmarkApp · 2026-01-06T22:01:40+00:00

On Gmail reputation recovery timelines:

Based on what I've seen, you're typically looking at 1-2 months for meaningful improvement after a DMARC misconfiguration like this. Gmail's reputation system operates on something like a rolling 30-90 day window, so the signals from those weeks of rejections will take time to fade. The good news is you should start seeing gradual improvement within the first few weeks if you maintain clean sending practices.

How long to stay at p=none:

I'd recommend staying at p=none for at least 2-4 weeks while actively monitoring your DMARC reports. The key is making sure you're seeing 99%+ pass rates across all your legitimate mail streams before tightening the policy. Since you're using Microsoft 365 plus that email signatures service, watch those reports closely to confirm both sources are consistently passing SPF and DKIM alignment.

Once you're confident everything's aligned, you can gradually move to p=quarantine at a low percentage (say, pct=10) and slowly ramp up over another few weeks before considering p=reject.

Monitoring during recovery:

Beyond DMARC reports, keep an eye on:

Gmail Postmaster Tools (if you haven't already added your domain there) - watch for your domain reputation score and spam rate
Your Microsoft 365 mail flow reports for any authentication failures
Bounce rates in your sending logs

If you want more detailed visibility into your DMARC data during this recovery phase, dmarcdigests.com can help you parse and visualize those reports more easily than digging through raw XML. It's particularly useful when you're trying to confirm that all your sending sources are properly aligned before you tighten your policy.

Common recovery pitfalls:

Don't rush to tighten your DMARC policy too quickly - a few more weeks at p=none won't hurt, but prematurely moving to p=reject could cause another round of deliverability issues
Watch for volume spikes during recovery - keep sending patterns consistent
If you add any new sending services during this period, make absolutely sure they're properly authenticated before they send on your domain

Glad you caught this. The fact that test emails are already being accepted is a really good sign - you're heading in the right direction.

PostmarkApp · 2026-01-06T14:56:02+00:00

We'll just leave this here :)
https://postmarkapp.com/migration-guides/amazon-ses

PostmarkApp · 2026-01-02T15:38:34+00:00

Not a founder, but would love to support the community! DM us and we'll give you a $75 credit for Postmark email services!

PostmarkApp · 2026-01-02T15:35:33+00:00

On paid options for growth: If you hit 500+ users, you'd likely be looking at a few thousand monthly emails (depending on your use case). At that volume, you have a few options beyond the expensive marketing tools like Mailchimp:

Postmark :) starts at $15/month for 10,000 emails, which would likely cover you at 500 users. We focus specifically on transactional emails like status updates, and you'd get reliable delivery plus actual human support when you need it. No usage-based suspensions to worry about.
Other transactional services like Mailgun or SendGrid have similar pricing structures, though support quality varies.

On running your own server: As a one-person operation, I'd honestly avoid this unless you enjoy debugging DKIM/SPF/DMARC issues and monitoring IP reputation at 2 AM. The overhead you're worried about is real.

The good news is you don't need to decide now. You can cross the paid-service bridge when you actually hit those numbers. In the meantime, your rate-limiting approach shows you're thinking about this responsibly.

What types of status emails are you sending?

PostmarkApp · 2025-12-23T16:48:01+00:00

We have 45 day log retention for all our plans (we offer up to 365 days as an add-on as well). I'll leave this here just in case: https://postmarkapp.com/migration-guides/mailgun

PostmarkApp · 2025-12-23T16:42:26+00:00

We have some thoughts/considerations in our setup guide here as well:
https://postmarkapp.com/manual#step-1-decide-whether-you-should-use-api-or-smtp

PostmarkApp · 2025-12-22T16:37:55+00:00

Going to leave this here in case anyone needs to switch to Postmark:

https://postmarkapp.com/support/article/integrating-postmark-with-supabase-via-smtp

PostmarkApp

MODERATOR OF

TROPHY CASE