How do I install the Email Delivery Verification skill?

Run npx skillmds@latest add randommonicle/email-delivery-verification in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Email Delivery Verification safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Email Delivery Verification?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Email Delivery Verification free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Email Delivery Verification?

randommonicle (@randommonicle) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Email Delivery Verification by randommonicle

Name: Email Delivery Verification
Author: randommonicle

Email Delivery Verification

A 2xx from a transactional email API means accepted, not delivered. Verify actual delivery in the provider's dashboard or webhooks, check the account-level suppression list, verify every recipient leg of a multi-recipient flow, and confirm a mailbox exists before pointing a send at it. Triggers when adding or changing any transactional email send or recipient address, and when diagnosing "the email never arrived". The provider-specific child of verify-the-effect. Does not fire on non-email side effects (outbound-side-effect-idempotency) or on the content of the email.

randommonicle Updated Sep 21, 2026

File contents

Email delivery verification

Three occurrences across two repos, all the same shape: the API returned success, the team believed the mail sent, and it silently never arrived. A corporate filter hard-blocked the whole message over an attachment type; a wrong operator address hard-bounced once and the provider's account-level suppression list swallowed every subsequent send to it, forever and silently.

The rules

2xx means queued. Actual delivery status (delivered / bounced / suppressed) lives in the provider's dashboard or webhooks — read it there when a send matters, and after any recipient change.
Check the suppression list as part of any "never arrived" diagnosis. One hard bounce can suppress an address account-wide; subsequent sends return 2xx and go nowhere.
Verify every recipient leg. Multi-recipient flows fail per-leg: the customer email worked while every operator notification was suppressed. Checking one leg proves one leg.
Confirm a mailbox exists before addressing it — the suppression cascade starts with one send to a mistyped or unprovisioned address.
Corporate filters block whole attachment classes. .html attachments get the entire message rejected by M365/Mimecast-class filters: deliver links, attach only tolerated formats (a DOCX passes where an HTML file does not). For recipients on a firm's own domain, a recipient-side block can only be fixed by their IT allowlisting the sender.
A sandbox sender reaches only verified addresses — verify the sending domain before relying on any send in the field.

What this skill does not do

It does not choose failure semantics for the send-then-record path (outbound-side-effect-idempotency) and does not govern email content. It is the delivery leg of verify-the-effect, split out because the mechanics are provider-specific.

Why

Email is the one side effect whose failure mode is designed to be silent: providers accept first and fail privately. Every incident in the evidence was discovered by a human noticing absence, days later. Evidence: ICC LESSONS_LEARNED L-004, L-015; ASH CLAUDE.md DNS/Email lesson (2026-05-21).

---name: email-delivery-verificationdescription: A 2xx from a transactional email API means accepted, not delivered. Verify actual delivery in the provider's dashboard or webhooks, check the account-level suppression list, verify every recipient leg of a multi-recipient flow, and confirm a mailbox exists before pointing a send at it. Triggers when adding or changing any transactional email send or recipient address, and when diagnosing "the email never arrived". The provider-specific child of verify-the-effect. Does not fire on non-email side effects (outbound-side-effect-idempotency) or on the content of the email.---# Email delivery verificationThree occurrences across two repos, all the same shape: the API returned success, the teambelieved the mail sent, and it silently never arrived. A corporate filter hard-blocked thewhole message over an attachment type; a wrong operator address hard-bounced once and theprovider's account-level suppression list swallowed every subsequent send to it, forever andsilently.## The rules- **2xx means queued.** Actual delivery status (delivered / bounced / suppressed) lives in the provider's dashboard or webhooks — read it there when a send matters, and after any recipient change.- **Check the suppression list as part of any "never arrived" diagnosis.** One hard bounce can suppress an address account-wide; subsequent sends return 2xx and go nowhere.- **Verify every recipient leg.** Multi-recipient flows fail per-leg: the customer email worked while every operator notification was suppressed. Checking one leg proves one leg.- **Confirm a mailbox exists before addressing it** — the suppression cascade starts with one send to a mistyped or unprovisioned address.- **Corporate filters block whole attachment classes.** `.html` attachments get the entire message rejected by M365/Mimecast-class filters: deliver links, attach only tolerated formats (a DOCX passes where an HTML file does not). For recipients on a firm's own domain, a recipient-side block can only be fixed by their IT allowlisting the sender.- **A sandbox sender reaches only verified addresses** — verify the sending domain before relying on any send in the field.## What this skill does not doIt does not choose failure semantics for the send-then-record path(outbound-side-effect-idempotency) and does not govern email content. It is the delivery legof verify-the-effect, split out because the mechanics are provider-specific.## WhyEmail is the one side effect whose failure mode is designed to be silent: providers acceptfirst and fail privately. Every incident in the evidence was discovered by a human noticingabsence, days later. Evidence: ICC LESSONS_LEARNED L-004, L-015; ASH CLAUDE.md DNS/Emaillesson (2026-05-21).

Frequently asked questions