"My email did not send" covers two very different problems. Either the message never left Outlook and is sitting in the Outbox, or it left, was rejected somewhere, and came back as a non-delivery report. The NDR looks like noise, but it contains a code that tells you exactly who to call.
This post is about reading that code, checking the sending domain's DNS records when the code points at you, and using message trace in Exchange Online to see what actually happened.
Stuck in the Outbox versus bounced
If the message is in the Outbox, the mail server never saw it. That is a client problem: Outlook is offline or disconnected, the attachment is over the size limit, or the message is held by an add-in or a delayed delivery rule. Check the status bar, remove the attachment and try again, and see our post on Outlook connection problems if it is disconnected.
If the user received a message from a postmaster or mailer-daemon address, the mail was sent and rejected. Open that message and find the line that begins with a number like 550 5.1.1. The first digit tells you whether it is permanent (5) or temporary (4). The three-part code after it is the enhanced status code, and that is the part that matters.
Read the NDR: the code says who to call
These are the codes you will see most in Microsoft 365 environments and what they usually mean. The wording after the code matters as much as the number, so read the whole line.
- 5.1.1 or 5.1.10 Recipient not found: the address is wrong or the mailbox no longer exists. Check the spelling, then ask the recipient's organisation.
- 5.4.1 Recipient address rejected: Access denied: the recipient's Exchange Online tenant has Directory-Based Edge Blocking and the address does not exist there. Their problem, unless it is your own domain.
- 5.7.1 Delivery not authorized or Relay access denied: the sender is not allowed to send to that group or through that server. For an internal group, check who is allowed to send to it in its properties.
- 5.7.23 or 5.7.26 SPF or DMARC failure: the receiving side does not trust your domain's records. That is your problem, and the next section is the fix.
- 5.2.2 Mailbox full: the recipient's quota. Their problem.
- 5.7.750 or a Restricted entity notice: your tenant or user was blocked for sending spam. Check Defender > Review > Restricted entities.
Check SPF, DKIM and DMARC
When the code says the recipient did not trust your domain, look at the three DNS records that vouch for it. SPF is a TXT record on the domain that lists which servers may send for it, and it must include Microsoft's servers plus anything else that sends as you, such as a ticketing system, a marketing tool or a copier. It also has a lookup limit, and an SPF record with too many includes fails silently. DKIM is a signature; in Exchange Online it needs two CNAME records and a toggle under Defender > Email & collaboration > Policies & rules > Threat policies > Email authentication settings. DMARC is a TXT record at _dmarc.yourdomain that tells receivers what to do when SPF and DKIM fail.
Check all three with a public lookup tool or with nslookup. The most common findings are an SPF record that was never updated when a new sending service was added, and DKIM that was never enabled. A DMARC record set to p=reject before SPF and DKIM were right causes exactly the bounces users complain about.
nslookup -type=txt _dmarc.yourdomain.com
Get-DkimSigningConfig -Identity yourdomain.com | Format-List Enabled, Selector1CNAME, Selector2CNAMERun a message trace
When the user has no NDR but the recipient says nothing arrived, message trace tells you what Exchange Online did with it. In the Exchange admin center go to Mail flow > Message trace and search by sender, recipient and a date range. The result shows whether the message was delivered, quarantined, filtered as spam, or failed with a reason. For the last few days the trace is immediate; older messages need an extended trace that arrives as a report.
The same search from PowerShell is faster when you do it often. Look at the Status column. Delivered means it reached the recipient's server or mailbox and the problem is on their side, usually a junk folder or a rule. FilteredAsSpam means your own tenant stopped it, and the quarantine page explains why.
Get-MessageTrace -SenderAddress jsmith@yourdomain.com -StartDate (Get-Date).AddDays(-2) -EndDate (Get-Date) | Select-Object Received, RecipientAddress, Status, SubjectClient-side sending problems
A few sending problems are purely local. A message stuck in the Outbox with a large attachment blocks everything behind it; delete or edit it and the rest goes. A message being sent from a shared mailbox without Send As rights bounces internally with a permission error. An inbox rule or a defer delivery setting holds mail in the Outbox on purpose and users forget they set it. RackLedge can review your mail flow and DNS records if you want a second opinion.
Frequently asked questions
The bounce says the recipient does not exist, but they emailed me yesterday. What now?
Reply directly to their message rather than typing the address, and check for a typo or an old cached autocomplete entry. If it still bounces, their mailbox may have been moved or removed and their IT needs to fix it.
Do we need DMARC if SPF and DKIM are set up?
Yes. Many receivers now expect it, and it is the record that tells them what to do with mail that fails the other two. Start with p=none to monitor, then move to quarantine and reject once the reports show all legitimate mail passing.
Takeaway
Separate stuck from bounced, then read the enhanced status code. Codes in the 5.1 and 5.2 range are usually the recipient's problem, 5.7 codes about SPF, DKIM or DMARC are yours, and a message trace settles anything without a bounce. Keep SPF, DKIM and DMARC current every time a new system sends as your domain and most of these tickets never appear.