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.
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'
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.
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.
5. Try sending the email without link tracking
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: