---
title: "Why aren't my users getting my emails, and how do I fix it"
slug: users-never-got-login-code
description: "How to find out why a user never got a login code, receipt or newsletter your app says it sent, from typos and suppressions to quarantines, spam and delays."
created_at: "2026-10-13"
updated_at: "2026-10-13"
humans: ["jp-valery"]
---

When key emails like login codes don't arrive, it blocks your users, clogs your support queue, and can often lead to churn or missed sales opportunities.

Why do emails not arrive? Most cases come down to 1 of 6 causes:
1. a typo in the address
2. an address on your suppression list
3. a bounce or a delay
4. a quarantine at the user's company
5. an inbox that filed the email where the user didn't look
6. a domain that inbox providers don't trust yet

In this guide, we'll walk through each cause in the proper order to help you diagnose the problem.

## Start with who's affected

Before you change anything, look at how many people are missing your emails and which email providers they use.

<Table
  data={{
    headers: ["Who's affected", "Most likely cause", "Where to look"],
    rows: [
      ["A single user", "A typo in the address, a suppressed address, or a quarantine at the user's company", "Your provider's logs and suppression list, then the user's spam folder or quarantine"],
      ["Users at a single email provider, such as Outlook or Hotmail", "Your domain's reputation at that provider, often after a new domain or a jump in volume", "Bounce and deferral messages from that provider"],
      ["Users at a single company", "The company's spam filter or security gateway", "The company's IT team"],
      ["Everyone", "An unverified domain, broken authentication, or a bug in your sending code", "Your provider's API logs and domain settings"],
    ],
  }}
/>

Identifying the group affected helps you understand the scope and identity of the problem. Authentication issues affect everyone at once, for instance, so when only one user is affected, start with the address and the logs.

## How to trace an email your app says it sent

"Sent" in your app and "in the inbox" are separate steps, and an email can stop at any point between them. Trace it from your code, to your email provider, to the recipient's mail server.

1. **Find the request.** Most email APIs return an ID when they accept an email. Store the ID with the user or the order, so you can look the email up later instead of searching by address and time.
2. **Check whether your provider has a record of it.** If your provider has no record, the email never left your app: the request failed, or your code never made it. Your application logs should reveal the error.
3. **Check the delivery status.** Once your provider accepts an email, it reports what happened next.

<Table
  data={{
    headers: ["Status", "What it means"],
    rows: [
      ["Sent", "Your provider processed the email and is delivering it to the recipient's mail server."],
      ["Delivered", "The recipient's mail server accepted the email. Where it goes next, inbox, spam or quarantine, is up to the recipient's provider."],
      ["Delivery delayed", "The recipient's server deferred the email with a temporary error, such as a full inbox or rate limiting. Your provider keeps retrying."],
      ["Bounced", "The recipient's server rejected the email. The bounce message explains why."],
      ["Suppressed", "Your provider skipped the email because the address is on your suppression list."],
    ],
  }}
/>

The more detailed your logging, the easier it will be to identify the problem. Gather timestamps and status data at each step to see exactly where an email got stuck in the process.

## How to check whether the address is the problem

When a single user is affected, look at the address before anything else.

- **Typos.** The most common error is a user-mistyped email address. Show the address on your "check your email" screen so users can spot their own typo. At signup, an [email verification service](/blog/best-email-verification-apis) can check the address's syntax, confirm its domain accepts email, and in some cases suggest a fix for a misspelled domain.
- **Suppressed addresses.** Email providers keep a suppression list (addresses they stop sending to after a hard bounce or a spam complaint) to protect your reputation. An address that bounced once stays suppressed until you remove it, even if the user has fixed the problem since. Remove it only after you fix the cause, or it'll bounce and land back on the list, possibly harming your sending reputation.
- **Apple Hide My Email addresses.** Users who sign in with Apple can hide their real address behind one ending in `@privaterelay.appleid.com`. Apple only forwards email to those addresses from domains and sender addresses you've [registered with Apple](https://developer.apple.com/documentation/signinwithapple/communicating-using-the-private-email-relay-service). Everything else bounces.

## What "delivered" means when the user still can't find the email

"Delivered" only means the recipient's mail server accepted the email. From there, the recipient's provider decides where it goes, and it doesn't report back to you. A delivered email can still land in one of these places:

