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.
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:
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.
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.
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.
Fix:
The organization’s mail admin needs to request new outbound SMTP IPs from:
This issue is far more common than people think.
Sometimes the provider blocks a specific mailbox before the message even leaves their server.
Common symptoms include:
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.
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:
If all else fails:
If it’s happening across all messages for a specific provider, it’s time to escalate.
Most bounce and spam issues boil down to:
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:
Sr. Manager, Technical Support Engineering