Ad Code

Responsive Advertisement

How to debug code when a user does not receive email, not showing on epurify firewall and MS online exchange

Khabza Mkhize August 21, 2025

How to debug code when a user does not receive email,


Here’s a practical, fast triage/runbook you can follow when a user says “I didn’t get the email,” and you can’t see it in e-Purifier or Exchange Online.

0) First 60-seconds checks (scoping)

  • Is it one sender or everyone? One domain or many?

  • Exact recipient address and timestamp (local: Africa/Johannesburg).

  • Ask the sender for any NDR/bounce text or an SMTP transcript (this often tells you what blocked it and where). Common bounces include Spamhaus / policy blocks. Reddit

1) DNS/MX layer — prove where mail is supposed to go

If a message is missing from both e-Purifier and Exchange Online, it most often never reached your infrastructure. Start with MX:

  • Run:
    nslookup -type=mx yourdomain.tld
    Confirm MX points to your e-Purifier cloud/gateway (whatever FQDN they gave you). If your MX points elsewhere (or to old records), mail will bypass your stack entirely.
    If you’re unsure, Microsoft’s Remote Connectivity Analyzer – Inbound SMTP will validate DNS/MX and attempt delivery end-to-end. testconnectivity.microsoft.comMicrosoft Learn+1

  • If you recently changed DNS, check TTLs/propagation and (optionally) run the Exchange DNS test in ExRCA to catch common inbound issues. Microsoft Learn

Tip: If you use DNSSEC/DANE, ensure records are valid; misconfig there can cause silent failures before your gateway. Office 365 Reports

2) Edge/gateway (e-Purifier) layer — prove connection & recipient validation

e-Purifier is a cloud email security service (widely used in SA) that sits in front of Microsoft 365. Confirm it’s actually receiving mail for your domain:

  • Portal logs/quarantine: expand the time window and search by external sender and internal recipient. If nothing at all appears, the connection probably never reached e-Purifier (MX wrong, sender unable to connect, IP blocked upstream), or the service is not associated with that domain. Product overviews: e-Purifier (Securicom). thesmallbusinesssite.co.zaasg.africa.comE Purifier

  • Recipient/Directory sync: if e-Purifier does recipient validation and your directory sync is broken/out-of-date, it can 550-reject unknown recipients before Exchange sees it. (You’d see these rejections in the sender’s bounce.)

  • Allow/Block/TLS policies: check if you enforce TLS or source IP allow-lists at e-Purifier that might reject the sender prior to logging to downstream systems.

  • Live SMTP probe (from a safe admin box):
    openssl s_client -starttls smtp -connect <your MX host>:25
    then EHLO test, MAIL FROM:<you@you>, RCPT TO:<victim@yourdomain>.
    You should get a 250 for RCPT. Any 550/5xx here is gold for root cause.

3) Microsoft 365 / Exchange Online — prove it never arrived (or where it went)

If the message didn’t hit Exchange, message tracing won’t show it. Still, run a proper trace to confirm:

  • EAC > Mail flow > Message trace: set a wide range and search by recipient/sender. If nothing returns, Exchange Online never saw it. Microsoft’s guidance + “Troubleshoot message delivery” wizard are helpful here. Microsoft Learn+1

  • If you do see it, open Trace details to see whether it was delivered, junked, dropped, or redirected by a rule/quarantine. (Also check Defender for Office 365 Explorer/Real-time detections if licensed.) Microsoft Learn

  • For faster triage on failed deliveries, filter by Status = Failed in the trace workflow. AdminDroid

4) Sender-side realities — many “invisible” failures happen there

  • Ask the sender for the exact NDR. Common case: their IP is on an RBL (e.g., Spamhaus) and gets rejected before your stack ever logs it. That NDR will usually show 550 5.7.1 with a blacklist reference. Reddit

  • Verify the sender actually attempted delivery to the correct MX hostname and didn’t hit TLS/cert mismatches or size limits at their gateway.

5) Quick decision tree

A. Not in e-Purifier and not in Exchange traces →
Likely pre-edge failure:

  • MX wrong/outdated or domain not onboarded in e-Purifier → fix DNS/onboarding. Validate with Inbound SMTP test (ExRCA). testconnectivity.microsoft.comMicrosoft Learn

  • Sender blocked by public RBL or can’t negotiate TLS to your MX → prove via sender NDR / your live SMTP probe. Reddit

  • e-Purifier recipient validation rejecting due to stale directory sync → fix sync / disable strict validation temporarily (if your policy allows).

B. Present in e-Purifier, missing in Exchange traces →
Handoff failure from gateway to Microsoft:

  • Check e-Purifier delivery host target (should be your tenant’s <domain-key>.mail.protection.outlook.com).

  • Check M365 inbound connector (From your partner organization/e-Purifier) and routing rules. Validate with Microsoft’s Connector validation tests. Microsoft Learn

C. Present in Exchange trace but not in user’s Inbox →
Mailbox/policy issue:

  • Delivered to Junk, Quarantine, or hit a Transport rule.

  • Check Inbox rules, forwarding, hidden delegates, and Recoverable Items if needed. (Trace details will show the path.) Microsoft Learn

6) Minimal “prove it” commands & tools

DNS/MX

bash
nslookup -type=mx yourdomain.tld
nslookup -type=txt yourdomain.tld      # SPF/DMARC sanity

SMTP Live Probe (edge)

bash
openssl s_client -starttls smtp -connect <mx.host.name>:25
# Then EHLO / MAIL FROM / RCPT TO manually

(Use ExRCA “Inbound SMTP Email” if you prefer a guided test with a report.) testconnectivity.microsoft.comMicrosoft Learn

Exchange Online PowerShell (optional)

powershell
Get-MessageTrace -RecipientAddress victim@yourdomain.tld -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date)
# If found:
Get-MessageTraceDetail -MessageTraceId <IdFromAbove> -RecipientAddress victim@yourdomain.tld

(Or run the Troubleshoot message delivery workflow in M365 Admin.) Microsoft Learn

7) Common silent killers to check once

  • MX still points to old vendor after migration to e-Purifier/M365.

  • Partner TLS mismatch (you require TLS; they can’t negotiate). Use ExRCA to confirm. testconnectivity.microsoft.com

  • Directory sync lag → recipient seen as invalid at e-Purifier.

  • Oversized message rejected at edge before content filter logs.

  • DNSSEC/DANE misconfig creating pre-connection failures. Office 365 Reports

Khabza Mkhize

Posted by Khabza Mkhize

Close Menu