Loading

Marketing Cloud Triggered Send email (including Journey Builder sends) not sent to subscriber

Дата публикации: Dec 18, 2025
Описание

Overview

When sending a Marketing Cloud Email via a Triggered Send Definition, there are occasions where the send wasn't delivered to the Subscriber specified in the Triggered Send API call or the Journey builder email activity

There are a few common reasons a Subscriber isn't sent a Triggered Email. Each section provides an overview of the behavior and how to check if it's causing the Email not to be sent.

⚠️: This Knowledge Article is specifically for Triggered Sends via Email Studio or non Transactional Sends in Journey Builder. While some information applies to the Transactional API, this article focuses solely on Triggered Sends via Email Studio.


Table of Contents:

 


Triggered Send Status


Triggered Sends must be in a Running/Active status for the Email to be sent. There are four statuses in the UI with an additional status when using SOAP API.
 

  • New (UI) & New (API)
  • Paused (UI) & Inactive (API)
  • Running (UI) & Active (API)
  • Archived (UI) & Canceled (API)
  • Deleted (API only)


To review Triggered Send Status within Email Studio, use the following steps.

  • Log into your MC tenant and go into Email Studio
  • Select Interactions, and within the menu, select Triggered Emails
  • Find the Triggered Send within your folder structure
  • On the right-hand side, review the Status column and check the Triggered Send is Running


If the Triggered Send is in a Paused/Inactive status, the emails are queued and sent when the Triggered Send is placed in a running/active state. As soon as you hit Start/Restart, the system attempts to send the queued Emails. If you're concerned about sending the queued emails, review our Triggered Sends Queue Options to identify the queued emails and clear the Triggered Send Queue.

 

If the Triggered Send is in running status, and there are emails in the queue, the triggered send is in an error status. When a triggered send is moved to error status an email is sent to the configured address in Alert Manager (if Alert Manager was not configured, finish configuration and stop / start the triggeredsend if it errors again, email will be sent with reason). Once the error has been resolved, Stop / Publish / Start the triggeredsend to send to subscribers within the queue with update content.

⚠️: The Marketing Cloud has a three-day expiration policy for subscribers queued for a Triggered Send. Any subscriber in the queue > 72 hrs will move to error status once the triggeredsend is restarted.

 

Exclusion Management


Subscribers can be excluded from a Triggered Send using a Domain Exclusion Data Extensions or Exclusion Script. Excluded Subscribers don't appear on an Email SendLog but do appear in the NotSent Data Extract.


Domain Exclusion Data Extension


A Domain Exclusion Data Extension is a Data Extension created with the’ DomainExclusion’ Template. Only Data Extensions created with the ‘DomainExclusion’ Template appear in the Domain Exclusion folder tree when setting up a Triggered Send.

A Domain Exclusion Data Extension comes with a predefined ‘Domain’ field that can be populated with as many Domains as you see fit and applied to the Triggered Send. Any API call that attempts to send to an EmailAddress that includes a domain in a Domain Exclusion Data Extension won’t be sent.

The EmailAddress in an API call can be different than the EmailAddress of the SubscriberKey in the All Subscribers List. Checking the All Subscribers List for that SubscriberKey may not be an accurate method to confirm the exclusion from the Send.

To review a Subscriber excluded by a Domain Exclusion Data Extension, configure the NotSent Data Extract and review the file, a Subscriber excluded appears as:

  • SendID = JobID of the Send
  • EventType = NotSent
  • Reason = Domain Exclusion


 

Exclusion Script


An Exclusion Script uses AMPscript to restrict Subscribers from receiving a Triggered Send. The Create an Exclusion Script to limit a Triggered Send to Email one Subscriber at a time article provides an example of using this functionality.

Should a Subscriber be excluded by the Exclusion Script, review the NotSent Data Extract as the Subscriber will show a Reason that points to the Exclusion Script:

  • SendID = JobID of the Send
  • EventType = NotSent
  • Reason = Excluded by Send Time Filter

