Why your verification email landed in spam — and what to do about it

You enter a temp-mail address, click "send code", wait five minutes, refresh, and the inbox is empty. The default assumption is that the service blocked your domain. But there's a second possibility most users miss: the email was accepted by the temp-mail server and silently filtered into a spam folder you can't see.

How temp-mail handles spam

Most temp-mail providers do not show you a spam folder. Mail.tm has a single Inbox; Mail.gw the same; Maildrop likewise. If their backend SpamAssassin or Rspamd rules tag a message as spam (score ≥ 5), it's either:

• silently dropped at SMTP time (550 reject)
• accepted but moved to a hidden spam folder you can't see via the API
• accepted into the inbox but with a <spam> HTML tag prepended to the subject (rare; some legacy providers)

This is opaque to the user. From your side it looks like the email never arrived.

Common reasons OTP emails get tagged as spam

1. Sender reputation. If the SaaS service uses a shared SMTP provider (SendGrid, Mailgun) and another customer on that pool is currently sending spam, the IP's reputation drops; emails sent from it get flagged. Has nothing to do with you.
2. Missing SPF / DKIM / DMARC. Properly authenticated email (SPF pass + DKIM pass + DMARC alignment) rarely gets flagged. Misconfigured services get tagged.
3. Suspicious content. All-caps subject, lots of links, all-image emails, unusual character sets. Legitimate OTP emails normally clear this hurdle, but some poorly-templated ones don't.
4. Volume burst. Sending 10,000 OTPs in 10 seconds from a new IP triggers spam filters. Affects new SaaS launches occasionally.
5. Domain-pattern blocklists at the temp-mail server. Some temp-mail providers run their own anti-spam to keep their servers from being abused as spam-laundering infrastructure. Marketing emails get auto-deleted; transactional sometimes gets caught in the same net.

How to verify it's a spam-filter problem and not a domain block

PocketInbox switches providers automatically. If you see "no mail" for 60 seconds:

1. Click Refresh manually first — sometimes there really is a 30s delay from the upstream SMTP provider.
2. If still empty, click New address and try again. If the email arrives on the new address, the original domain was blocked at the SaaS service's outbound layer.
3. If still empty on the new address, switch providers (PocketInbox rotates Mail.tm → Mail.gw → TempMail.lol). If it arrives on a different provider, the original temp-mail server's spam filter ate the message.
4. If it doesn't arrive on any provider, you probably need a real email — the service has aggressive disposable-email blocking.

The boring fix: check your sender

If you're a developer running into this on your own SaaS:

• Use mail-tester.com from your transactional sender. Send a test email; get a score. Any score below 8/10 means your OTP emails are at risk.
• Set up SPF, DKIM, DMARC. There's no excuse not to. A DMARC quarantine policy (p=quarantine; sp=quarantine) helps deliverability.
• Use a dedicated sending IP for transactional emails. Don't mix marketing volume with OTPs; reputation pollution is real.
• Keep OTP email content minimal. Plain text. One link. No tracking pixels. Spam filters love minimal.

If you're a user and you keep losing OTPs

Pragmatic advice:

• Try PocketInbox. Multi-provider failover catches a lot of these issues automatically.
• For services where receiving the email is critical (banking, two-factor recovery), use a real address you control.
• For non-critical signups (newsletters, free trials), if the OTP doesn't arrive in 2 minutes on three different providers, the service has decided you're not allowed to use temp mail and you have to use real email.

Related: Temp mail for 2FA — when it works and when it doesn't · Why is disposable email blocked here?.