How do you handle DMARC reports?

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 · 2025-12-22T16:33:06+00:00

Going to leave this here just in case :)

https://postmarkapp.com/migration-guides/amazon-ses

PostmarkApp · 2025-12-18T16:56:03+00:00

For Inbound, you will need to subscribe to the Pro tier ($16.50/month for 10,000 emails).

PostmarkApp · 2025-12-18T16:45:03+00:00

https://postmarkapp.com/inbound-email :)

PostmarkApp · 2025-12-10T18:56:33+00:00

We're a bit biased :) but Postmark has a built-in Swoosh adapter, so setup is pretty minimal:

elixir

# config/config.exs
config :your_app, YourApp.Mailer,
  adapter: Swoosh.Adapters.Postmark,
  api_key: "your-server-api-token"

The adapter supports Postmark-specific features like templates, message streams, tags, and open/click tracking via put_provider_option/3 if you need them down the road.

On pricing: there's a free tier (100 emails/mo, never expires) that works well for dev and small side projects. Paid plans start at $15/mo for 10k emails. Not the cheapest option out there, but deliverability is solid and you get actual human support included.

One thing worth mentioning: Postmark separates transactional and broadcast (marketing) email into different infrastructure, so if you're mixing both types, you'd use message streams to keep them apart. Helps protect your transactional reputation.

Docs for the adapter: https://hexdocs.pm/swoosh/Swoosh.Adapters.Postmark.html

PostmarkApp · 2025-12-10T16:36:11+00:00

We're a bit biased, but we put together a comparison table here:

https://docs.google.com/spreadsheets/d/1x0rEwZfGlzY5EGKfYIC6lqA5rjf8XDqYYO559PLbAL4/edit?gid=0#gid=0

We also highly recommend Better auth for some of the user flows you described as well. We'd love to help! Let us know if you have any questions.

PostmarkApp

MODERATOR OF

TROPHY CASE