- **Spam or junk.** Spam placement is most likely for new domains, for the first email a user gets from you, and for very short emails.
- **A tab or folder the user doesn't watch.** Gmail sorts mail into tabs such as Promotions and Updates, and Outlook splits the inbox into Focused and Other. The [Promotions tab isn't a spam signal](/blog/why-you-should-embrace-promotions-tab-gmail), but a login code filed under Updates or Other can go unnoticed, especially when the user only gets notifications for their main inbox.
- **Quarantine.** Company email systems can hold suspicious mail outside the user's mailbox entirely, where the user never sees it unless they go looking.
- **A forwarded inbox.** Users who forward their email to another address depend on a second delivery. Forwarded mail [often fails SPF](https://www.rfc-editor.org/rfc/rfc7960#section-3.2.1), because the forwarding server isn't one of yours, and the destination provider can still send it to spam or drop it.

Ask the user to search all their mail, spam included, for the exact subject line. A subject line search finds the email faster than a search by sender name, and Microsoft's quarantine search also matches on the full subject.

## When a company quarantines your login and invite emails

Quarantine is a holding area that company email systems, such as Microsoft 365 and Google Workspace, use for messages they consider risky. Unlike the spam folder, quarantine sits outside the user's mailbox, so most users never see what's in it. The email system also deletes quarantined messages automatically after a set period.

B2B apps run into quarantine often, because login and invite emails from an unfamiliar sender look a lot like phishing to a security filter. A quarantined email needs a manual action:

- **In Microsoft 365**, users can [find and release quarantined messages](https://learn.microsoft.com/en-us/defender-office-365/quarantine-end-user) at `security.microsoft.com/quarantine`, and choose "Allow sender" for future emails. Messages quarantined as high-confidence phishing or malware can only be [released by an admin](https://learn.microsoft.com/en-us/defender-office-365/quarantine-admin-manage-messages-files).
- **In Google Workspace**, an admin can find the message with [Email Log Search](https://knowledge.workspace.google.com/admin/gmail/advanced/email-log-search-delivery-status-definitions), which shows whether Gmail delivered the message, marked it as spam, or quarantined it.

Releasing a message only delivers that one email. If later emails still end up in quarantine, ask the company's IT team to allowlist your sending domain.

## What to send a customer's IT team so they allowlist your emails

When a customer's IT team asks how to allowlist your emails, give them your sending domain and your return-path domain, not IP addresses. The return-path domain is where bounces go, and it appears in every email's headers. Most email providers send from shared pools of IP addresses that change over time, so an IP allowlist breaks without warning.

Here's a message you can adapt and send:

> Our records show your mail server accepted the email, but it didn't reach the recipient's inbox, which usually means your email system quarantined it. You can release it from quarantine, or a Microsoft 365 user can release it at security.microsoft.com/quarantine. To prevent this for future emails, please allowlist our sending domain, `example.com`, and our return-path domain, `bounces.example.com`.

If the company's filters still quarantine your emails after the allowlist, the quarantine reason in their admin tools shows which rule caught them.

## Why login code and password reset emails go to spam

Phishing emails tend to be short: a line of text, a code or a link, and no context. Spam filters treat a login email with the same shape the same way. A few changes make yours easy to tell apart.

- **Add context.** Name your app, explain why the user is getting the email, and say what to do if they didn't ask for it: "_You're receiving this code because someone tried to sign in to MyApp with this address._"
- **Link to your own domain.** Spam filters flag links to free hosting subdomains, such as `vercel.app`, because spammers use them too, and a link domain that doesn't match your sending domain looks like phishing. Keep your website and your sending domain on the same root domain: don't send from `myapp.app` if your site is at `myapp.com`.
- **Send from your own domain.** The default senders of auth services like Supabase and Firebase send from domains shared with many other apps, so you inherit their reputation. Set up your own domain before you launch.
- **Separate login emails from marketing.** A big marketing send can get your domain throttled, and password resets from the same domain get stuck behind it. Send each type of email from [its own subdomain](/docs/knowledge-base/is-it-better-to-send-emails-from-a-subdomain-or-the-root-domain), such as `auth.example.com` and `news.example.com`.
- **Plan for launch-day spikes.** A launch can bring in more signups than your domain's history supports. Ramp up ahead of time, as covered in [how to warm up a new domain](/guides/email/new-domain-emails-going-to-spam) and [how to prepare for Black Friday](/guides/email/prepare-sending-for-black-friday).

## Why emails take 5 to 20 minutes to arrive

Most emails arrive within seconds, but some take minutes. Compare 2 timestamps to find out where the time goes: when your app sent the email, and when your provider reported it as delivered.

The first step is to identify where the delay is happening: in your app or the receiving mail server.

If the delay comes before "sent", the email is stuck in your app, often in a job queue behind bulk work. Give login codes and password resets their own queue, so a newsletter can't hold them up.

If the delay comes after "sent", the recipient's server is deferring you, and no code change on your end will fix it. Your email provider retries deferred emails automatically, and most of them arrive within the retry window. For more details, see the SMTP response, which explains the delay:

- **Greylisting.** Some providers, smaller European ones in particular, temporarily reject email from senders they don't know and accept it on the next retry. Greylisting is a [standard anti-spam technique](https://www.rfc-editor.org/rfc/rfc6647), and it mostly affects new domains.
- **Throttling after a jump in volume.** Gmail responds with `421 4.7.28` when it sees an unusual rate of email from you. Microsoft responds with `451 4.7.500` to `4.7.699`, which it calls [IP throttling](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/fix-error-code-451-4-7-500-699-asxxx-in-exchange-online) and says resolves as you build a sending history over a few days.
- **A busy or full inbox.** Some deferrals are about the recipient, not you. Gmail's `4.2.1` response means "the user you are trying to contact is receiving email at a rate that prevents additional messages from being delivered", and `4.2.2` means "the recipient's inbox is out of storage space."
- **Attachment scanning.** Company security gateways scan attachments before delivery, which adds time. Attachments also make emails heavier and harder to read on mobile, so link to a secure, hosted file instead.

Even after your provider marks an email as delivered, some inbox providers take a few more minutes to process it before it appears in the inbox. If slow deliveries follow a pattern, look at which inbox providers they have in common.

## Why users at some email providers miss your emails

Internet providers and regional email services, such as Comcast, AT&T, Orange, T-Online and GMX, are often harder to reach than Gmail or Outlook. Their spam filters can be stricter, and they rarely offer reporting tools like [Google Postmaster Tools](https://support.google.com/mail/answer/9981691) to show how they rate your domain. When users at one of them keep missing your emails, contact the provider's postmaster team directly.

University addresses, often ending in `.edu`, sit behind some of the strictest inbound filters. Expect the same kind of [quarantine](#when-a-company-quarantines-your-login-and-invite-emails) and [allowlist](#what-to-send-a-customers-it-team-so-they-allowlist-your-emails) conversations as with B2B customers.

## When subscribers say they aren't getting your newsletter

The same checks apply to newsletters, with a few additions:

- **Check their subscription first.** Make sure the address is still subscribed and not on your suppression list.
- **Look at the whole send.** When a slice of your list missed a newsletter, check the bounce and suppression rates for that send before looking at individual addresses.
- **Watch for work addresses.** Company filters and quarantines are the most likely to hold newsletters sent to work addresses.

## How to cut down on "never got the email" tickets

You can prevent most of these tickets on the screen users see right after you send the email:

- **Show the address** you sent the email to, so users can catch a typo.
- **Tell users what to look for:** your sender name and subject line, in all folders, including spam.
- **Add a resend button**, rate limited so users can't trigger 10 emails in a row.
- **Show the email's status:** "sent" once your provider accepts it, and "delivered" once the delivered event comes back.

Give support agents the same resend button for receipts, invoices and confirmations, wired to the function that sent the original.

A help article for users who aren't getting your emails saves your support team time. List your sender name and a typical subject line so readers can copy them into a search, ask them to check spam and other tabs, and ask users with a work address to check their quarantine or contact their IT team. If none of that works, ask them to contact you, so you can check whether the email bounced or landed on your suppression list.

## "Never got the email" triage checklist

1. Confirm the exact address with the user, and look for typos.
2. Find the email in your provider's logs by its ID, or by address and time.
3. If your provider has no record of the email, check your application logs for an API error.
4. If your provider suppressed the email, find out why, fix the cause, then remove the address from your suppression list.
5. If the email bounced, read the SMTP response in the bounce message.
6. If the recipient's server is delaying delivery, let the retries run, and read the SMTP response if the email ends up bouncing.
7. If the email shows as delivered, ask the user to search all their mail, spam included, for the exact subject line.
8. If the user has a work address, ask them to check quarantine or contact their IT team.
9. If several users at the same provider are affected, look at your volume and reputation with that provider.
10. If everyone is affected, check your domain verification, your authentication records, and your API credentials.

## Other details to keep in mind

When a single user is missing an email, leave your DNS records alone. Your authentication records (SPF, DKIM and DMARC) apply to a sending domain, so a broken record can affect all mail sent through that domain. Editing your records to fix one user's problem can break delivery for other users of that domain.

Find out which emails generate the most tickets. People tend to reply to the email itself, so searching your support inbox by subject line shows which emails need work first.

Don't wait for users to tell you. Alerts on bounces and delivery delays show a problem with a provider or a domain before your support inbox fills up.

## How to find missing emails with Resend

<Callout type="info">

- Store the `id` the [Send Email API](/docs/api-reference/emails/send-email) returns, and look the email up on the [Emails page](/emails) or with the [Retrieve Email API](/docs/api-reference/emails/retrieve-email). Each email's [event timeline](/docs/dashboard/emails/manage-emails) shows whether it was sent, delivered, delayed, bounced or suppressed.
- We retry delayed emails for up to 14 hours before marking them as bounced. Hover a Bounced label to see the [bounce details](/docs/dashboard/emails/email-bounces).
- Check the [suppression list](/docs/dashboard/emails/email-suppressions) for the address, and remove it once you've fixed the cause.
- Find failed API requests, with the full request and response, on the [Logs page](/docs/dashboard/logs/introduction).
- Use the `email.delivered`, `email.delivery_delayed`, `email.bounced` and `email.suppressed` [webhooks](/docs/webhooks/event-types) to show a status on your "check your email" screen, or to alert your team.
- Register your domains with Apple before sending to [Hide My Email addresses](/docs/knowledge-base/sending-apple-private-relay).

</Callout>

## FAQ

**What's the difference between quarantine and the spam folder?**

The spam folder is part of the user's mailbox, so they can open it and move your email out. Quarantine belongs to their organization's email system and sits outside the mailbox, often where only a separate portal or an admin can reach it. The system deletes quarantined messages automatically after a set period.

**Do Hide My Email, Firefox Relay, or DuckDuckGo addresses change anything?**

Mostly no. Relay services forward your email to the user's real inbox. The exception is Sign in with Apple: its `privaterelay.appleid.com` addresses only accept email from domains and sender addresses you've registered with Apple.

**How do AI inbox features handle login codes and receipts?**

Inbox providers are adding summaries and code detection, and there's no standard yet for marking an email as a one-time code. Keep the code and its purpose clearly visible near the top of the email, in plain text.

**Why did some people get my newsletter twice?**

The reader probably subscribed with 2 addresses that lead to the same inbox, such as an alias and their main address. Both are valid, so both get the newsletter.

**Why are my emails grouped into one conversation in Gmail?**

Gmail can group emails with the same subject into one conversation, so a new login code ends up hidden under older ones. Give each email a distinct subject, for example by including the order number. You can also give each email an [`X-Entity-Ref-ID` header](/docs/dashboard/emails/custom-headers) with a unique value, such as a UUID, which stops Gmail from grouping them.

## Sources

- Google, [Gmail SMTP errors and codes](https://knowledge.workspace.google.com/admin/support/troubleshooting/gmail-smtp-errors-and-codes), accessed October 13, 2026
- Google, [Email Log Search delivery status definitions](https://knowledge.workspace.google.com/admin/gmail/advanced/email-log-search-delivery-status-definitions), accessed October 13, 2026
- Microsoft, [Find and release quarantined messages as a user](https://learn.microsoft.com/en-us/defender-office-365/quarantine-end-user), accessed October 13, 2026
- Microsoft, [Manage quarantined messages and files as an admin](https://learn.microsoft.com/en-us/defender-office-365/quarantine-admin-manage-messages-files), accessed October 13, 2026
- Microsoft, [Fix NDR error 451 4.7.500-699 (ASxxx) in Exchange Online](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/fix-error-code-451-4-7-500-699-asxxx-in-exchange-online), accessed October 13, 2026
- Apple, [Communicating using the private email relay service](https://developer.apple.com/documentation/signinwithapple/communicating-using-the-private-email-relay-service), accessed October 13, 2026
- IETF, [RFC 6647: Email Greylisting](https://www.rfc-editor.org/rfc/rfc6647), accessed October 13, 2026
- IETF, [RFC 7960: Interoperability Issues between DMARC and Indirect Email Flows](https://www.rfc-editor.org/rfc/rfc7960), accessed October 13, 2026
- Resend, [What if an email says delivered but the recipient has not received it?](/docs/knowledge-base/what-if-an-email-says-delivered-but-the-recipient-has-not-received-it), accessed October 13, 2026