Password reset emails marked delivered but never arrive

What breaks quietly

Why password reset triggered sends fail without surfacing

SFMC tracking shows API call success and delivery status. It does not alert when a data extension lookup returns null, when AMPscript halts mid-render, or when a subscriber key mismatch silently drops the send.

1

Data extension lookup returns null

The triggered send definition pulls the reset token from a data extension row matched on subscriber key. The API call provides a key that exists in All Subscribers but has no matching row in the token table. The lookup returns null. SFMC logs the send as complete. The email arrives with a blank token.

2

Subscriber key mismatch between systems

The application sends a user ID as the subscriber key. SFMC expects an email address. The triggered send API call succeeds because the key format is valid. The subscriber record is not found. SFMC creates a new record with the user ID as the email address. The send completes to an undeliverable address.

3

AMPscript error halts rendering

The email template includes an AMPscript block that references a field from the data extension. The field name was updated after a schema change. AMPscript throws an error. Rendering stops. SFMC logs the send, but the email never leaves the queue.

4

API timeout returns success before completion

The triggered send API call times out at the application layer. The application logs success based on the initial response. SFMC processes the request after the timeout. The send is queued but delayed by 15 minutes. The user has already retried and generated a duplicate.

5

Opt-out state overrides transactional classification

A subscriber previously opted out of marketing emails. The triggered send is marked as transactional in Email Studio, but the API call does not explicitly override the opt-out status. SFMC respects the subscriber preference. The send is suppressed. No error is logged.

6

Token expiry window shorter than send delay

The reset token has a 10-minute validity window. The triggered send is queued behind a batch job. The email arrives 12 minutes after the API call. The token is expired. The user clicks the link and sees an error page.

Real breakage pattern

When reset emails arrive late on the first send of the day

A login system fires password reset requests through SFMC. The first request each morning takes eight minutes to arrive. Subsequent requests in the same hour arrive within 90 seconds. The delay is not random. It is the send queue warming up after idle overnight.

1

Late arrival in the first 30 minutes is usually a queue issue

When a reset email takes longer than expected but still arrives within a few minutes, the cause is often SFMC send-queue throttling or a processing delay after idle periods. A genuine breakage shows up as no arrival at all, or arrival outside the configured window entirely.

2

Scheduled checks catch the symptom before the user retries

The absence of the expected send within two minutes signals a problem. Scheduled monitoring fires a test API call on a regular cadence. If the reset email does not arrive in the window, an alert fires. The operator knows the flow is broken before the first support ticket.

3

SFMC tracking will not flag silent suppression

When a subscriber opt-out state suppresses a triggered send, SFMC treats that as valid behaviour. There is no error logged. The API call returns success. Inbox-side monitoring fills the gap by confirming the test profile receives the email every time.

How Telltide fits

A monitored profile for every triggered send definition

Telltide runs alongside SFMC, not inside it. You add a test subscriber to the triggered send audience. Telltide watches the inbox for the sends SFMC says it made.

1

Add the monitor address to your subscriber list

Telltide gives you a unique inbox address per monitor. You create a subscriber record with that address, populate the data extension fields the template needs, and configure a scheduled API call to fire the triggered send definition on a regular cadence.

2

Set the arrival window to match your token validity

If the reset token expires in 10 minutes, set the monitor window to 8 minutes. If the email arrives after the window closes, an alert fires. If it does not arrive at all, an alert fires. Both scenarios tell you the flow is not working as designed.

3

Get alerted when the inbox disagrees with SFMC

If the email does not arrive in the window, an alert fires within two minutes. If it arrives twice because the API call was retried, an alert fires. If the reset link is broken or the token is blank, an alert fires. SFMC might still report the send as healthy. The alert tells you what actually reached the inbox.

Monitoring specific reset-flow components

Data extension lookups, AMPscript blocks and API timing

Each component in a password reset flow has its own monitoring considerations. Here is how to set up Telltide for the parts that break most often.

1

Confirm the data extension row exists before the API call

The test harness that fires the triggered send should write a token row to the data extension first, then call the API with the matching subscriber key. If the lookup fails, the monitor catches a blank token in the arrived email and alerts immediately.

2

Watch for AMPscript errors in the template

Set the monitor to compare the arrived email structure against a reference. If an AMPscript block halts rendering mid-template, the arrived email will be truncated or missing sections. The monitor flags the deviation and alerts.

3

Fire the test call on a realistic cadence

If production reset requests are sparse, fire the test call every 15 minutes to catch queue delays and idle-state issues. If requests are frequent, hourly checks are sufficient. The monitor confirms every test send arrives on time.

4

Override opt-out status in the API call

Mark the test subscriber as opted out in SFMC. Configure the triggered send API call to explicitly override the opt-out status with a transactional flag. If the override stops working after an SFMC update, the monitor catches the suppressed send.

SFMC observability vs native tracking

What SFMC tracking shows, and what it cannot

SFMC tracking is detailed. It logs API call success, delivery status, and bounce events. What it cannot show is whether the email that SFMC logged as delivered actually arrived with the correct token, within the validity window.

1

SFMC reports delivery, not inbox arrival

When SFMC logs a send as delivered, it means the receiving mail server accepted the message. It does not confirm inbox placement, spam filtering, or correct rendering. Inbox-side monitoring closes that gap by confirming arrival in a real inbox.

2

Suppressions are logged, not alerted

When a subscriber opt-out suppresses a triggered send, SFMC logs the suppression in the tracking data. It does not send an alert. If the suppression was unintended, you will not know until you actively review the logs or a customer complains.

3

AMPscript errors render silently

When AMPscript throws an error, SFMC logs the error in Job History. The email might still be marked as sent if rendering completed partially. The customer receives broken content. Telltide compares the arrived email against a reference and alerts on structural deviation.

Pair it with

Concepts and related monitoring guides

The pages below cover the broader SFMC monitoring context and how it fits with other transactional flows.

Monitor SFMC: the parent guide covering all SFMC send surfaces.
Triggered send monitoring: step-by-step confirmation for API-driven transactional emails.
Silent send failure: what constitutes a silent failure and why native tracking misses it.
Flow trigger failure: how entry conditions and API timing interact across platforms.

FAQ

Common questions about password reset monitoring

What causes a password reset email to be marked delivered but never arrive?

Data extension lookups that return null for the subscriber key, API calls that time out silently, AMPscript errors that halt rendering mid-template, or subscriber opt-out states that override the triggered send classification. SFMC logs each scenario differently. The inbox tells you whether the email actually arrived.

How do I monitor a password reset flow that fires on demand?

Set a scheduled test that fires the triggered send API call on a regular cadence. The monitored profile receives the reset email. If the API call succeeds but the inbox stays empty, an alert fires within two minutes.

Can SFMC native tracking catch subscriber key mismatches?

SFMC logs API errors when the subscriber key is completely invalid. It does not alert when the key is valid but points to the wrong data extension row, or when a lookup returns null and the send completes with blank personalisation.

What happens when a password reset link expires before the email is sent?

The triggered send completes, the email arrives with an expired token, and the customer sees a broken experience. Monitoring the arrival time catches delays that push the send past the token validity window.