⚠️: If you can’t create an Exclusion Script within a Triggered Send definition, create a Case for Customer Support to enable this feature.



API Call Troubleshooting


When creating a Triggered Send Email Message, we recommend creating a Triggered Send Data Extension using the TriggeredSendDataExtension Template. Associating a Triggered Send Data Extension to your Triggered Send Email assists in troubleshooting delivery issues by recording specific details about the API call and Subscriber.

⚠️: We recommend logging the complete API Requests and Responses you make to the Marketing Cloud for in-depth troubleshooting of your API calls.

Marketing Cloud allows both synchronous (sync) and asynchronous (async) API calls. The following sections cover the differences in how the system handles sync and async calls.
 

Synchronous API Calls


When performing synchronous Triggered Send API calls, the Marketing Cloud processes and responds to the request in a single transaction. Review the API response provided by the Marketing Cloud endpoint to determine why an API call failed to send the Triggered Send Email.

The most common ErrorCode is 180008. Review the complete list of Error Codes in our SOAP Error Codes Developer Documentation.

 

Asynchronous API Calls


When performing asynchronously Triggered Send API calls, the Marketing Cloud checks the structure of the API call is correct and then places the request in a processing queue. The system doesn't try to process the call or evaluate if the provided data result in a successful email before sending an initial response.

Because an async API call isn’t fully processed before responding, it’s possible to receive an initial successful response, but the Email fails to be sent because of incorrect or missing data in the API call.

We recommend reading our Asynchronous Processing documentation to determine if this API processing method is correct for you. If you’re using asynchronous API calls, ensure you have implemented Callback Handling for Asynchronous Calls to check the final result of an async call.

If callback handling hasn’t been implemented, you can perform the same API call synchronously instead of asynchronously to get real-time errors in the response of your call.

If a Sync or Async call fails, review your SendLog (if it's configured) or the NotSent Data Extract to confirm if and why the Subscriber was excluded from the Send.

⚠️: Some Error Codes are logged to the SendLog Data Extension and can be used for troubleshooting API calls, but the NotSent Data Extract is the recommended source to identify excluded Subscribers of a Send.

It’s also possible to use the API to return the result of the messageDefinitionSends service via the deliveryRecords URI. The endpoint requires the RecipientSendId value from the response of the messageDefinitionSends service so ensure you’ve logged this value to then add it as a URL parameter to review the delivery (or non-delivery) of your Triggered Send Message.

An example of the response from the messageDefinitionSends route is below.
 

{
    "requestId": "9719beb7-7447-4c19-ae56-b16e863be863",
    "responses": [
        {
            "recipientSendId": "9719beb7-7447-4c19-ae56-b16e863be863",
            "hasErrors": false,
            "messages": [
                "Queued"
            ]
        }
    ]
}


After noting down the recipientSendId value, input this into your URL like so.
 

https://xxxxxxxxxxxxxxx.rest.marketingcloudapis.com/messaging/v1/messageDefinitionSends/key:PasswordReset/deliveryRecords/9719beb7-7447-4c19-ae56-b16e863be863


After you make the GET call to return information around the send, the response provides information about whether the Send was successful or unsuccessful, the following is an example of an unsuccessful Send.
 

{
    "id": "fe9fbb4c-d316-ec11-b835-48df37d1df5a",
    "messageId": "af6d0b88-fa96-4815-a7d9-d7312978a5c2",
    "status": "Error",
    "to": {
        "address": "",
        "id": 0,
        "key": ""
    },
    "messageErrors": [
        {
            "messageErrorStatus": "There are required data extension fields missing for the subscriber"
        }
    ]
}

  



 

Standard Email Troubleshooting


If you’ve confirmed the Triggered Send is active and your API calls are correct perform standard email troubleshooting steps. 

Номер статьи базы знаний

000389503

 
Загрузка
Salesforce Help | Article