Why emails bounce (and how to fix deliverability issues without an email admin)

Why emails bounce (and how to fix deliverability issues without an email admin)

5 min read

This post is part of our ‘What to do when there’s no email admin’ series — practical guides for anyone who suddenly finds themselves responsible for email systems they’ve never touched before.

If you missed the first post, you can read it here:
Understanding Microsoft 365 admin approval.


What to do when messages land in spam, get blocked, or return cryptic 5.7.1 errors

If you’ve ever pushed an email through your app only to have it bounce, disappear, or drop straight into a spam folder, it can feel like something is broken in your integration.

Usually it isn’t.

Most of the time, your users are running into classic deliverability issues — the kind an IT admin would normally diagnose. But if you’re the admin (or there simply isn’t one), here’s how to quickly figure out what’s going wrong and what you can safely fix on your own.

This blog breaks down the most common causes of bounced or spammed messages, how to read what the bounce codes are telling you, and what you can do without needing deep email-server expertise.

1. First: Check whether the issue only happens when sending via your app

This is the quickest way to narrow down the root cause.

Ask the user to send the exact same message from their webmail client (Outlook.com, Gmail, etc.). Then compare results.

If it fails both ways:
The problem is almost always:

  • The provider’s SMTP IP reputation
  • The sender domain’s reputation
  • Bad DNS configuration

This happens constantly for IMAP/generic accounts.

Fix: They’ll need their email admin or provider to resolve the domain/IP reputation issue.

If it only fails when sent via your app:
Move on to the checks below — something in the programmatic send path is being flagged.

2. Check if your app is modifying headers (providers hate this)

If you’re sending using the raw message/rfc822 format, you may unintentionally be rewriting or overwriting system headers. That’s a huge spam trigger for Microsoft, Google, and most filtering engines.

Raw MIME example (risky)

curl -X POST 'https://api.nylas.com/send' \
  -H 'Content-Type: message/rfc822'

MIME JSON example (recommended)

curl --request POST \
  --url https://api.nylas.com/send \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json'

Fix:
Don’t modify headers. Modify the body instead. If possible, avoid raw MIME unless you truly need it.

3. Understand Microsoft & Google’s two-SMTP-server model

This is the part most non-admins never learn:

Emails sent from Outlook or Gmail’s UI do not use the same SMTP servers as third-party applications.

Apps like Nylas get routed to pooled outbound servers shared with other organizations. If anyone in that shared pool sends spam, the IP reputation drops — and your messages get blocked even if your content is clean.

To diagnose this:

  1. Open the sent message and grab the full headers
  2. Collect the SMTP hostnames/IPs
  3. Test those IPs using MXToolbox: https://mxtoolbox.com/blacklists.aspx

If the IPs show blacklist issues:

Fix:
The organization’s mail admin needs to request new outbound SMTP IPs from:

  • Microsoft 365 Support
  • Google Workspace Support

This issue is far more common than people think.

4. Check whether the account is actually blocked for sending spam

Sometimes the provider blocks a specific mailbox before the message even leaves their server.

Common symptoms include:

  • Microsoft bounce code 5.1.8
  • Sudden inability to send via API but Outlook still works

Fix:
Admins can follow Microsoft’s recovery steps for 5.1.8 to unblock the account.

Tracking URLs add redirect layers and can trigger phishing or spam filters.

If deliverability improves without tracking, you’ve found the issue.

6. Office365: Why Outlook delivers to inbox, but your app goes to spam

This one confuses developers constantly.

Emails sent via Outlook use Microsoft’s reserved, clean outbound IPs.
Emails sent via apps use shared third-party IP pools, which are noisier and often associated with bulk sending.

So the user may say:

“But it works when I send from Outlook!”

Completely normal.

Fix options:

  • Request new IPs from Microsoft
  • Switch providers if the shared IP reputation issues persist

7. Everything looks clean — now pull the full headers

If all else fails:

  • Grab the raw headers
  • Look for the full spam report
  • Check all IPs and domains against blacklist tools
  • Use the message ID to trace how the provider evaluated the message
  • Drop the headers into a diagnostic tool (yes, even ChatGPT) to interpret flags

If it’s happening across all messages for a specific provider, it’s time to escalate.

You don’t need to be an email admin to diagnose deliverability issues

Most bounce and spam issues boil down to:

  • Sender or IP reputation
  • Strict security filters
  • Header manipulation
  • Shared SMTP pools
  • DNS or configuration mismatches

And most of these can be identified with a few simple checks — no deep IT knowledge required.

If you run into persistent issues or unclear bounce codes, you can refer back to the support article or the Nylas Developer Docs for deeper guidance.

This post is part of our “What to do when there’s no email admin” series.
If you haven’t yet, read earlier entries:

Related resources

How to read Office 365 spam headers: A simple guide for non-admins

This post is part of our “What to do when there’s no email admin” series…

Understanding Microsoft 365 admin approval (and what it means for your integration)

This post is part of our “What to do when there’s no email admin” series,…

How to integrate Zoom meetings into a SaaS application

Quick summary: Compares how developers can use the Zoom Cloud Recording API, custom Linux SDK…