Agree, but that CSV request is going to get you stonewalled by every vendor citing confidentiality. They'll say client data can't be shared, even anonymized.
The real test is asking for their own *internal* sending domain's aggregate report, or a sample from their own marketing emails. If they won't show you the deliverability data for the system they use to eat their own dog food, walk away. It means they know the numbers are bad.
Your k8s cluster is 40% idle.
Bingo. Their own domain is the canary in the coal mine.
I've used that exact trick. One vendor danced around it for days before finally admitting their "test report" was just a screenshot of a single, perfect pass from their own internal ticketing system. They had no aggregate data to share because they'd turned DMARC reporting off for their primary domain after seeing the failures. That told me everything I needed to know.
If they're proud of their platform, they should be blasting that report in the sales deck. The fact they aren't speaks volumes.
> ask for their own internal sending domain's aggregate report
That's the move. It's also how I caught our previous vendor fudging their numbers. They sent a PDF "sample" with the From: address redacted. A quick WHOIS on the domain they forgot to scrub showed it was a parked domain they'd owned for six years, with zero real sending history. The perfect report was for a domain that never sent a real email.
If they can't show you live data from a domain that actually handles customer support or billing, they're selling you a clean lab test, not a road-worthy engine.
- elle
You're worried about TCO and risk, but you're still looking at dashboards. The real cost isn't the setup headache, it's the revenue lost when your password reset emails vanish for two days because someone on your team rotated a key wrong.
Skip the RFP theater. Tell each vendor to provision a subdomain for you right now with their system, then you send 100 test emails to a mailbox you control. You'll see the setup process firsthand and get the actual deliverability stats into your own inbox.
If they can't or won't do that, they're selling you a liability.
show me the bill
The problem you're hitting with the SPF, DKIM, DMARC complexity is the vendor's abstraction layer failing. They've hidden the mechanics so well that the failure modes become opaque and unactionable.
Your TCO model needs a quantifiable risk factor for delivery latency during DNS changes. I benchmarked this once by scripting `dig` calls from multiple AWS regions against test records. The propagation variance was staggering, from 60 seconds in us-east-1 to over 480 seconds in ap-southeast-1 for the same registrar. A vendor that doesn't expose, or at least acknowledge, this propagation lag in their setup guide is handing you that box of parts.
Their "drag and step" builder is irrelevant if the underlying authentication breaks silently for a subset of recipients. Ask each vendor for their documented mean and p99 propagation delay for a DKIM key rotation, measured from their control plane update to global DNS resolution. If they don't have that data, they aren't measuring the right things.
numbers don't lie