1. Establish a baseline with a minimal test
Create a new test inbox, copy its address, and immediately trigger a simple email with a unique subject. You may include the test ID in the subject, but never include production keys or real customer data.
Record when you click the business button, when the job enters the queue, and when the provider accepts it. If a simple email arrives but a complex template does not, the issue is more likely template rendering, attachments, or content policy than basic network connectivity.
2. Confirm that the app actually generated the email
Check whether the business event met the sending conditions, such as account status, environment flags, deduplication rules, and notification preferences. Logs should show the final recipient address—not just a generic “email job created” message.
Verify the address character by character, especially if the app has cached an old address after you changed test inboxes. If there is no message record, fix the trigger and template parameters first; don’t investigate DNS yet.
Evidence you should see
- Business event ID and template version
- Normalized recipient address
- Successful message creation or a clear error
3. Check the queue, retries, and timing
Asynchronous email often gets stuck in the queue connection, worker process, scheduled time, or retry backoff. Compare the enqueue time, first execution, each retry, and final status to confirm that the job is not still waiting.
If one event produces multiple emails, check whether the idempotency key is stable and whether the consumer timed out before receiving a success response. Don’t hide deterministic template errors with unlimited retries, or the receiving inbox may get duplicate messages.
4. Read the sending provider’s events
An HTTP 2xx response usually means only that the provider accepted the request—not that the recipient’s server accepted the message. Continue checking for events such as queued, sent, delivered, deferred, bounced, or rejected, and retain the provider message ID.
SMTP 4xx responses usually indicate a temporary delay and can be handled with the recommended backoff. 5xx responses are generally permanent rejections; fix the address, authentication, or policy first. If the provider has no corresponding message, the break is still between the app and the provider.
5. Verify sender domain authentication
Check that SPF covers the actual sending source, that the DKIM signing domain aligns with the From domain as configured, and that DMARC alignment and policy match the test environment. After a DNS change, also account for TTLs and resolver caches.
Don’t rely only on a green status in the dashboard. Read the authentication results in the specific email event or raw headers. Shared test domains that frequently switch sending platforms can also retain stale records or exceed the SPF lookup limit.
6. Isolate template and content policy issues
Send a plain-text baseline first, then add HTML, images, links, and attachments step by step. If delivery fails after adding one item, check URL reputation, attachment type, encoding, message size, and unreplaced template variables.
Don’t imitate phishing language in the subject or body, and never use real credentials. For verification-code tests, use a fixed test code and clearly label the environment so testers don’t mistake the message for a production notification.
7. Rule out receiving-inbox issues
Confirm that the test inbox countdown has not reached zero and that the current toolbar address matches the sending target. Click Refresh manually. If you just changed addresses, messages from the old inbox will not move to the new one.
After the real email arrives, the demo row should disappear from the list and only real data should remain. Open the details and check the subject, sender, arrival time, HTML body, and plain-text fallback. Don’t judge template completeness from the list preview alone.
8. Analyze delays, ordering, and duplicates
Use the same time zone to compare the business trigger, enqueue, provider acceptance, and inbox arrival times. Attribute the delay to a stage only when one checkpoint is clearly longer; inconsistent time zones can lead to false conclusions.
For resend tests, use a new unique event ID while retaining the old message ID. If the later message arrives first, check queue priority, concurrent consumers, and provider retries instead of assuming the inbox sorted the list incorrectly.
9. Narrow the issue with a symptom matrix
10. When to escalate and what to provide
If the steps above do not identify the issue, compile a minimal evidence package containing the timeline, target address, business event ID, provider message ID, final status, and ruled-out possibilities. Redact sensitive message content and retain only what is needed to reproduce the issue.
When contacting MSGTMP support, include the inbox creation and expiry times, whether you changed the address, and the final response recorded by the sending provider. Never send passwords, login codes, or complete private keys. The support email is support@msgtmp.com.
Definition of diagnostic complete
Success is not “it happened to arrive after a resend.” You should be able to identify the break, explain the cause, and prove with the same minimal test that the fix works consistently.
