GauntletEST. VERDICT ~15 MIN Contact sales
Email delivery diagnostics IT teams · 20–200 seats verdicts from real filters

Your mail didn’t bounce. It vanished.

Trace says Delivered. The inbox is empty. We tell you which filter ate it and how to get it back, read straight off that filter’s own console. No simulation.

Contact sales See how it works ↓

Preliminary verdict in ~15 min, final at 24 h. One delegated mailbox is the whole footprint.

Your mail runs the gauntlet of the filters that actually block it

Microsoft Defender for Office 365 Google Workspace Mimecast Proofpoint Barracuda Networks Cisco Secure Email Sophos The Spamhaus Project

Receiving tenants run Microsoft 365 (EOP plus Strict on Defender P2), Google Workspace, Mimecast, Proofpoint, Barracuda, Cisco, and Sophos — with Spamhaus checked in the same pass. These are the filters your mail runs, not a customer list.

A · SENDER SIDE Your tenant Microsoft 365 · EXO one delegated mailbox same IPs · same DKIM real mail UUID canary B · THE GAUNTLET receiving tenants we administer Microsoft 365 — EOP default protection preset M365 — Strict · Defender P2 quarantine + Threat Explorer Google Workspace Gmail spam classifier Mimecast · Proofpoint Barracuda · Cisco · Sophos C · VERDICTS read from consoles we own INBOX X-Forefront: SCL:1 · CAT:NONE QUARANTINED CAT:SPM · Strict preset · releasable SILENTLY_DROPPED accepted 250 OK · absent at 24 h REJECTED 554 at the edge · NDR classified D · SENDER-SIDE TELEMETRY NDRs read from the delegated mailbox — 550 5.7.606, 554 fingerprints, recipient custom-rule blocks we catch from real bounces A · SENDER SIDE Your tenant — M365 · EXO one delegated mailbox · UUID canary B · THE GAUNTLET receiving tenants we administer — verdicts read from consoles we own Microsoft 365 — EOP default protection preset → INBOX SCL:1 · CAT:NONE M365 Strict · Defender P2 quarantine + Threat Explorer → QUARANTINED CAT:SPM · releasable Google Workspace Gmail spam classifier SILENTLY_DROPPED accepted 250 OK · absent at 24 h Mimecast · Proofpoint · Barracuda → REJECTED 554 · NDR classified D · SENDER-SIDE TELEMETRY NDRs read from the delegated mailbox: 550 5.7.606 · 554 fingerprints · recipient custom-rule blocks caught from real bounces
Fig. 1 — Probe path. Your real message, sent by your Exchange Online, through filters we administer. Each one hands back a verdict from its own console. Leg D correlates what your side saw against what our side recorded.
§ 01

How it works

GNT · 01/05

Think VirusTotal, for email delivery. Most tools simulate a filter and guess the outcome. We run your mail through the real one and read the verdict off its console.

1.1
tenant mailbox consent scoped app

Delegate one mailbox

You admin-consent a scoped app and hand over a single probe mailbox. An application access policy locks the grant to that one mailbox. Revoke it in one click.

1.2
probe EOP Strict Gmail real filters

Probes run the gauntlet

We compose your real mail and send it from your own Exchange Online — same IPs, same DKIM your users carry. It runs every filter on the wall above, from EOP and Strict Defender to Mimecast and Proofpoint.

1.3
verdict REJECTED · 606 fix: delist form + headers

Verdict plus the fix

Because we own every receiving console, the verdict is the real one, with its reason code. Then the part other tools skip: the exact form to file and what to attach.

● T+15 min · preliminary verdict ● T+24 h · final verdict a greylist 451 is a defer, not a block. We wait it out and never report it as one.
§ 02

The silent drop

GNT · 02/05

Some filters accept your message with a 250 OK, then throw it away once the connection closes. Your trace reads Delivered. Nobody gets a bounce. The recipient never sees a thing.

From either end alone, this failure is invisible. Your logs say success. Their inbox says the message never existed. You need someone standing on both ends of the wire at once, which is exactly what a probe is. We sent it from your tenant. We run the tenant it landed in. Empty mailbox, nothing in quarantine at 24 hours? That is the verdict, and we issue it.

