Azure Communication Services Email remains OutForDelivery and never reaches recipient mail server

Hi @Pim Vrolijks

Thank you for reaching us regarding the issue.

According to the ACS Email logs documentation:

• Message-level events (no RecipientId) use the statuses Queued, OutForDelivery, or Dropped.
• Recipient-level events (with RecipientId) and any SMTP / enhanced SMTP codes appear only for terminal outcomes: Delivered, Failed, Bounced, Suppressed, Quarantined, or FilteredSpam.

OutForDelivery simply means ACS accepted the message and handed it off. The absence of further recipient-level events indicates that no terminal delivery report was generated.

Recommended actions (directly from Microsoft documentation)

1. Fully re-verify the custom domain In the Email Communication Services resource → Provision Domains, confirm that Domain, SPF, DKIM, and DKIM2 all show Verified.
   • SPF must use the hard-fail mechanism (-all).
   • Validate the published records externally with nslookup (or equivalent).
2. Publish an MX record for the custom domain Microsoft explicitly recommends an MX record even though ACS is outbound-only: “Although Azure Communication Service only supports outbound email messages, we recommend that you set up an MX record to improve the reputation of your sender domain. An email message from a custom domain that does not have an MX record can be labeled as spam by the email provider of the addressee.” Point the MX record at a valid mail server that can accept messages for the domain (or at least resolves cleanly). Verify with: nslookup -q=MX <your-custom-domain> 8.8.8.8
3. Publish a DMARC record lists DMARC configuration as an admin responsibility for verified sender domains and recommends:
   • Policy p=reject where possible (otherwise p=quarantine).
   • Inclusion of a rua tag pointing to a monitored mailbox. Azure-managed domains ship with p=reject; custom domains do not inherit this automatically.
4. Confirm the domain is connected On the Communication Services resource > Email > Domains, verify the custom domain is listed as connected and that the data locations of the two resources match.
5. Continue monitoring with the available diagnostics
   • Query ACSEmailStatusUpdateOperational by CorrelationId (Message ID) for both message-level and any late recipient-level rows.
   • Subscribe to Event Grid Microsoft.Communication.EmailDeliveryReportReceived events.
   • Use the portal Try Email feature and the Email Insights blade.

Reference:
https://learn.microsoft.com/en-us/azure/communication-services/concepts/email/email-domain-configuration-troubleshooting
https://learn.microsoft.com/en-us/azure/communication-services/concepts/email/email-authentication-best-practice

Kindly let us know if the above comment helps or you need further assistance on this issue.

Please "accept" if the information helped you. This will help us and others in the community as well.

First — OutForDelivery is a message-level status, not a delivery outcome. The email logs doc splits the two: message-level events have no RecipientId and carry Dropped, OutForDelivery or Queued. Recipient-level events carry a RecipientId and the actual result — Delivered, Failed, Bounced, Quarantined, FilteredSpam, Suppressed or Expanded.

So what you have is the send operation handing off, with no per-recipient outcome recorded. The missing SMTP status code fits too — the doc describes it as the code "returned from the recipient email server," and no code was captured, which lines up with what the recipient's provider told you.

Second — the gap between the two tables is most likely the diagnostic setting rather than anything about the message. They're separate log categories and each has to be ticked individually:

"Under diagnostic setting name, select Email Service Delivery Status Update Logs, Email Service Send Mail logs, and Email Service User Engagement Logs to enable email logs."

The three email categories in the diagnostic setting — each has to be ticked individually:

If only Delivery Status Update was selected, you'd see exactly this — status records, no send-mail records. Worth confirming all three are on before reading anything into it.

Third — there isn't a free route. The support guidance is explicit: "Azure provides unlimited support for subscription management, which includes billing, quota adjustments, and account transfers. For technical support, you need a support plan." A server-side message trace is technical, so Basic won't cover it.

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.