MailTaste: Finally Understanding Who's Sending Email as You

The first DMARC report I ever opened was a wall of XML that made me question my life choices. Angle brackets nested inside angle brackets, IP addresses I didn't recognize, authentication results that meant nothing to me. I closed the file and went back to ignoring the daily emails from Google and Microsoft with subject lines like "Report domain: esoup.net."

That was a mistake. Those reports were trying to tell me something important.

The Wake-Up Call

Months later, I finally forced myself to parse one properly. What I found was unsettling: dozens of IP addresses I'd never seen, sending email that claimed to be from my domain. Some were legitimate - services I'd forgotten I'd authorized. But others? No idea. Ghost senders, slipping through because my DMARC policy was set to none. I was asking mailbox providers to report on spoofing attempts but doing absolutely nothing about them.

The thing about DMARC is that it's not complicated in theory. You publish a DNS record. Mailbox providers check incoming email against your SPF and DKIM policies. They send you reports. You adjust. Eventually, you get confident enough to move from p=none (monitor only) to p=quarantine (suspicious mail goes to spam) to p=reject (fraudulent mail gets blocked entirely).

In practice? Those XML reports pile up. You never look at them. Your policy stays at none forever. The whole system works on paper but fails in the garage.

Building the Thing I Needed

So I built MailTaste - a DMARC report processor that actually makes this data usable.

The name fits the eSoup ecosystem. It's about tasting what's in the soup - understanding the ingredients of your email flow before you commit to a stricter policy. Because flipping to reject without knowing who's legitimately sending on your behalf is how you break your own email delivery.

Here's what MailTaste does: it receives the aggregate reports that Google, Microsoft, Yahoo, and other providers send daily. It parses the XML. It stores the data with encryption at rest. And it presents everything in a dashboard that answers the questions you actually have:

Who's sending email as my domain? A clear list of sources - IP addresses, hostnames where available, volumes over time.

Are they passing authentication? SPF results. DKIM results. Alignment checks. At a glance.

What's the trend? A timeline showing email volume, pass rates, and failures. You want to see that green line climbing before you tighten your policy.

Domain Verification the DNS Way

Because MailTaste handles sensitive data - email authentication reports reveal a lot about your infrastructure - it requires proof of domain ownership before it'll accept reports for that domain.

The verification happens through DNS, naturally. You add a TXT record to your domain's zone, MailTaste confirms it's there, and you're in. It's the same pattern used everywhere from Google Search Console to Let's Encrypt. DNS as the source of truth. If you control the zone, you control the domain.

This also enables per-organization isolation. Each verified domain operates in its own silo. Your data stays yours.

The Path to Reject

The real value isn't just seeing the data - it's building confidence.

When I first pointed my DMARC reports at MailTaste, I discovered three things:

A newsletter service I'd set up years ago was still sending on my behalf, properly authenticated. Good.
A calendar integration was sending meeting invites from my domain with broken DKIM. Needed fixing.
A handful of IPs in countries I've never operated in were attempting to spoof my domain. Failing authentication, but still trying.

The legitimate senders were easy to identify - recognizable hostnames, consistent patterns, passing authentication. The illegitimate ones were obvious too, once I could see them clearly.

After a few weeks of monitoring, I knew my legitimate email sources. I fixed the calendar integration. And then I did something I'd been putting off for years: I changed my DMARC policy from p=none to p=reject.

That felt good.

Mail servers around the world now actively block email that claims to be from my domain but fails authentication. Not quarantine. Not "maybe spam." Blocked. The DNS record says so, and they comply.

The Stack

MailTaste is built with Bun and TypeScript - the same foundation as other tools in the eSoup family. It runs on minimal infrastructure because it doesn't need much. Parse XML, store data, serve a dashboard. The complexity is in making the data legible, not in the data itself.

Reports come in via email to a dedicated mailbox. MailTaste polls, parses, and processes. The dashboard updates. You check in when you want to, not because you're drowning in XML attachments.

Privacy by Design

There are commercial DMARC monitoring services. Some are quite good. But they're businesses, which means your email infrastructure data becomes part of their business model - analytics, upsells, "insights" derived from aggregate customer data.

MailTaste is different. We encrypt your data at rest with per-organization keys. We don't mine it, we don't sell it, we don't build products on top of it. The service exists to show you your DMARC reports in a usable format. That's it.

It's still a hosted service - your data lives on our servers. But it's designed with the assumption that you'd rather we couldn't read it than that we promise not to.

Try It

mailtaste.esoup.net

If you've been ignoring your DMARC reports - and statistically, you probably have - this is your nudge to stop. Those XML files are trying to help you. They're just trapped in a format that actively resists being useful.

MailTaste sets them free.