Filters do this on purpose, to deny spammers a signal. It denies you one too, which is why these incidents drag on for weeks.

The failures that hurt most are the ones that never throw an error.

RECEIVING SCOPE PROBE 7F2C…E1 · T+0 → T+24 H T+0 250 OK SILENTLY_DROPPED ECHO: NONE 24 H WINDOW CLOSED — NO NDR · NO FOLDER · NO TRACE
Fig. 2 — one ping, no echo. Accepted at T+0, then gone: no NDR on your side, no folder on ours. Absence of the canary is the evidence. Verdict V-06, confirmed when the 24-hour window closes.
inbox

Delivered to the inbox.

junk

Delivered, foldered as spam. Reason codes attached.

quarantined

Held in admin quarantine with a category: spam, phish, malware.

rejected

Refused at the edge. SMTP code and NDR classified.

deferred

Queued or greylisted. The sender is still retrying. Not a block.

silently_dropped

Accepted, then destroyed after the connection closed. No bounce anywhere. This is the one a trace can’t see.

§ 03

The reason, and the fix

GNT · 03/05

A placement score of 62 doesn’t tell you what to do next Monday. “550 5.7.606, file the Microsoft delist form and attach these headers” does. Every finding ends with the part deliverability tools leave out.

  1. 3.1

    The filter, named

    Which layer took it. EOP edge, content filter, Defender detonation, Gmail classifier. Blame gets an address.

  2. 3.2

    The reason, decoded

    550 5.7.606 is an IP-reputation block, not a content problem. Chase the wrong one and you lose a week.

  3. 3.3

    The escalation playbook

    Which portal or vendor form to file, what to attach, what turnaround to expect, and what to do when the first try gets ignored.

  4. 3.4

    Pool versus you

    M365 shares outbound IP pools, so IP findings are pool-level. We split what you can fix from what belongs to a stranger.

3.5 · Standing monitors

Half of delivery incidents are self-inflicted DNS wounds. We check the boring things first, so the playbook never sends you to a delist form when the bug is in your zone file. On the Direct plan these run continuously.

MX SPF · 10-lookup limit DKIM selector probe DMARC policy DMARC rua ingestion MTA-STS TLS-RPT Spamhaus DQS DBL / SURBL Google Postmaster
A finding, as delivered Report excerpt 
finding 03 · probe 7f2c…e1
verdict:  rejected @ Microsoft EOP edge
reason:   550 5.7.606 — sending IP on
          Microsoft block list
action:   submit sender.office.com delist
          (attach NDR + probe ID); ETA 24–48 h;
          if silent after 72 h → escalation
          path 2, documented below

Written to be forwarded, unedited, to a vendor or a recipient’s IT contact.

3.6 · The alert, before the incident

On monitoring, findings don’t wait for a bounce. When a leading indicator trips, the agent posts to your Teams channel while probes still land — with the fix already drafted.

Fig. 3 — caught at the listing, not at the bounce. The DBL sweep flags the listing twelve minutes in. Probes confirm nothing has failed yet; the delist draft is attached. Your users never see this one.
§ 04

Plans

GNT · 04/05

Two plans. One if you run mail for a single company, one if you run it for many. Talk to us and we scope it to your situation.

Item 04-A▸ you’re here mid-incident

Direct

For one company running its own mail.

  • Incident diagnostic: full probe series from your tenant across every filter
  • Continuous monitoring once the fire is out, with alerts when a verdict changes
  • Both-ends telemetry: your NDRs correlated against our console verdicts
  • Escalation playbooks per filter and reason code
Contact sales
Item 04-B

MSP

For teams running mail for many companies.

  • Multi-tenant: run diagnostics across every client domain you manage
  • Per-domain, pay-as-you-go
  • One console, verdict history per tenant
  • Alerts routed per client, to the channels you already watch
Contact sales

We scope every engagement to your tenant before any work starts. Nothing gets installed, your MX stays untouched, and the grant never reaches past one mailbox.

§ 05

Contact sales

GNT · 05/05

Tell us what’s failing. Recipient domain, and any NDR text you have, codes and all. The more of the bounce we can read, the faster the answer.

We respond within one business day.

Contact sales GNT · 05