If you've run a system that sends email, you've probably hit this wall:

  • Your email provider says Sent ✅
  • Logs say Delivered ✅
  • No bounces
  • No complaints …and yet the recipient insists they never received anything.

Most deliverability articles stop at SPF. Production incidents start after that.

This post is written as an operator's guide, not a checklist blog. This is the guide you need when this happens.

The Incident (Why This Guide Exists)

We sent transactional email from a new domain to a corporate domain. Here's what our system showed:

[SYSTEM CHECK — Sender Side]

Provider Sent:       ✅ Yes
Provider Delivered:  ✅ Yes
Bounces:             ❌ None
Complaints:          ❌ None

Delivery events were recorded at a specific UTC timestamp.

From the sender's side, everything succeeded. From the recipient's side, nothing arrived.

This is not an edge case.

First Principle: "Delivered" Is a Transport Result, Not an Inbox Result

This is the most important concept in email deliverability.

Delivered means:

  • The recipient's mail server accepted the message during SMTP transfer.

It does NOT mean:

  • It reached a human inbox
  • It bypassed internal security checks
  • It wasn't quarantined, delayed, or silently dropped

Modern corporate email systems accept first, filter later.

Once the message is accepted, everything that happens next is invisible to the sender.

That's why:

  • You see no bounce
  • Your provider shows "Delivered"
  • The user never sees the email

This isn't an error; it's the intentional design of enterprise security.

Before You Escalate: Prove It's Not Your System

You should never push the problem to the recipient until you've ruled out your side cleanly and confidently.

Step 1: Confirm provider-level delivery

In your ESP (SES, SendGrid, Mailgun, etc.):

  • Verify Send and Delivery events
  • Confirm no bounces
  • Confirm no complaints
  • Check suppression lists (account-level and global)

If the provider shows Delivered and the address isn't suppressed, the message has left your control.

