Email API
Calendar API
Contacts API 
Scheduler
Notetaker API
Google email & calendar integration
Outlook email & calendar integration
IMAP integration
Google Meet integration
Zoom integration
Microsoft Teams integration
Docs
SDKs
Tutorials
API status
Changelog
Support
Blog
Events
Guides
Inspiration gallery
Build vs. buy
Customer stories
Security & Compliance
Why Nylas
Newsroom
Why emails sent via your app go to spam (but Outlook delivers them just fine)
• 4 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.
Check out the earlier posts:
• Understanding Microsoft 365 admin approval (and what it means for your integration)
• Why emails bounce (and how to fix deliverability issues)
• How to read Office 365 spam headers: A simple guide for non-admins
• How to fix Microsoft’s “service abuse mode” error
If emails sent through your app land in spam or bounce with errors like 554 5.7.1 or 5.1.8, it’s easy to assume something is wrong with your API call or integration.
Usually, nothing is wrong with your code.
In almost every case, the provider is blocking or filtering the message based on reputation signals, header manipulation, or the SMTP infrastructure third-party apps are forced to use.
This guide walks through the exact steps to diagnose the issue and figure out what’s actually happening behind the scenes.
Ask the user to send the exact same message from their webmail client (Outlook, Gmail, etc.).
If it fails both ways:
The problem is almost certainly:
With IMAP or generic accounts, this is the culprit 90% of the time.
Fix: The user’s mail admin or provider must resolve the domain or SMTP IP reputation issue.
If it only fails when sent via your app:
Then something in the programmatic send path is triggering filtering. Move on to the next checks.
If you use raw message/rfc822, you may unintentionally rewrite system headers — a major spam trigger.
Risky (raw MIME)
curl -X POST 'https://api.nylas.com/send' \
-H 'Content-Type: message/rfc822'Recommended (JSON MIME)
curl -X POST 'https://api.nylas.com/send' \
-H 'Content-Type: application/json'
Fix: Don’t modify headers. Modify the body instead. When possible, send JSON MIME — Nylas defaults to this format.
Emails sent from Outlook or Gmail’s UI use different SMTP servers than emails sent by third-party apps.
Third-party apps are routed to shared SMTP pools. If anyone in that pool sends spam, the IP reputation drops — and your messages get filtered.
How to confirm:
If any IPs are blacklisted:
The user’s mail admin must request new outbound SMTP IPs from:
Sometimes the mailbox is blocked before the message ever leaves the server.
Signs include:
Fix:
Admins should follow Microsoft’s recovery steps for send-blocked accounts.
Tracking URLs add redirect layers, which many filters distrust.
If deliverability improves without link tracking, you’ve found the issue.
Outlook uses Microsoft’s clean, reserved IPs.
Third-party apps use shared, noisier IP pools.
So users may say:
“It works when I send it from Outlook!”
Totally normal.
Fix options:
If the earlier checks don’t reveal the issue:
Most “Nylas sends to spam” issues aren’t Nylas problems — they’re provider filtering decisions.
Common root causes include:
A few quick checks usually reveal the cause.
If you’re still unsure, refer back to earlier posts in this series or check 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:
This post is part of our “What to do when there’s no email admin” series…
This post is part of our “What to do when there’s no email admin” series…
This post is part of our “What to do when there’s no email admin” series…
Sr. Manager, Technical Support Engineering