ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Email Security • Microsoft 365 NDR • Defender XDR

The Recipient Was Unrecognised

The email looked like a payment receipt.

The Office-style branding looked familiar. The amount looked believable. The wording was designed to create panic.

But when the message was replied to, Microsoft 365 returned a bounce message. Agent Foskett wanted to know why.

Discuss your email security Back to briefings
Agent Foskett Microsoft 365 NDR fake payment receipt investigation
Briefing summary

A suspicious payment receipt attempted to create urgency. The message appeared convincing enough to worry a user, but a Microsoft 365 Non-Delivery Report revealed the receiving server rejected the reply because the recipient was unrecognised.

Subject = Payment Receipt
Amount = USD403.22
Status = 550 5.0.350
Error = recipient unrecognised

The email wanted a reaction

The message was not designed to be carefully analysed. It was designed to make someone panic.
The subject looked financial The subject referenced a payment receipt, a multi-year package plan and a specific order total. That is enough to make many users stop and worry.
The branding looked familiar Scam emails often copy familiar logos, layouts and colour schemes because trust can be borrowed visually before the user reads the details.
The wording created urgency Unexpected payments, declined transactions and subscription renewals are common social engineering triggers because they invite a fast emotional response.

The reply changed the investigation

Instead of clicking a link or calling a support number, the email was replied to. That produced the clue.
Microsoft 365 attempted delivery The reply left Microsoft 365 and was handed toward the receiving mail system. The delivery attempt was real.
The remote server rejected it The receiving mail server returned 550 5.0.350 and reported that the recipient was unrecognised.
The mailbox did not exist A legitimate billing mailbox should usually be able to receive a reply. In this case, the mailbox behind the message could not.

The KQL investigation

Agent Foskett starts by finding the original suspicious email in Microsoft Defender XDR.
fake-payment-receipt-investigation.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
EmailEvents
| where Timestamp > ago(30d)
| where Subject contains "Payment Receipt"
    or Subject contains "USD403.22"
| project
    Timestamp,
    SenderFromAddress,
    RecipientEmailAddress,
    Subject,
    ThreatTypes,
    DeliveryAction,
    DeliveryLocation

What the bounce message revealed

The Non-Delivery Report was not just a failed message. It was evidence.
550 5.0.350 The message was rejected by the remote mail server. Microsoft 365 could not complete delivery to the outside recipient.
Recipient unrecognised The remote server did not recognise the mailbox. That strongly suggested the reply address was invalid, abandoned or never intended to receive responses.
The receipt story failed If the payment receipt was real, the business process behind it should have made sense. The failed reply told a different story.

Was it part of a wider campaign?

A single email might be noise. Repeated subjects, senders or amounts can reveal a campaign.
payment-receipt-campaign-scope.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
EmailEvents
| where Timestamp > ago(30d)
| where Subject has_any ("Payment Receipt", "4Years Package Plan", "USD403.22")
| summarize
    TotalMessages = count(),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp)
    by SenderFromAddress, SenderIPv4, SenderIPv6

Checking authentication evidence

A suspicious email can look professional, and it may still pass some authentication checks.
SPF SPF helps identify whether the sending server was permitted to send for the envelope domain, but it does not prove the message is safe.
DKIM DKIM can show that a message was signed by a domain, but a signed message can still be part of a scam campaign.
DMARC and composite authentication Authentication results help explain technical trust, but defenders still need to investigate sender behaviour, content and user impact.

Authentication KQL

Agent Foskett checks whether the authentication story supports or contradicts the email story.
email-authentication-review.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
EmailEvents
| where Timestamp > ago(30d)
| where Subject contains "Payment Receipt"
| project
    Timestamp,
    SenderFromAddress,
    SenderMailFromAddress,
    RecipientEmailAddress,
    EmailAuthenticationResults,
    AuthenticationDetails

Checking for user impact

The next question is whether anyone clicked, opened, downloaded or interacted with the message.
Did anyone click? If a link was present, UrlClickEvents can help identify whether the email became a user interaction event.
Did anyone call? Some payment scams are not link-based. They try to move the victim into a phone call, remote access session or fake refund process.
Did anything happen next? Follow-up activity may include suspicious sign-ins, browser activity, endpoint network connections or new inbox rules.

