Build for free
Why emails sent via your app go to spam (but Outlook delivers them just fine)

Why emails sent via your app go to spam (but Outlook delivers them just fine)

• 4 min read
Jump to section
Author: Alex Petersen
Alex Petersen
Tags:
Featured articles
Agentic AI
The State of Agentic AI in 2026: What teams are actually shipping
• 6 min read
Read more
Nylas Transactional Send public beta launch
• 4 min read
Read more
Notetaker API
Introducing Summaries and Action Items for the Notetaker API
• 3 min read
Read more
Jump to section

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.

1. Confirm it only happens when sending through your app

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:

  • Poor IP reputation on the provider’s SMTP server
  • Low sender domain reputation
  • DNS issues (SPF/DKIM/DMARC mismatch)

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.

2. Check if your application is modifying headers

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.

3. Understand Microsoft and Google’s dual-SMTP model

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:

  1. Pull the full headers.
  2. Copy all SMTP hostnames and IPs.
  3. Check them with MXToolbox:
    https://mxtoolbox.com/blacklists.aspx

If any IPs are blacklisted:
 The user’s mail admin must request new outbound SMTP IPs from:

  • Microsoft 365 Support
  • Google Workspace Support

4. Check whether the account is actually sending spam

Sometimes the mailbox is blocked before the message ever leaves the server.

Signs include:

  • Bounce codes like 5.1.8
  • Can send via Outlook but not via API
  • Sudden send failures

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.

6. Office365 inbox vs. API spam placement

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:

  • Ask Microsoft to assign cleaner outbound IPs
  • Switch providers if IP issues repeat

7. If everything looks clean, pull the full headers

If the earlier checks don’t reveal the issue:

  1. Grab the raw headers
  2. Review spam evaluation fields (IPV, SCL, SFV)
  3. Test all domains and IPs in the chain
  4. Use diagnostic tools to interpret filtering
  5. Escalate if all messages to a specific provider fail the same way

You don’t need to be an email admin to diagnose this

Most “Nylas sends to spam” issues aren’t Nylas problems — they’re provider filtering decisions.

Common root causes include:

  • IP reputation issues
  • Shared SMTP pools
  • Header manipulation
  • Tracking layers
  • Domain reputation problems
  • Provider-level blocks

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:

Related resources

What to do when there’s no email admin
How to fix Microsoft’s “service abuse mode” error

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

• 3 min read
Read more
What to do when there’s no email admin
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…

• 4 min read
Read more
What to do when there’s no email admin
Why emails bounce (and how to fix deliverability issues without an email admin)

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

• 5 min read
Read more