How to fix issues where some emails are not being received, even though the domain is no longer on the blacklist.

Question

How to fix issues where some emails are not being received, even though the domain is no longer on the blacklist.

Administrator - IT Infra 0

My mail is currently failing to receive inbound emails from a specific vendor (vendor1.com), while emails from all other external vendors and clients arrive without issues.

The sender domain was previously blacklisted/blocked, but it has since been verified and removed from our internal blocklists, spam filters, and major public DNSBL/RBL databases. Despite confirming the domain is clean and no longer listed as blocked, emails from vendor1.com still do not reach user inboxes or the junk/quarantine folders, and our inbound mail logs show no successful delivery handshakes from their mail exchange servers.

0 comments

2 answers

Your answer

Answer 1

Hello,
As the forum’s AI recommended, checking the sender’s non-delivery report (NDR) and SMTP delivery logs is the right starting point. However, the information provided does not yet establish where delivery is failing.

Could you confirm whether your mailboxes are hosted in Microsoft 365/Exchange Online and whether incoming mail passes through a third-party email security gateway first? Also, are the “inbound logs” you checked Exchange Online message trace results or logs from another mail server/gateway?

If you use Exchange Online, please work with your email administrator and the vendor’s mail administrator on these checks:

Capture one fresh delivery attempt. Ask the vendor to send a new test message to an affected recipient and record the time and time zone. Their administrator should check the actual outbound sending IP, destination mail server, and SMTP response, or confirm whether the message remains queued. If there is no NDR, ask them to check the outbound delivery logs for that test.
Trace the same message on your side. In the Exchange admin center, go to Mail flow > Message trace. Search using the recipient and the test’s time range, select the matching time zone, and include all delivery statuses. Open any matching result to inspect its events. See Microsoft’s message trace instructions. Microsoft states that messages typically take 5–10 minutes to appear in trace data. Also, connection-filter events, such as blocked IP addresses, are not traceable. Therefore, no matching trace result alone does not prove that the sender never contacted Microsoft 365. See Message trace FAQ. If you use an upstream email gateway, have its administrator check receipt and onward delivery for the same test.
Choose the fix based on the actual error. Microsoft maintains its own sending-IP blocklist, so a clean public blocklist result does not rule out a Microsoft IP block. However, an IP block has not been confirmed in this case. If the NDR contains 550 5.7.606-649 with “banned sending IP,” the vendor should follow Microsoft’s IP delisting procedure. For 5.7.511, Microsoft instead instructs the sender to contact delist@microsoft.com with the full NDR code and sending IP. These procedures apply only when the corresponding error is present. See Microsoft’s delisting instructions.

I recommend identifying the delivery failure before making further allow-list or authentication changes.

Please confirm your mail hosting/gateway setup and share the SMTP error code and accompanying error text, if available. Remove email addresses, IP addresses, message IDs, and other identifying details before posting publicly.

Answer 2

If inbound mail from only vendor1.com is missing, and nothing appears in inbox, junk, quarantine, or inbound logs, the most likely cause is that the sender’s messages are being rejected or restricted before they reach the mailbox service.

Use this path:

Ask the sender to check whether they receive a non-delivery report (NDR).
- The key detail is the SMTP error code returned to them.
- If the NDR shows 550 5.7.606-649 Access denied, banned sending IP, the sender should use the Office 365 Anti-Spam IP Delist Portal.
- They must enter the email address that received the NDR and the sending IP address shown in the error, then complete verification and select Delist IP.
If the sender receives 5.7.511, do not use the delist portal for that case.
- That error requires additional investigation on the sending traffic.
If the sender receives 451 4.7.550 Access denied, please try again later, Microsoft 365 has temporarily throttled traffic from the sender IP because suspicious activity was detected.
- In that case, the restriction is temporary while the traffic is evaluated.
If the sender’s NDR indicates authentication failure such as SPF problems, the fix is on the sender side.
- A sender-side SPF failure can cause Microsoft to reject the message before it reaches the mailbox, which matches the symptom where nothing appears in mailbox folders.
If the sender confirms no NDR but mail still never reaches Microsoft 365, verify whether the issue is actually with mail flow to the tenant rather than mailbox filtering.
- Since inbound logs show no successful delivery handshake from their mail servers, focus on sender-side delivery status and SMTP rejection details first, not Outlook client settings or mailbox junk settings.
If the sender was previously blocked and has now been delisted, allow time for the restriction to clear.
- Results can vary, and removal can take up to 24 hours or longer.
If mail is being treated as a false positive after it starts arriving, check tenant anti-spam handling.
- For legitimate partner mail blocked by policy, review whether the sender domain is in the Tenant Allow/Block List and remove the block entry or create an allow entry for the domain.
- Allow 15–30 minutes for anti-spam policy changes and up to one hour for mail flow rule changes.

This scenario does not point to an Outlook for Windows client issue. It points to sender-side rejection, Microsoft 365 edge restriction, or tenant mail-flow/anti-spam handling before mailbox delivery.