Check If Email Was Sent: How to Find Out What Happened

A user gets in touch: they signed up, or asked for a password reset, and nothing arrived. Before you can help, you need to know one thing. Did your project actually send that email?

This guide shows people building with Claude Code how to check if an email was sent, find out why it didn't arrive, and get it fixed, with Claude Code doing the digging. If you haven't set up email in your project yet, start with how to send emails from Claude Code.

Why do emails go missing?

An email can go missing at three points: your project never asks to send it, your email service can't send it, or the receiving mail server turns it away.

Here's the journey of a typical transactional email, such as a password reset. (A transactional email is a one-to-one message your product sends because someone did something.)

1. The trigger. Your user does something, such as clicking "Forgot password". Your project should then ask your email service to send the reset email.
2. The email service. The service checks the request, then accepts it or rejects it with an error.
3. The receiving server. The service hands the email to the mail server for your user's address, which accepts or refuses it.
4. The mailbox. Once accepted, the receiving server files it in your user's mailbox.

If the problem is at step 1, there's no record of the email at all. At steps 2 and 3, the send log shows what went wrong. At step 4, the log says delivered, and the person needs to look a little harder on their side.

How do you check if an email was sent?

Look the email up in your email service's send logs. A send log is the service's record of every email your project asked it to send: who it went to, when, and what happened to it. Search by the person's email address and the time they say they tried.

Most services give each email a status. The exact words vary, but they usually mean something like this:

One detail catches people out. "Delivered" means the receiving mail server accepted the email. It doesn't tell you whether the person opened it or even saw it.

Bounces also come with a short code from the receiving server. Codes starting with 4 mean a temporary problem, so a later attempt may work. Codes starting with 5 mean a permanent failure that resending as-is won't fix. Claude Code can read these codes for you.

If you'd like your project to react to these statuses as they happen, that's what email webhooks are for.

What are the most common reasons an email didn't arrive?

Most missing emails come down to three causes: a wrong address, a trigger that never fired, or an error at the email service. Here's how to spot each one.

A wrong address. A typo such as jo@yourcompnay.com, a missing letter, or an old work address. The log shows a bounce, often with a code saying the mailbox or domain doesn't exist. The fix is the address, not the email.

The trigger never fired. There's no log entry at all, so something in your project stopped the request from going out. The step that sends the email might not be connected to that action, it might have broken after a recent change, or it might only work in your test version and not the live one. Claude Code can track this down by reading your project.

An error at the email service. The log shows "failed" or an error message. Common reasons are a missing or wrong secret key (an API key, the password-like code your project uses to prove it's allowed to send), a sending domain that isn't verified yet, or reaching your plan's sending limit. If the error mentions your domain, the guide to verifying your domain for email walks through the DNS records.

How can Claude Code check for you?

Ask it. With SimpleSends connected, Claude Code can read your send logs and delivery status through SimpleSends, check your project, and explain in plain English what happened to a specific email.

SimpleSends links to Claude Code through a connector, an add-on that uses MCP (Model Context Protocol, a standard way for AI tools to work with other services). Your live project still sends real emails on its own; the connector lets Claude Code work with SimpleSends while you build, including looking up what happened to those emails.

If you haven't connected SimpleSends yet:

1. Sign up on the SimpleSends website and follow the steps there to set up the email address you'll send from. To send from your own domain, this includes adding a few DNS records where your domain is registered.
2. In Claude Code, open Customize, then Connectors, choose Add, then Add custom connector. Name it SimpleSends and enter the MCP server URL https://mcp.simplesends.com/mcp.
3. When Claude prompts you to connect, log in to SimpleSends.
4. Back in the Claude Code chat, tell Claude Code: "I've connected SimpleSends for all transactional email."

Then describe the problem the way you'd describe it to a colleague:

A user at jo@yourcompany.com says they never got their password reset email. They tried around 2pm today. Can you check the send logs, tell me what happened, and explain it in plain English?

Claude Code looks the email up and reports back. Expect one of three answers: it was delivered (with the time), it bounced or failed (with the reason), or there's no record, which points to the trigger.

If there's no record, follow up:

There's no log entry, so it looks like the reset email never went out. Can you check whether the forgot-password button actually sends it in the live version of my project? Tell me what's wrong before you change anything.

How do you fix the problem and resend the email?

Fix the cause first, then resend, then test.

For a one-off resend, one message covers it:

I've corrected the address, so please send jo@yourcompany.com a fresh password reset email now. Then check the log and confirm it was delivered.

Password reset links often expire, so send a new one rather than forwarding an old one.

Once it's fixed, try the action yourself with your own address and confirm the email arrives. For a fuller routine before each release, see how to test your emails before your users see them.