Las devoluciones son el resultado de un intento de entrega y un error en el que el ISP proporciona avisos de error de devolución. El procesamiento de la manipulación de devoluciones es una parte esencial del estado de la lista. Una vez que un correo electrónico determinado ha rebotado varias veces, este proceso indica su supresión.
Este proceso evita que los sistemas continúen enviando direcciones de correo electrónico no válidas. Las devoluciones son uno de los datos clave que los ISP utilizan para determinar la reputación de la IP. Es importante estar atento a esta métrica. "Entregado" frente a "devuelto" es probablemente la forma más común de medir el envío de mensajes de marketing: cuanto mayor sea el porcentaje de entrega, mejor.
Si un mensaje no se puede enviar a un perfil, el servidor remoto envía automáticamente un mensaje de error a Adobe Campaign. Este error sirve para determinar si la dirección de correo electrónico, el número de teléfono o el dispositivo deben ponerse en cuarentena. Consulte Administración de correos rechazados.
Una vez enviado un mensaje, puede ver el estado de envío de cada perfil y el tipo y el motivo de error asociado en los registros de envío.
Cuando una dirección de correo electrónico está en cuarentena, o si un perfil está a la lista de bloqueados, el destinatario se excluye en el paso de preparación de la entrega. Los mensajes excluidos se muestran en el panel de entrega.
Existen dos tipos de error cuando falla un mensaje. Cada tipo de error de entrega determina si una dirección se envía a cuarentena o no.
Rechazos graves
Las devoluciones duras son errores permanentes generados después de que un ISP determine que un intento de envío a una dirección de suscriptor no se puede entregar. En Adobe Campaign, las devoluciones graves de mensajes clasificados como no aptos para entrega se añaden a la lista de cuarentena, lo que significa que no se volverán a enviar. Hay algunos casos en los que se ignoran los mensajes devueltos no válidos si se desconoce la causa del error.
Estos son algunos ejemplos comunes de devoluciones graves: La dirección no existe, Cuenta deshabilitada, Sintaxis incorrecta, Dominio incorrecto
Rechazos leves
Las devoluciones leves de mensajes son errores temporales que los ISP generan cuando tienen dificultades para enviar correos. Los errores leves volver a intentar varias veces (con variación según el uso de la configuración de envío personalizada o predeterminada) para intentar una entrega correcta. Las direcciones de mensajes devueltos no entregados que reboten de forma continua no se añadirán a la cuarentena hasta que se haya intentado el número máximo de reintentos (que varía en función de la configuración).
Algunas causas comunes de las devoluciones leves son las siguientes: Buzón lleno, Recepción del servidor de correo electrónico caído, Problemas de reputación del remitente
El Ignorado El tipo de error es temporal, como "Fuera de la oficina", o un error técnico, por ejemplo, si el tipo de remitente es "Administrador de correo".
El bucle de comentarios funciona como los correos electrónicos rechazados: cuando un usuario clasifica un correo electrónico como correo no deseado, puede configurar las reglas de correo electrónico en Adobe Campaign para bloquear todas las entregas a este usuario. Incluida en la lista de bloqueados Las direcciones de estos usuarios se aunque no hayan hecho clic en el vínculo de baja. Las direcciones se añaden a (NmsAddress) tabla de cuarentena y no a (NmsRecipient) tabla de destinatarios con Denylisted estado. Obtenga más información acerca del mecanismo de bucle de comentarios en la Guía de prácticas recomendadas de entrega de Adobe.
Una entrega de mensajes puede fallar inmediatamente, en ese caso se clasifica como un error sincrónico. Si el envío de mensajes falla o más tarde, después de enviarlos, el error es asincrónico.
Estos tipos de errores se administran de la siguiente manera:
Error sincrónico: el servidor remoto contactado mediante el servidor de entrega de Adobe Campaign devuelve inmediatamente un mensaje de error. No se permite realizar la entrega al servidor del perfil. El Agente de transferencia de correo (MTA) determina el tipo de rechazo y clasifica el error, y envía esa información a Campaign para determinar si las direcciones de correo electrónico correspondientes deben ponerse en cuarentena. Consulte Cualificación de correo rechazado.
Error asíncrono: el servidor receptor reenvía más tarde un correo electrónico de rechazo o una SR. Este error se califica con una etiqueta relacionada con el error. Pueden producirse errores asíncronos hasta una semana después de mandar la entrega.
Como usuario de Managed Cloud Services, la configuración del buzón de rechazos se realiza mediante el Adobe.
La forma en que se gestiona la calificación de correo rechazado en Adobe Campaign depende del tipo de error:
Errores sincrónicos: el MTA determina el tipo de rechazo y la calificación, y envía esa información a Campaign. Las cualificaciones de rechazo en la Delivery log qualification no se utilizan para sincrónico mensajes de error de fallo de entrega.
Errores asíncronos: Las reglas utilizadas por Campaign para clasificar los errores de entrega asincrónicos se enumeran en la Administration > Campaign Management > Non deliverables Management > Delivery log qualification nodo. Las devoluciones asincrónicas son calificadas por el proceso de inMail a través de la variable Inbound email reglas. Para obtener más información, consulte Documentación de Adobe Campaign Classic v7.
Si la entrega de un mensaje falla tras un error temporal (Suave o Ignorado), Campaign reintenta enviar. Estos reintentos se pueden realizar hasta el final de la duración de la entrega.
Los reintentos de rebote suave y el periodo entre ellos están determinados por el MTA en función del tipo y la gravedad de las respuestas de devoluciones procedentes del dominio de correo electrónico del mensaje.
Campaign no utiliza la configuración de reintentos en las propiedades de entrega.
La configuración del periodo de validez de los envíos de Campaign está limitada a 3,5 días o menos. Para una entrega, si define un valor superior a 3,5 días en Campaign, no se tendrá en cuenta.
Por ejemplo, si el periodo de validez se establece en el valor predeterminado de 5 días en Campaign, los mensajes de rebote suave se incluirán en la cola de reintentos de MTA y se volverán a intentar durante un máximo de 3,5 días a partir de la fecha en que el mensaje llegue al MTA. En ese caso, no se utilizará el valor establecido en Campaign.
Una vez que un mensaje ha estado en la cola de MTA durante 3,5 días y no se ha podido entregar, se agotará el tiempo de espera y se actualizará su estado de Sent hasta Failed en los registros de envío.
Para obtener más información sobre el periodo de validez, consulte la Documentación de Adobe Campaign Classic v7.
Para el canal de correo electrónico, a continuación se enumeran los posibles motivos de un error de entrega.
Etiqueta de error | Tipo de error | Valor técnico | Descripción |
Cuenta deshabilitada | Leve/Grave | 4 | La cuenta vinculada a la dirección no está activa. Cuando el proveedor de acceso a Internet (IAP) detecta un periodo de inactividad prolongado, puede cerrar la cuenta del usuario. A partir de ese momento no se pueden realizar entregas a la cuenta de usuario. Si la cuenta está temporalmente desactivada debido a seis meses de inactividad y todavía se puede activar, se asigna el estado “con errores” y se prueba de nuevo la cuenta hasta que el contador de errores alcance 5. Si el error indica que la cuenta está desactivada de forma permanente, se envía directamente a Cuarentena. |
Dirección en cuarentena | Grave | 9 | La dirección se envió a cuarentena. |
Dirección no especificada | Grave | 7 | No se proporciona ninguna dirección para el destinatario. |
Dirección de baja calidad | Ignorado | 14 | El índice de calidad de esta dirección es demasiado bajo. |
Dirección incluida en la lista de bloqueados | Grave | 8 | La dirección se agregó a la lista de bloqueados al momento del envío. Este estado se utiliza para importar datos de listas externas y sistemas externos a la lista de cuarentena de Adobe Campaign. |
Dirección de control | Ignorado | 127 | La dirección del destinatario forma parte del grupo de control. |
Duplicada | Ignorado | 10 | La dirección del destinatario ya se encontraba en esta entrega. |
Error ignorado | Ignorado | 25 | La dirección está incluida en la lista de permitidos. Por lo tanto, el error se ignora y se envía un correo electrónico. |
Excluido tras la mediación | Ignorado | 12 | El destinatario se ha excluido mediante las reglas de tipología de campaña de tipo “mediación”. |
Excluido por una regla SQL | Ignorado | 11 | El destinatario se ha excluido mediante una regla de tipología de campaña de tipo “SQL”. |
Dominio inválido | Leve | 2 | El dominio de la dirección del correo electrónico es incorrecto o ya no existe. Este perfil se vuelve a seleccionar hasta que el recuento de errores llegue a 5. Después de esto, el registro se pone en estado de cuarentena y no se realiza ningún reintento. |
Buzón de correo lleno | Leve | 5 | El buzón de este usuario está lleno y no puede aceptar más mensajes. Este perfil se vuelve a seleccionar hasta que el recuento de errores llegue a 5. Después de esto, el registro se pone en estado de cuarentena y no se realiza ningún reintento. Este tipo de error se administra mediante un proceso de limpieza; la dirección se establece en un estado válido después de 30 días. Advertencia: para que la dirección se elimine automáticamente de la lista de direcciones en cuarentena, debe iniciarse el flujo de trabajo técnico Database cleanup. |
Sin conexión | Ignorado | 6 | El teléfono móvil del destinatario está apagado o no está conectado a la red cuando al enviar el mensaje. |
Sin definir | Sin definir | 0 | La dirección está en proceso de clasificación porque el error aún no se ha sumado. Este tipo de error se produce cuando el servidor envía un nuevo mensaje de error: puede tratarse de un error aislado; sin embargo, si vuelve a producirse, el contador de errores aumenta, lo que advierte a los equipos técnicos. Entonces pueden realizar análisis de mensajes y clasificar este error a través del nodo Administration, Campaign Management, Non deliverables Management en la estructura del árbol. |
No reúne los requisitos para las ofertas | Ignorado | 16 | El destinatario no reunía los requisitos para las ofertas de la entrega. |
Rechazado | Leve/Grave | 20 | La dirección se ha enviado a cuarentena debido a un comentario de seguridad que informa de correo no deseado. Según el error, se vuelve a intentar enviar un correo a la dirección hasta que el contador de errores alcance 5 o se envía directamente a cuarentena. |
Destinatarios de tamaño limitado | Ignorado | 17 | Se ha alcanzado el tamaño máximo de entrega para el destinatario. |
Dirección no autorizada | Ignorado | 15 | La dirección postal no se ha clasificado. |
Inaccesible | Leve/Grave | 3 | Se ha producido un error en la cadena de entrega de mensajes. Podría ser un incidente en la retransmisión SMTP, un dominio al que no se puede acceder temporalmente, etc. Según el error, se vuelve a intentar enviar un correo a la dirección hasta que el contador de errores llegue a 5 o se envía directamente a cuarentena. |
Usuario desconocido | Grave | 1 | La dirección no existe. No se intenta realizar entregas adicionales para este perfil. |
Para el canal de aplicaciones móviles, los posibles motivos de un error de entrega se enumeran a continuación.
El protocolo HTTP/V2 permite los comentarios y el estado directo para cada notificación remota. Si se utiliza el conector de protocolo HTTP/V2, el flujo de trabajo mobileAppOptOutMgt ya no se comunica con el servicio de comentarios. Un token de dispositivo se considera no registrado cuando se desinstala o se vuelve a instalar una aplicación móvil.
Sincrónicamente, si APNS devuelve el estado “no registrado” para un mensaje, el token de destino se pone inmediatamente en cuarentena.
Situación |
Estado |
Mensaje de error |
Tipo de error |
Motivo del error |
Reintento |
Dispositivo de destino encendido |
OK |
||||
Dispositivo de destino apagado |
OK |
||||
El usuario desactiva las notificaciones de la aplicación |
OK |
||||
Fase de creación/análisis de mensaje: carga útil demasiado grande |
Fallo |
Carga útil demasiado grande |
Leve |
Rechazado |
No |
Fase de creación/análisis de mensaje: problema de formato inesperado del contenido |
Fallo |
Varios mensajes de error según el error |
Leve |
Sin definir |
No |
Problema de certificado (contraseña, corrupción, etc.) y conexión de prueba a un problema de APNS |
Fallo |
Varios mensajes de error según el error |
Leve |
Rechazado |
No |
Se perdió la conexión de red durante la entrega |
Fallo |
Error de conexión |
Sin definir |
Inaccesible |
Sí |
Rechazo de mensaje APNS: cancelación del registro el usuario ha eliminado la aplicación o el token ha caducado . |
Fallo |
No registrado |
Grave |
Usuario desconocido |
No |
Rechazo de mensaje de APNS: todos los demás errores |
Fallo |
La causa del rechazo del error está presente en el mensaje de error. |
Leve |
Rechazado |
No |
Para Android V1
Para cada notificación, Adobe Campaign recibe los errores sincrónicos directamente desde el servidor FCM. Adobe Campaign los gestiona sobre la marcha y genera errores graves o leves según la gravedad de los errores y los reintentos que se puedan realizar:
El flujo de trabajo mobileAppOptOutMgt se ejecuta cada 6 horas para actualizar la tabla de AppSubscriptionRcp. En el caso de los tokens declarados no registrados o ya no válidos, el campo Deshabilitado se establece en Verdadero y la suscripción vinculada a ese token de dispositivo se excluye automáticamente de futuros entregas.
Durante el análisis de la entrega, todos los dispositivos excluidos del destino se añaden automáticamente a la tabla excludeLogAppSubRcp.
Para los clientes que utilicen el conector Baidu, los distintos tipos de errores son:
Adobe Campaign se pone en contacto con el servidor Baidu cada 10 minutos para recuperar el estado del mensaje enviado y actualiza los broadlogs. Si se declara un mensaje como enviado, el estado del mensaje en los broadlogs se establece en Received. Si Baidu declara un error, el estado se establece en Failed.
Para Android V2
El mecanismo de cuarentena de Android V2 utiliza el mismo proceso que Android V1; lo mismo se aplica a las suscripciones y a la actualización de las exclusiones. Para obtener más información, consulte la sección de Android V1.
Situación |
Estado |
Mensaje de error |
Tipo de error |
Motivo del error |
Reintento |
Fase de creación/análisis de mensaje: palabras clave no válidas utilizadas en los campos personalizados |
Fallo |
Las siguientes palabras clave no se pueden utilizar: {1} |
Leve |
No |
|
Fase de creación/análisis de mensaje: carga útil demasiado grande |
Fallo |
La notificación es demasiado pesada: {1} bits, mientras que solo se autorizan {2} . |
Leve |
Rechazado |
No |
Se perdió la conexión de red durante la entrega |
Fallo |
No hay respuesta del servicio Firebase Cloud Messaging en la dirección: {1} |
Leve |
Inaccesible |
Sí |
Rechazo de mensaje FCM: El servidor FCM no está disponible temporalmente (por ejemplo, con tiempos de espera). |
Fallo |
El servicio de Firebase Cloud Messaging no está disponible temporalmente |
Leve |
Inaccesible |
Sí |
Rechazo de mensaje FCM: Error al autenticar la cuenta del remitente . |
Fallo |
Error al identificar la cuenta de desarrollador, compruebe su ID y contraseña |
Leve |
Rechazado |
No |
Rechazo de mensaje FCM: Se excedió la cuota de dispositivo . |
Fallo |
Leve |
Rechazado |
Sí |
|
Rechazo de mensaje FCM: Registro no válido / no registrado |
Fallo |
Grave |
Usuario desconocido |
No |
|
Rechazo de mensaje FCM: Todos los demás errores |
Fallo |
El servidor Firebase Cloud Messaging ha devuelto un código de error inesperado: {1} | Rechazado |
No |
|
Rechazo de mensaje de FCM: argumento no válido |
Fallo |
INVALID_ARGUMENT | Ignorado | Sin definir |
No |
Rechazo de mensaje de FCM: error de autenticación de terceros |
Fallo |
THIRD_PARTY_AUTH_ERROR | Ignorado | Rechazado |
Sí |
Rechazo de mensaje de FCM: el ID del remitente no coincide |
Fallo |
SENDER_ID_MISMATCH | Leve | Usuario desconocido |
No |
Rechazo de mensaje de FCM: no registrado |
Fallo |
NO REGISTRADO | Grave | Usuario desconocido |
No |
Rechazo de mensaje de FCM: interno |
Fallo |
INTERNAL | Ignorado | Rechazado |
Sí |
Rechazo de mensaje de FCM: no está disponible |
Fallo |
UNAVAILABLE | Ignorado | Rechazado |
Sí |
Rechazo de mensaje de FCM: código de error inesperado |
Fallo |
unexpected error code | Ignorado | Rechazado |
No |
Autenticación: problema de conexión |
Fallo |
No es posible conectarse al servidor de autenticación | Ignorado | Rechazado |
Sí |
Autenticación: cliente o ámbito no autorizado en la solicitud. |
Fallo |
unauthorized_client | Ignorado | Rechazado |
No |
Autenticación: el cliente no tiene autorización para recuperar los token de acceso mediante este método o no está autorizado para ninguno de los ámbitos solicitados. |
Fallo |
unauthorized_client | Ignorado | Rechazado |
No |
Autenticación: acceso denegado |
Fallo |
access_denied | Ignorado | Rechazado |
No |
Autenticación: correo electrónico no válido |
Fallo |
invalid_grant | Ignorado | Rechazado |
No |
Autenticación: JWT no válido |
Fallo |
invalid_grant | Ignorado | Rechazado |
No |
Autenticación: firma JWT no válida |
Fallo |
invalid_grant | Ignorado | Rechazado |
No |
Autenticación: audiencia de ámbito de OAuth o token de ID no válida proporcionada |
Fallo |
unauthorized_client | Ignorado | Rechazado |
No |
Autenticación: cliente OAuth deshabilitado |
Fallo |
disabled_client | Ignorado | Rechazado |
No |
Para conectores estándar
Las particularidades del canal SMS se enumeran a continuación.
La tabla Delivery log qualification no se aplica al conector Extended generic SMPP.
Situación |
Estado |
Mensaje de error |
Tipo de error |
Motivo del error |
Enviado al proveedor |
Enviado |
|||
Recibido en el móvil |
Recibido |
|||
Error devuelto por el proveedor |
Fallo |
Error al recibir datos (SR o MO) |
Leve |
Inaccesible |
Reconocimiento de MT no válido |
Fallo |
Error “{1}” durante el procesamiento del marco de reconocimiento de la consulta de entrega |
Leve |
Inaccesible |
Error al enviar el MT |
Fallo |
Error al enviar mensajes |
Leve |
Inaccesible |
Para el conector SMPP genérico extendido
Al utilizar el protocolo SMPP para enviar mensajes SMS, la administración de errores se gestiona de forma distinta.
El conector SMPP recupera los datos del mensaje de SR (informe de estado) que se devuelve utilizando expresiones regulares (regex) para filtrar su contenido. Estos datos se corresponden con la información que se encuentra en la tabla Delivery log qualification (disponible a través del menú Administration > Campaign Management > Non deliverables Management).
Antes de que se clasifique un nuevo tipo de error, el motivo del error se establece siempre como Rechazado de forma predeterminada.
Los tipos de errores y los motivos del error son los mismos que para los correos electrónicos.
Solicite a su proveedor una lista de estados y códigos de error para establecer tipos y motivos de error adecuados para los errores en la tabla de clasificación de registros de entregas.
Ejemplo de mensaje generado:
SR Generic DELIVRD 000|#MESSAGE#
Todos los mensajes de error empiezan por SR para distinguir entre los códigos de error de los SMS y códigos de error de los correos electrónicos.
La segunda parte (Generic en este ejemplo) del mensaje de error hace referencia al nombre de la implementación de SMSC, como se define en el campo SMSC implementation name de la cuenta externa de SMS.
Dado que el mismo código de error puede tener un significado diferente para cada proveedor, este campo permite saber qué proveedor genera el código de error. Después se puede buscar el error en la documentación del proveedor correspondiente.
La tercera parte (DELIVRD en este ejemplo) del mensaje de error corresponde al código de estado recuperado del SR mediante las regex de extracción de estado definidas en la cuenta externa de SMS.
Esta regex se especifica en la pestaña SMSC specificities de la cuenta externa.
De manera predeterminada, la regex extrae el campo stat: como se define en la sección Apéndice B de la especificación de SMPP 3.4.
La cuarta parte (000 en este ejemplo) del mensaje de error corresponde al código de error extraído del SR mediante la regex de extracción de código de error definida en la cuenta externa de SMS.
Esta regex se especifica en la pestaña SMSC specificities de la cuenta externa.
De manera predeterminada, la regex extrae el campo err: tal y como se define en la sección Apéndice B de la especificación de SMPP 3.4.
Todo lo que aparece después del símbolo de barra vertical (|) se muestra solo en la columna First text de la tabla Delivery log qualification. Este contenido siempre se sustituye por #MESSAGE# después de normalizar el mensaje. Este proceso evita tener varias entradas para errores similares y funciona igual que para los correos electrónicos.
El conector genérico extendido SMPP aplica un método heurístico para buscar valores predeterminados coherentes: si el estado comienza con DELIV, se considera un éxito porque coincide con los estados comunes utilizados por la mayoría de los proveedores DELIVRD o DELIVERED. Cualquier otro estado conlleva un error grave.