Email Delivery Failures, NDRs, Junk Misclassification — SPF/DKIM/DMARC, Blacklist, Connector, and Transport Rule Triage (Exchange / Exchange Online)

Indicators

• Sender receives an NDR with SMTP status code 5.x.x (permanent failure) or 4.x.x (transient failure)
• Recipients report messages arriving hours or days late
• Legitimate outbound email lands in recipients' external junk/spam folders (e.g., Gmail, Outlook.com)
• Inbound email from known senders silently moved to the Junk Email folder with no user action
• Mail queue backlog visible in Exchange Queue Viewer or Get-Queue cmdlet — MessageCount climbing, Status not 'Ready'
• Exchange Application event log contains errors from Source = 'MSExchangeTransport'
• Microsoft 365 Admin Center message trace shows status 'Failed' or 'GettingStatus' for affected messages

Likely causes

• Missing, incorrect, or misaligned SPF TXT record — sending IP not listed, causing receiving servers to reject or junk messages
• DKIM signing not configured or DKIM signature failing validation at the recipient mail server
• DMARC policy set to p=reject or p=quarantine with SPF/DKIM both failing alignment, causing mass rejection
• Sending IP address listed on one or more public DNS block lists (DNSBLs/RBLs) due to spam relay or compromised account
• Missing or incorrect MX records preventing inbound mail delivery or causing routing loops
• Send or Receive connector misconfiguration on Exchange Server — wrong address space, smart host, or TLS requirement mismatch
• Anti-spam policy (EOP or third-party) incorrectly classifying messages due to content scoring, header anomalies, or sender reputation
• Transport rule inadvertently redirecting, deleting, or rejecting messages without generating an NDR
• Expired or untrusted TLS certificate on SMTP connector causing opportunistic TLS negotiation failures
• Exchange mailbox database or transport service outage causing queue buildup and delivery deferral

Diagnostic steps

1. Run a message trace to identify exactly where delivery failed. In Microsoft 365: Exchange Admin Center > Mail Flow > Message Trace. In on-premises Exchange, run: Get-MessageTrackingLog -Sender 'sender@domain.com' -ResultSize 100 | Select Timestamp, EventId, Source, MessageSubject, Recipients, RecipientStatus
   Pinpoints the delivery stage at which the message failed (submission, categorisation, routing, delivery) and surfaces SMTP error codes or rejection reasons.
2. Check the outbound sending IP against public DNS block lists: navigate to https://mxtoolbox.com/blacklists.aspx or https://multirbl.valli.org and enter the public IP of the sending mail server. Also check Microsoft SNDS at https://sendersupport.olc.protection.outlook.com/snds/
   Determines whether the sending IP is blacklisted, which causes external recipients to reject or junk messages regardless of content or authentication.
3. Validate SPF, DKIM, and DMARC DNS records for the sending domain. Run: nslookup -type=TXT yourdomain.com (SPF and DMARC) and nslookup -type=TXT selector._domainkey.yourdomain.com (DKIM). Or via PowerShell: Resolve-DnsName -Name yourdomain.com -Type TXT; Resolve-DnsName -Name _dmarc.yourdomain.com -Type TXT; Resolve-DnsName -Name 'selector._domainkey.yourdomain.com' -Type TXT
   Identifies missing or broken email authentication records that cause receiving servers to reject or junk messages from the domain.
4. Review Exchange mail queue status on-premises: Get-Queue | Where-Object {$_.Status -ne 'Ready'} | Select Identity, Status, MessageCount, NextHopDomain, LastError
   Identifies stuck or growing queues and surfaces the last SMTP error encountered when attempting delivery, indicating connector or DNS routing problems.
5. Inspect transport rules for any that may be silently affecting the affected messages: Get-TransportRule | Select Name, Priority, State, Description | Sort-Object Priority — then review rule conditions for sender/recipient/content matches that could redirect, delete, or reject messages.
   Rules acting on the affected sender, recipient, or message content may be silently discarding or rerouting messages without generating an NDR.
6. Inspect the raw NDR or bounce message headers. Identify the SMTP diagnostic code (e.g., 550 5.7.1, 5.7.23, 5.7.509, 451 4.7.0) and the reporting MTA hostname. Cross-reference the extended status code against Microsoft's NDR reference: https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/non-delivery-reports-in-exchange-online/non-delivery-reports-in-exchange-online
   The SMTP status code and extended status code directly identify the rejection reason — policy, relay denied, reputation, SPF/DKIM/DMARC authentication failure — and determine the correct resolution path.
7. Check the Application event log on Exchange servers for transport service errors: Get-EventLog -LogName Application -Source MSExchangeTransport -EntryType Error -Newest 50 | Select TimeGenerated, EventID, Message — or filter Event Viewer on Source = 'MSExchangeTransport'.
   Surfaces Exchange transport service-level errors indicating connector failures, TLS certificate problems, or service crashes contributing to delivery failures.
