What is the reasoning for feedback status value being delay instead of sent?

[MarlieHo1]

We have a live journey where members were not receiving the email as expected (unitary event/triggered). A day later, they received the email and the message feedback status was equal to "delay". Is there any in depth explanation to why a delay would happen?

[DavidKangni]

I noticed a similar behavior when sending to my work email vs personal email. The reason can be your email server is doing an additional verification and delivering the email late. Also some domain such as comcast can show delay because of the throughput or throttle traffic from the AJO IP

You can run this query 

SELECT
  split_part(
    _experience.customerJourneyManagement.emailChannelContext.address,
    '@',
    2
  ) AS recipientDomain,
  _experience.customerjourneymanagement.messagedeliveryfeedback.feedbackstatus AS status, _experience.customerjourneymanagement.messagedeliveryfeedback.messagefailure.reason AS failurereason, _experience.customerjourneymanagement.messagedeliveryfeedback.messagefailure.type AS bouncetype, 
    count(*) eventCount
FROM
  ajo_message_feedback_event_dataset
WHERE
  _experience.customerjourneymanagement.messageprofile.channel._id = 'https://ns.adobe.com/xdm/channels/email'
  and _experience.customerJourneyManagement.messageDeliveryfeedback.feedbackStatus = 'delay'
GROUP BY
  recipientDomain, status, failurereason, bouncetype
ORDER BY
  eventCount DESC;

 Overall, based on the result of your query you may need to reach out to Adobe deliverability to get more details on the issue or to do a remediation with the domain.

Thanks,

David

[FilipeFreitas · Accepted solution]

HI @MarlieHo1,

I faced the same issue here, which made me contact both our deliverability consultant and Adobe's customer support. Let me share the answers I received.

When asked about delay:

"The "delay" status you observed in the reporting for the journey usually indicates that Adobe’s mail infrastructure is retrying message deliveries, typically due to temporary ISP throttling or temporary recipient server issues.

These are not permanent failures: most delayed messages will eventually be delivered or classified as bounces with explicit reasons.

There are no configuration or reporting errors identified in AJO or CJA. This behavior is expected when ISPs, such as Gmail or Yahoo, throttle large volumes or temporarily block specific sending IPs.

Recommended Steps:
Monitor delivery over the next hours to days: Most "delay" messages will resolve themselves, converting into "Sent" or explicit "Bounce/Error" with a reason.

Check Deliverability Reports: Please review standard deliverability best practices (Adobe's documentation) to help improve sending reputation."

When asked about timeout, that was high for Gmail:

"In this specific instance, those bounces are from Gmail and when I review the bounce logs they indicate that these users are currently suspended. Their email accounts have not yet been deleted by Gmail (would show as Invalid Recipient), and they don’t have a Full Mailbox either; instead, these users have not logged into Gmail in so long that Gmail has suspended their account. If they do not log in soon, they will eventually be deleted, but the account could still be revived by the user if they wanted to do so if they act before the deletion. While suspended, Gmail does not process any email for them to avoid spending additional resources on an account they believe is no longer wanted."

Again, just sharing the knwoledge from the answers I received. 

I hope this somehow helps.

Best Regards,

Filipe Freitas

[Pulkit_Jain_]

@MarlieHo1 

There is a difference between the status code delay (deferral), bounce, and sent.

Transient 4xx responses (mostly mailbox busy) are written to the feedback dataset as feedbackStatus = delay, and they keep the message in the retry queue until the message is delivered (status sent) or the status is marked as bounced if the retry limit is reached i.e all retries will convert in sent or bounce. So ideally the status should have been changed, if the email was recieved (before the retry-duration)

To understand why the status didn't change to sent, could you share the screenshot of feedback dataset with messageFailure.type, timestamp and messageFailure.reason as well?