Click investigation KQL

If links were involved, URL telemetry helps determine whether the lure worked.
url-click-impact-review.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
UrlClickEvents
| where Timestamp > ago(7d)
| where Url has_any ("payment", "receipt", "invoice", "support")
| project
    Timestamp,
    AccountUpn,
    Url,
    ActionType,
    Workload

Why this matters

A bounce message can be easy to dismiss. In this case, it became one of the strongest clues.
Scams exploit trust Familiar branding and official-looking payment language can bypass common sense when the recipient is busy or worried.
NDRs are evidence Non-Delivery Reports can reveal invalid mailboxes, remote policy blocks, routing problems and suspicious sender infrastructure.
Behaviour beats appearance The question is not only whether an email looks real. The better question is whether the email behaviour makes sense.

Agent Foskett moment

The original email was designed to look convincing. The reply failure told the real story.
The receipt was the lure The payment amount, subscription wording and branding were there to trigger a reaction before the recipient slowed down.
The NDR was the clue The failed reply showed that the mailbox behind the message could not receive email. That changed the direction of the investigation.
The mailbox told the story The recipient was unrecognised. The message had the appearance of a transaction, but the infrastructure did not support the claim.

Questions every analyst should ask

When a suspicious payment receipt appears, slow the investigation down and test the story.
Who actually sent it? Compare SenderFromAddress, SenderMailFromAddress, authentication results and the visible branding used in the message.
Can the sender receive replies? A fake billing mailbox, abandoned mailbox or unrecognized recipient can expose a scam that looked convincing at first glance.
What did the user do next? Check clicks, sign-ins, endpoint activity, mailbox rules and follow-up communication if the message triggered any interaction.

Related investigations

The Email Passed SPF, DKIM and DMARC — Why Did Composite Authentication Still Fail? Understand why passing authentication checks does not always mean a message deserves trust. Read more →
The Email Was Delivered — But Nobody Ever Saw It Learn why delivered does not always mean the message landed in the user's inbox. Read more →
Investigating EmailAuthenticationResults in Microsoft Defender XDR Understand the authentication evidence stored in Defender email telemetry. Read more →
SenderFrom vs SenderMailFrom Compare visible sender identity with envelope sender evidence during email investigations. Read more →
AuthenticationDetails Explained Learn how authentication details help explain why a message passed, failed or deserved further review. Read more →
The Disney Email Wasn't From Disney Investigate sender identity, brand impersonation and suspicious email behaviour using Defender evidence. Read more →
The payment receipt looked real.
But the mailbox did not. The Non-Delivery Report became the clue that exposed the story.
Contact GEMXIT

Final thought

A convincing email is not the same thing as a legitimate email.
At GEMXIT We help organisations investigate Microsoft Defender XDR, email security, phishing, spoofing, Microsoft 365 security and practical threat hunting. If you want to understand how this applies to your environment, see our Microsoft Security services.
Agent Foskett mindset Do not stop at the logo. Do not stop at the subject. Investigate the behaviour, the telemetry and the story behind the message.

The receipt was the lure. The bounce message was the clue. Explore related investigations including Composite Authentication, Investigating EmailAuthenticationResults, and DeliveryLocation investigations.

Develop IT. Protect IT. GEMXIT PTY LTD | GEMXIT UK LTD
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026

Microsoft 365 Non-Delivery Report Investigation

A Microsoft 365 Non-Delivery Report can help security analysts investigate suspicious email activity, failed replies, invalid recipient addresses, remote server rejections and phishing infrastructure.

550 5.0.350 Recipient Unrecognized

The error 550 5.0.350 recipient unrecognized indicates that the receiving mail server rejected the message because the recipient mailbox could not be recognized. In phishing investigations, this can expose suspicious or abandoned sender infrastructure.

Fake Payment Receipt Email Investigation

Fake payment receipt scams use familiar branding, unexpected charges and urgent language to make users react quickly. Microsoft Defender XDR telemetry, EmailEvents, EmailAuthenticationResults and UrlClickEvents can help defenders investigate the message and determine user impact.