8. Review Send and Receive connector configuration: Get-SendConnector | Select Name, AddressSpaces, SmartHosts, RequireTLS, TlsAuthLevel, Enabled and Get-ReceiveConnector | Select Name, Bindings, RemoteIPRanges, AuthMechanism, RequireTLS — compare against expected topology.
   Identifies connector misconfiguration such as incorrect address spaces, missing smart host entries, or TLS requirement mismatches that cause delivery failures.

Resolution path

• If SPF is missing or incorrect: Publish or correct a TXT record in DNS in the format: v=spf1 include:yourmailprovider.com ip4:x.x.x.x ~all — ensuring all legitimate sending IPs and third-party services are included. Allow up to 48 hours for DNS propagation. Validate with: Resolve-DnsName -Name yourdomain.com -Type TXT
• If DKIM is not configured on Exchange Online: Enable DKIM signing in Microsoft 365 Defender portal > Email & Collaboration > Policies & Rules > Threat Policies > DKIM. Publish the two CNAME records provided by Microsoft into your public DNS zone. Validate with: Resolve-DnsName -Name 'selector1._domainkey.yourdomain.com' -Type CNAME
• If DMARC is missing: Publish a DMARC TXT record at _dmarc.yourdomain.com. Start with monitoring policy: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com — escalate to p=quarantine then p=reject only after confirming SPF and DKIM pass reliably in aggregate reports.
• If sending IP is blacklisted: Submit delisting requests through each DNSBL provider's portal (Spamhaus: https://www.spamhaus.org/lookup/, Barracuda: https://www.barracudacentral.org/rbl/removal-request, Microsoft JMRP/SNDS: https://sendersupport.olc.protection.outlook.com/snds/). Investigate and remediate the root cause (compromised account, spam relay, open relay) before requesting delisting.
• If a Send or Receive connector is misconfigured: Review with Get-SendConnector and Get-ReceiveConnector. Correct address spaces, smart host entries, or TLS settings using Set-SendConnector or Set-ReceiveConnector as appropriate, then restart: Restart-Service MSExchangeTransport
• If anti-spam policy is over-filtering (EOP): In Microsoft 365 Defender > Email & Collaboration > Policies & Rules > Threat Policies > Anti-Spam, add the sender domain or IP to the allowed senders list as a temporary measure. Tune SCL thresholds or create a scoped allow-list entry. For on-premises Exchange, review the Content Filter Agent configuration in EMS.
• If a transport rule is incorrectly affecting messages: Disable the suspected rule with: Disable-TransportRule -Identity 'Rule Name' — verify delivery resumes, then modify the rule conditions or actions to correct the logic before re-enabling with: Enable-TransportRule -Identity 'Rule Name'

Prevention

• Publish and maintain accurate SPF, DKIM, and DMARC records for all sending domains; enforce DMARC at p=quarantine or p=reject only after confirming SPF and DKIM pass reliably to prevent spoofing and improve deliverability
• Monitor outbound sending IP reputation proactively using Microsoft SNDS, Spamhaus SBL feeds, or an automated RBL monitoring service — configure alerts on listings before they cause customer-visible delivery failures
• Enable multi-factor authentication on all mailboxes and audit sign-in logs to prevent account compromise, which is a primary cause of IP blacklisting due to spam relay activity
• Configure Exchange or EOP alert policies for mail flow anomalies such as queue depth thresholds, unusually high bounce rates, or spikes in outbound message volume so failures are detected before users report them
• Periodically audit transport rules and anti-spam policies to ensure they remain accurate as organisational email patterns change; document all rules with clear descriptions and owners in the rule Description field

Tools

• Exchange Management Shell / Exchange Online PowerShell — queue inspection, connector review, transport rule management, message tracking
• Microsoft 365 Admin Center Message Trace — end-to-end delivery status and SMTP error codes for Exchange Online
• MXToolbox (mxtoolbox.com) — SPF, DKIM, DMARC, MX, and blacklist lookups
• Microsoft SNDS (sendersupport.olc.protection.outlook.com/snds/) — outbound IP reputation and complaint data
• Microsoft Remote Connectivity Analyzer (testconnectivity.microsoft.com) — SMTP, MX, and connector testing
• mail-tester.com — outbound email authentication scoring and spam assessment
• nslookup / Resolve-DnsName — DNS record inspection for MX, SPF, DKIM, DMARC TXT records
• Event Viewer (Application log, MSExchangeTransport source) — transport service error review

References

• Fix email delivery issues for error code 5.7.1 in Exchange Online
• Non-delivery reports (NDRs) in Exchange Online
• Set up SPF to help prevent spoofing
• Use DKIM to validate outbound email from your custom domain
• Use DMARC to validate email
• Queues and messages in queues in Exchange Server
• Microsoft SNDS (Smart Network Data Services) — sending IP reputation