SES note (quick checks)

  • Suppression list: SES Console → Suppression list
  • Message-ID + UTC timestamp: capture these from your SES delivery events (useful for the recipient's IT team / Message Trace)

Step 2: Verify authentication (once, properly)

At minimum, you should know this is true:

  • SPF: pass
  • DKIM: pass
  • DMARC: pass or monitoring (p=none)

If you're unsure, send a test email to a diagnostic inbox and check authentication results.

Important reality check:

A perfect spam-test score means you are not obviously broken. It does not guarantee inbox placement in corporate systems.

Step 3: Sanity-check neutral inboxes

Send the same email to:

  • Gmail
  • Outlook.com
  • ProtonMail

If those receive it immediately, your infrastructure is fine.

At this point, probability strongly shifts to recipient-side filtering.

The Part Most Articles Skip: Corporate Email Reality

Corporate email behaves nothing like consumer inboxes.

Common behaviors:

  • New domains are treated as suspicious by default
  • Emails are quarantined without notifying the user
  • Attachments or links trigger silent blocking
  • Quarantine notifications are delayed, broken, or disabled

Other signals corporate gateways evaluate (and you usually can't see):

  • Domain age and sender reputation (new domains start "guilty until proven safe")
  • Reverse DNS + HELO/EHLO consistency (does the sending infrastructure look legitimate)
  • TLS quality (is the SMTP connection encrypted and configured cleanly)
  • URL reputation of embedded links (a clean email can still be blocked because of a flagged domain)

So when users say "I never got anything," they're often telling the truth — nothing reached their inbox, and they never saw a quarantine alert.

What Actually Happened (Most Likely)

Given:

  • Provider shows Delivered
  • No bounces or complaints
  • Emails arrive fine to consumer inboxes
  • Recipient domain is corporate

The conclusion is straightforward:

The emails were accepted by the recipient's mail server and then filtered internally.

Most common reasons:

  1. Corporate spam filter quarantined emails from a new sender domain
  2. Email security gateway blocked or delayed the message
  3. Messages landed in Junk without user notification

This is how enterprise email security is designed to work.

The Operational Reality: Whitelisting Takes Time

Here's a truth many posts avoid saying out loud:

Domain or sender whitelisting inside corporations can be slow, bureaucratic, and outside your control.

Depending on the company, whitelisting may require:

  • IT tickets
  • security reviews
  • policy approvals
  • waiting on someone in another timezone

That means "just whitelist us" is not always the fastest resolution.

What often works faster

After improving authentication or sender signals:

  • Ask the recipient to test again
  • Sometimes, the updated signals are enough for the gateway to allow delivery
  • If not, then you wait for whitelisting

This is a practical, time-saving step — and it matters in real incidents.

The Only Message You Need to Send the Recipient

This is where incidents either resolve quickly or drag on for days.

Send exactly this:

Our email provider confirms successful delivery to your mail server at [UTC timestamp], with no bounces or complaints.

Could your IT team please:
1. Check spam and junk folders
2. Check quarantine or email security gateway logs for emails from support@yourdomain.com 
3. Whitelist yourdomain.com or support@yourdomain.com

This is common for new sender domains and corporate email systems.

If whitelisting takes time, ask them to re-test delivery after recent fixes.

If they use Microsoft 365 / Exchange, ask them to run a Message Trace using:

  • Sender address
  • UTC timestamp window
  • Subject or Message-ID

Don't argue about RFCs. At this stage, the solution is operational, not theoretical.

"We Improved It" — What That Actually Means

During investigation, DevOps often:

  • Tightens DMARC alignment
  • Improves authentication results
  • Improves spam-test scores

This is necessary and good.

But understand this clearly:

Improving authentication won't release quarantined emails. Corporate gateways don't reprocess quarantined mail.

The recipient still needs to:

  • Release from quarantine or
  • Whitelist sender or
  • Re-test delivery after improvements

Both sides must act.

The 10-Minute Decision Tree (Bookmark This)

Email not received
└─ Provider says NOT delivered  => [Sender/ESP issue]
└─ Provider says DELIVERED      => Continue
   ├─ Fails on Gmail/Outlook    => [Sender-side issue: auth/content/reputation/suppression]
   └─ Works on Gmail/Outlook    => [Recipient-side filtering]
      └─ Corporate domain?      => [Likely quarantine/security gateway]
         └─ ACTION: Message Trace -> Re-test -> Whitelist

This resolves most real-world cases.

If you run transactional email long enough, you'll see this pattern again. Bookmark this section.

Prevention (You Can Reduce Pain, Not Eliminate It)

To minimize future friction:

  • Use a dedicated subdomain for transactional email
  • Start DMARC in monitoring mode (p=none) and mature gradually
  • Warm up new domains before critical sends
  • Avoid attachments early; use secure links
  • Log Message-ID and UTC timestamps for support cases

Most importantly:

Email deliverability is a shared system, not a guarantee.

SPF, DKIM, DMARC — How They Actually Work (Plain English)

If you've configured these but don't fully get them, here's the mental model.

SPF — "Is this server allowed to send for this domain?"

SPF is a DNS rule that says:

"These servers are allowed to send email claiming to be from my domain."

Missing or incorrect SPF increases quarantine risk.

DKIM — "Was this message signed and unchanged?"

DKIM cryptographically signs the email.

It proves:

  • The domain authorized the email
  • The content wasn't altered in transit

DMARC — "If something looks wrong, what should receivers do?"

DMARC:

  • Ties SPF/DKIM to the visible From: domain
  • Defines policy (none/quarantine/reject)
  • Sends reports so you can see failures and spoofing

Even with SPF/DKIM present, misalignment can trigger corporate filtering.

The Full Modern Flow

  1. Your app sends email via ESP
  2. ESP connects to recipient gateway
  3. Gateway checks SPF, DKIM, DMARC
  4. Message is accepted
  5. Internal security scans run
  6. Email is delivered, quarantined, junked, or dropped

Only steps 1–4 are visible to the sender.

Final Takeaway

If there's one sentence to remember:

"Delivered" means the other server said 'thanks', not that a human saw it.

Most email incidents aren't caused by broken SPF records. They're caused by invisible corporate filters doing exactly what they were designed to do.

Once you understand that, email deliverability stops feeling mysterious and starts feeling debuggable.