Your emails go to spam. mailX shows you why, and how to fix it in seconds with clear answers and exact steps. Built for humans and AI agents. API and MCP ready.
In the future, will the tool be able to create such an email and settings on its own so it will not end up in the spam? Like the whole automation of the process instead of suggestions.
That's the question we keep asking ourselves. Today, we surface what's broken and guide the fix, full automation is the logical next step. Which part of the setup would you most want automated first?
@busmark_w_nika No. Our focus is not to create the email itself and send it.
Many tools already help with copy, personalization, and sequences.
Our focus is the part after that: making sure the email has the best chance to land in the inbox.
So mailX diagnoses what is wrong, through the web app or through AI agents via API & MCP.
The future for us is more about helping agents check, fix, and monitor deliverability safely, not replacing the creative part.
Report
@busmark_w_nika@thamibenjelloun That would be a huge relief. Right now, when my company email doesnt show up, i have to check 3 places, thunderbolt imap settings. spam/junk folders, google workspace settings.
@srinivas_narra Exactly 😅 And half the frustration is not even knowing where the problem actually is.
Sometimes it’s an IMAP/client issue, sometimes Google Workspace, sometimes authentication, sometimes spam filtering… and you end up debugging across 4 different dashboards just to understand why an email disappeared.
@thamibenjelloun aaa, okay, I thought that in most cases the cause of landing in the spam is the fact that the email contained some spam-triggering words. But there are more reasons for that.
@thamibenjelloun@busmark_w_nika Learning of the day: Email is an old technology built with 0 safety! When you tell a server to send an email, you literally give him the From and To. So you can send an email from any domain even if I don't own it!!! This ugly protocols: SPF, DMARC, DKIM have been created after to solve this, it's like an ID that allow to say I own the domain. If you don't have it, you are trying to enter to a party without having your ID. In this case the recipient provider decide if he reject, accept or put in spam.
Then there is your Domain reputation + Content analysis :)
@busmark_w_nika MailX itself no, but that's the magic of MCP and AI agent. You can Ask Claude to use MailX for the recommendations and set your actuals tools ♕
I'm Amine, co-founder of mailX. Huge thanks to @garrytan for hunting us today 🙏
After 6 years in email deliverability and building Mailwarm (YC S20), I keep seeing teams spend weeks rewriting subject lines, A/B testing send times, and buying warmup tools while they have a 5-minute problem they don't know is a problem. Missing DMARC. Broken SPF. A DKIM key that was never rotated. Boring stuff with scary names, ignored while everyone optimizes copy.
These protocols exist for a reason: they're your domain's ID card. They're how Gmail and Microsoft decide whether to trust you.
We built mailX to fix that. Ask the AI agent and it'll diagnose your setup and walk you through every step. Prefer to do it yourself? There's a human interface for that too. And every report is shareable, so you can hand it straight to an expert if you want a second pair of eyes.
mailX is really the result of different strengths coming together: deep deliverability experience, product thinking, engineering, AI workflows, customer support, and a lot of real problems we saw through Mailwarm over the years.
That’s what makes this launch special for me.
Not just a tool, but years of learning turned into something simple for humans and AI agents.
@andrzej_zarod good question. If you only send a small number of important emails like investor outreach, sales conversations, partnerships, support replies, etc missing the inbox hits harder. Higher volume makes the patterns more visible, but the underlying problems affect everyone.
@andrzej_zarod Low-volume are definitely benefiting setting DNS properly should be done by everyone. It's the highest results for the lowest effort/cost (Free)
@andrzej_zarod Absolutely! While high-volume senders get their Google Postmaster and Yahoo Sender Hub dashboards to populate faster, correcting your DNS protocols at a lower volume is highly strategic. It accelerates your long-term reputation growth. Establishing a healthy sender score from day one is far easier than trying to repair a damaged reputation at high volume, even if the tracking data takes a bit longer to catch up initially.
@andrzej_zarod Honestly, its for both but in different ways.
At higher volume, deliverability problems become expensive very quickly. But for low-volume founders, even a few important emails landing in spam can hurt sales, partnerships, or fundraising, so having the basics configured properly still matters a lot.
I do really like the idea of giving AI agents a deliverability expert, because otherwise they might just send blindly. Something I'm curious about is how an agent would actually use mailX in practice?
@theokitsberg Really good question. Maybe agents will eventually need deliverability-awareness built into their workflows, because otherwise they’ll just optimize for volume and unintentionally damage sender reputation over time. The goal with mailX is helping agents monitor domain health, detect issues early, and adapt instead of sending blindly.But yeah I appreciate your question :))
@theokitsberg Good question. In practice the agent calls the MailX MCP before it sends, basically as a pre-flight check. It pulls SPF, DKIM, DMARC, blacklist status, MX for the sending domain, and gets back a verdict it can act on: send, hold, or fix first.
If something's broken (say DMARC is set to none), the agent can call the SPF/DMARC generator tool to produce the corrected record, hand it back to the user, then re-check on the next run.
The shift is from blind 'spray and pray' to an agent that knows before it sends whether the email has a chance of landing.
@theokitsberg In practice, mailX becomes the diagnostic layer the agent calls before sending or scaling. The agent can check the domain setup, authentication, blacklists, and risks, then decide: “safe to send” or “fix this first.” Today it’s diagnostic. The next step is remediation with human approval.
@theokitsberg If your agent have access to your outreach and DNS, he can actually use mailX to double check everything, switch between domains is one of them is unhealthy. Stop if there is a problem, and tell you if someone is trying to send emails on your behalf using DMARC.
Report
Congrats on the 🚀
The line about an agent landing in spam being worse than not sending really stuck with me. Same thing is starting to happen with AI search. When ChatGPT or Perplexity recommends a competitor instead of you, most brands have no idea it even happened. The agent acted, the user trusted it, the brand never saw it. Feels like the same invisible plumbing problem, one layer up.
Are you seeing teams ask for this kind of visibility into what their agents are actually doing?
@francesco2689 This is an interesting parallel. We’re starting to see more conversations around visibility, trust, and observability for agent actions especially as agents become more autonomous. Once agents are acting on behalf of users, people want to understand the what and the why and whether the outcome was actually successful.
Same failure mode you described: the agent acted, the user trusted, the brand never saw. Visible to one side, invisible to the other.
Yes, teams ask for it, but framed as inbox placement so far. The agent-recommendation version isn't on most radars yet. It will be the moment founders realize their AI citation rate can drop silently the same way inbox placement always did.
@francesco2689 Yeah, this is exactly the direction things are heading.
There’s a growing gap between “what the system did” and “what the brand knows happened.” With email it’s spam filters and deliverability black boxes. With AI agents, it’s recommendations, tool calls, and decisions happening with zero audit trail for the brand. We’re starting to see teams ask for that visibility, not just logs, but explanations of outcomes: why something was recommended, what alternatives were considered, and when a competitor gets surfaced instead.
@francesco2689 The real issue is visibility. If agents start making growth decisions, sending emails, choosing sources, recommending vendors, we need to understand the signals behind those decisions. Otherwise companies will lose pipeline without even knowing where it leaked.
@francesco2689 Exactly. The real problem is visibility. If agents start sending, recommending, ranking, or choosing vendors, teams need to understand the signals behind those decisions.
Otherwise you lose pipeline silently, whether it’s email deliverability or AI search visibility.
That’s why we think diagnostics will become a core layer for AI workflows.
Report
I don’t fully understand what the difference is compared to Mail-tester? It shows the same thing and gives recommendations, for free. It also gives a score from 1 to 10, just like in the video presentation.
And separately, does it show deliverability for Google and Microsoft separately?
@natalia_iankovych Honestly the is to many things to handle with deliverability. Checkers
SPF
DKIM
DMARC
BIMI
SMTP Checker
IMAP Checker
Blacklist Checker
Generators
DMARC Generator
SPF Generator
BIMI Host
Finders
SMTP Finder
IMAP Finder
DNS
MX Lookup
TXT Lookup
CNAME Lookup
PTR Lookup
DNS Lookup
Here is what we can check right now if you want to compare with anything else, and the main difference is instead of understanding this keywords made for machines, we made it accessible fe AI agent check them via MCP.
@natalia_iankovych Fair question tools like Mail Tester are great for quick checks and basic validation.
With mailX, the goal is less about just giving a score, and more about helping users actually understand what’s wrong, why it matters, and how to fix it especially over time and across different workflows.
And yes, Google and Microsoft can behave very differently deliverability-wise, so provider-specific visibility is definitely something we care about.
@natalia_iankovych Mail-tester is useful. The difference we’re building toward with mailX is broader: not only a one-time score, but a full diagnostic layer for web, API, and AI agents through MCP. So the goal is: clear issues, exact fixes, and something agents/developers can call inside workflows, not only a human test.
On Google vs Microsoft: today we mainly diagnose the setup and risks through mailX. Provider-specific inbox placement is part of where we’re going, because Gmail and Microsoft don’t behave the same at all.
But on mailwarmwe do provide a SPAM Score per email provider. @manal_essalek1 will be happy to help you on that.
Mail-tester is mainly centered around testing a specific email by sending it to their inbox and getting a spam/content/authentication score back.
mailX is more focused on domain-level infrastructure audits and agent workflows through MCP, so the experience is closer to automated deliverability auditing than manual email testing.
On the Google/Microsoft question: right now we expose the underlying DNS/authentication checks directly rather than separate provider-specific inbox placement reporting.
The MCP angle is what makes this interesting to me. I've been building with Claude agents and "agent sends email" workflows always have the same silent failure mode: it lands in spam, the agent reports success, and the user only finds out a week later when no one replied. Diagnosing deliverability before the send (and exposing it as a tool the agent can actually call) is the right shape.
Curious, does the MCP server return structured remediation steps the agent can execute, or is it diagnostic-only for now?
@itsmasa This is exactly the failure mode we’ve been thinking about. The agent reports emails were sent successfully, but from a deliverability perspective the operation may have completely failed.
And yes the direction is definitely toward structured remediation, not just diagnostics. We want agents to understand what's the issue and why it happened and what do next to fix it.
That’s where the MCP side becomes really interesting for us.
@itsmasa That silent failure is the problem: the agent says “sent”, but nobody knows if the email had a real chance to land. For now, MCP is mainly diagnostic.
Next step is structured remediation: actions an agent can suggest, prepare, and execute with human approval.
We don’t want agents changing DNS blindly. But they should know when to say: “don’t send yet, fix this first.”
minimalist phone: reduce your screentime
In the future, will the tool be able to create such an email and settings on its own so it will not end up in the spam? Like the whole automation of the process instead of suggestions.
mailX by mailwarm
@busmark_w_nika Definitely something to keep in mind for our Roadmap 😉
mailX by mailwarm
Hi @busmark_w_nika, thank you for raising this!
That's the question we keep asking ourselves. Today, we surface what's broken and guide the fix, full automation is the logical next step. Which part of the setup would you most want automated first?
Mailwarm
@busmark_w_nika No. Our focus is not to create the email itself and send it.
Many tools already help with copy, personalization, and sequences.
Our focus is the part after that: making sure the email has the best chance to land in the inbox.
So mailX diagnoses what is wrong, through the web app or through AI agents via API & MCP.
The future for us is more about helping agents check, fix, and monitor deliverability safely, not replacing the creative part.
@busmark_w_nika @thamibenjelloun That would be a huge relief. Right now, when my company email doesnt show up, i have to check 3 places, thunderbolt imap settings. spam/junk folders, google workspace settings.
mailX by mailwarm
@srinivas_narra Exactly 😅 And half the frustration is not even knowing where the problem actually is.
Sometimes it’s an IMAP/client issue, sometimes Google Workspace, sometimes authentication, sometimes spam filtering… and you end up debugging across 4 different dashboards just to understand why an email disappeared.
minimalist phone: reduce your screentime
@thamibenjelloun aaa, okay, I thought that in most cases the cause of landing in the spam is the fact that the email contained some spam-triggering words. But there are more reasons for that.
mailX by mailwarm
@thamibenjelloun @busmark_w_nika Learning of the day: Email is an old technology built with 0 safety! When you tell a server to send an email, you literally give him the From and To.
So you can send an email from any domain even if I don't own it!!!
This ugly protocols: SPF, DMARC, DKIM have been created after to solve this, it's like an ID that allow to say I own the domain. If you don't have it, you are trying to enter to a party without having your ID.
In this case the recipient provider decide if he reject, accept or put in spam.
Then there is your Domain reputation + Content analysis :)
mailX by mailwarm
@busmark_w_nika MailX itself no, but that's the magic of MCP and AI agent. You can Ask Claude to use MailX for the recommendations and set your actuals tools
♕
mailX by mailwarm
Hey Product Hunt 👋
I'm Amine, co-founder of mailX. Huge thanks to @garrytan for hunting us today 🙏
After 6 years in email deliverability and building Mailwarm (YC S20), I keep seeing teams spend weeks rewriting subject lines, A/B testing send times, and buying warmup tools while they have a 5-minute problem they don't know is a problem. Missing DMARC. Broken SPF. A DKIM key that was never rotated. Boring stuff with scary names, ignored while everyone optimizes copy.
These protocols exist for a reason: they're your domain's ID card. They're how Gmail and Microsoft decide whether to trust you.
We built mailX to fix that. Ask the AI agent and it'll diagnose your setup and walk you through every step. Prefer to do it yourself? There's a human interface for that too. And every report is shareable, so you can hand it straight to an expert if you want a second pair of eyes.
The whole team is here today to answer your hardest deliverability questions 👇
Proud to work with all of you @thamibenjelloun @othman_katim @karimbenkeroum @manal_essalek1 @naimz @daniel_nwankwo
mailX by mailwarm
Mailwarm
@garrytan @othman_katim @karimbenkeroum @manal_essalek1 @naimz @daniel_nwankwo @bengeekly and all the others. Proud of this team.
mailX is really the result of different strengths coming together: deep deliverability experience, product thinking, engineering, AI workflows, customer support, and a lot of real problems we saw through Mailwarm over the years.
That’s what makes this launch special for me.
Not just a tool, but years of learning turned into something simple for humans and AI agents.
Let’s go team 🚀
mailX by mailwarm
@garrytan @othman_katim @karimbenkeroum @manal_essalek1 @daniel_nwankwo @bengeekly @thamibenjelloun Amen to that. You can feel the years of operational knowledge and customer pain points turned into something much more accessible, It’s not “AI for the sake of AI”
Big congrats to the team 👏 🤘🏻
mailX by mailwarm
@bengeekly heavy on the "boring stuff with scary names" lol. It's been lovely working with you and everyone too. To the launch and beyond 🚀
mailX by mailwarm
@garrytan @thamibenjelloun @othman_katim @karimbenkeroum @naimz @daniel_nwankwo @bengeekly Go us 🥳🤩
mailX by mailwarm
The CTO vision was key here to ship it, Proud of you @bengeekly !
mailX by mailwarm
@othman_katim Thanks
Is mailX useful for low-volume founders, or does the value become clearer at higher volume?
mailX by mailwarm
@andrzej_zarod good question. If you only send a small number of important emails like investor outreach, sales conversations, partnerships, support replies, etc missing the inbox hits harder. Higher volume makes the patterns more visible, but the underlying problems affect everyone.
mailX by mailwarm
@andrzej_zarod Low-volume are definitely benefiting setting DNS properly should be done by everyone. It's the highest results for the lowest effort/cost (Free)
Mailwarm
@andrzej_zarod Yes, useful even at low volume. Actually, it’s better to catch deliverability issues before scaling.
At high volume, the pain is bigger. At low volume, mailX helps you avoid damaging the domain early. It the first step before starting email warmup.
mailX by mailwarm
@andrzej_zarod Absolutely! While high-volume senders get their Google Postmaster and Yahoo Sender Hub dashboards to populate faster, correcting your DNS protocols at a lower volume is highly strategic. It accelerates your long-term reputation growth. Establishing a healthy sender score from day one is far easier than trying to repair a damaged reputation at high volume, even if the tracking data takes a bit longer to catch up initially.
mailX by mailwarm
@andrzej_zarod Honestly, its for both but in different ways.
At higher volume, deliverability problems become expensive very quickly. But for low-volume founders, even a few important emails landing in spam can hurt sales, partnerships, or fundraising, so having the basics configured properly still matters a lot.
Prism
I do really like the idea of giving AI agents a deliverability expert, because otherwise they might just send blindly. Something I'm curious about is how an agent would actually use mailX in practice?
mailX by mailwarm
@theokitsberg Really good question. Maybe agents will eventually need deliverability-awareness built into their workflows, because otherwise they’ll just optimize for volume and unintentionally damage sender reputation over time. The goal with mailX is helping agents monitor domain health, detect issues early, and adapt instead of sending blindly.But yeah I appreciate your question :))
mailX by mailwarm
@theokitsberg Good question. In practice the agent calls the MailX MCP before it sends, basically as a pre-flight check. It pulls SPF, DKIM, DMARC, blacklist status, MX for the sending domain, and gets back a verdict it can act on: send, hold, or fix first.
If something's broken (say DMARC is set to none), the agent can call the SPF/DMARC generator tool to produce the corrected record, hand it back to the user, then re-check on the next run.
The shift is from blind 'spray and pray' to an agent that knows before it sends whether the email has a chance of landing.
Mailwarm
@theokitsberg In practice, mailX is the diagnostic layer the agent calls before sending or scaling.
It can check the setup, spot risks, and tell the agent: “safe to continue” or “fix this first.”
That’s the direction we believe AI outbound needs.
Mailwarm
@theokitsberg In practice, mailX becomes the diagnostic layer the agent calls before sending or scaling. The agent can check the domain setup, authentication, blacklists, and risks, then decide: “safe to send” or “fix this first.” Today it’s diagnostic. The next step is remediation with human approval.
mailX by mailwarm
@theokitsberg If your agent have access to your outreach and DNS, he can actually use mailX to double check everything, switch between domains is one of them is unhealthy. Stop if there is a problem, and tell you if someone is trying to send emails on your behalf using DMARC.
Congrats on the 🚀
The line about an agent landing in spam being worse than not sending really stuck with me. Same thing is starting to happen with AI search. When ChatGPT or Perplexity recommends a competitor instead of you, most brands have no idea it even happened. The agent acted, the user trusted it, the brand never saw it. Feels like the same invisible plumbing problem, one layer up.
Are you seeing teams ask for this kind of visibility into what their agents are actually doing?
mailX by mailwarm
@francesco2689 This is an interesting parallel. We’re starting to see more conversations around visibility, trust, and observability for agent actions especially as agents become more autonomous. Once agents are acting on behalf of users, people want to understand the what and the why and whether the outcome was actually successful.
mailX by mailwarm
@francesco2689 Thanks! Glad it landed.
Same failure mode you described: the agent acted, the user trusted, the brand never saw. Visible to one side, invisible to the other.
Yes, teams ask for it, but framed as inbox placement so far. The agent-recommendation version isn't on most radars yet. It will be the moment founders realize their AI citation rate can drop silently the same way inbox placement always did.
What are you building?
mailX by mailwarm
@francesco2689 Yeah, this is exactly the direction things are heading.
There’s a growing gap between “what the system did” and “what the brand knows happened.” With email it’s spam filters and deliverability black boxes. With AI agents, it’s recommendations, tool calls, and decisions happening with zero audit trail for the brand. We’re starting to see teams ask for that visibility, not just logs, but explanations of outcomes: why something was recommended, what alternatives were considered, and when a competitor gets surfaced instead.
Mailwarm
@francesco2689 The real issue is visibility. If agents start making growth decisions, sending emails, choosing sources, recommending vendors, we need to understand the signals behind those decisions. Otherwise companies will lose pipeline without even knowing where it leaked.
Mailwarm
@francesco2689 Exactly. The real problem is visibility. If agents start sending, recommending, ranking, or choosing vendors, teams need to understand the signals behind those decisions.
Otherwise you lose pipeline silently, whether it’s email deliverability or AI search visibility.
That’s why we think diagnostics will become a core layer for AI workflows.
I don’t fully understand what the difference is compared to Mail-tester? It shows the same thing and gives recommendations, for free. It also gives a score from 1 to 10, just like in the video presentation.
And separately, does it show deliverability for Google and Microsoft separately?
mailX by mailwarm
@natalia_iankovych Honestly the is to many things to handle with deliverability.
Checkers
SPF
DKIM
DMARC
BIMI
SMTP Checker
IMAP Checker
Blacklist Checker
Generators
DMARC Generator
SPF Generator
BIMI Host
Finders
SMTP Finder
IMAP Finder
DNS
MX Lookup
TXT Lookup
CNAME Lookup
PTR Lookup
DNS Lookup
Here is what we can check right now if you want to compare with anything else, and the main difference is instead of understanding this keywords made for machines, we made it accessible fe AI agent check them via MCP.
mailX by mailwarm
@natalia_iankovych Fair question tools like Mail Tester are great for quick checks and basic validation.
With mailX, the goal is less about just giving a score, and more about helping users actually understand what’s wrong, why it matters, and how to fix it especially over time and across different workflows.
And yes, Google and Microsoft can behave very differently deliverability-wise, so provider-specific visibility is definitely something we care about.
Mailwarm
@natalia_iankovych Mail-tester is useful. The difference we’re building toward with mailX is broader: not only a one-time score, but a full diagnostic layer for web, API, and AI agents through MCP. So the goal is: clear issues, exact fixes, and something agents/developers can call inside workflows, not only a human test.
On Google vs Microsoft: today we mainly diagnose the setup and risks through mailX. Provider-specific inbox placement is part of where we’re going, because Gmail and Microsoft don’t behave the same at all.
But on mailwarm we do provide a SPAM Score per email provider. @manal_essalek1 will be happy to help you on that.
mailX by mailwarm
@natalia_iankovych That’s a fair comparison.
Mail-tester is mainly centered around testing a specific email by sending it to their inbox and getting a spam/content/authentication score back.
mailX is more focused on domain-level infrastructure audits and agent workflows through MCP, so the experience is closer to automated deliverability auditing than manual email testing.
On the Google/Microsoft question: right now we expose the underlying DNS/authentication checks directly rather than separate provider-specific inbox placement reporting.
JumprAI
The MCP angle is what makes this interesting to me.
I've been building with Claude agents and "agent sends email" workflows always have the same silent failure mode: it lands in spam, the agent reports success, and the user only finds out a week later when no one replied.
Diagnosing deliverability before the send (and exposing it as a tool the agent can actually call) is the right shape.
Curious, does the MCP server return structured remediation steps the agent can execute, or is it diagnostic-only for now?
Congrats on the launch !!
mailX by mailwarm
@itsmasa This is exactly the failure mode we’ve been thinking about. The agent reports emails were sent successfully, but from a deliverability perspective the operation may have completely failed.
And yes the direction is definitely toward structured remediation, not just diagnostics. We want agents to understand what's the issue and why it happened and what do next to fix it.
That’s where the MCP side becomes really interesting for us.
mailX by mailwarm
@itsmasa Thanks you, what are you building next?
mailX by mailwarm
@itsmasa Exactly, that silent failure mode is the worst part of agentic email.
mailX by mailwarm
@itsmasa It actually diagnose and give recos
Mailwarm
@itsmasa That silent failure is the problem: the agent says “sent”, but nobody knows if the email had a real chance to land. For now, MCP is mainly diagnostic.
Next step is structured remediation: actions an agent can suggest, prepare, and execute with human approval.
We don’t want agents changing DNS blindly. But they should know when to say: “don’t send yet, fix this first.”