Skip to content
cccskills
FreePublished on GitHub

cloudflare-email-service

Cloudflare Email Service(Email Sending + Email Routing)でトランザクションメールの送受信を実装するスキル。

Workers bindingまたはREST APIによるメール送信、Email Routing、Agents SDKのemail handler、Workers・Node.js・Python・Go等への組み込みで使う。

到達性、SPF/DKIM/DMARC、wrangler email設定、MCP email tools、coding agentからのメール送信も対象。「Workerにメール機能を追加」のような依頼でも、重要な設定要件があるため必ず使用する。

The English summary is being prepared. Showing the original description.

Works withCloudflare
See how to install

Files included (6)

  • SKILL.md9.2 KB
  • references/cli-and-mcp.md3.9 KB
  • references/deliverability.md8.9 KB
  • references/rest-api.md5.9 KB
  • references/routing.md7.3 KB
  • references/sending.md9.3 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

本ファイルは cloudflare/skills(Apache-2.0)を基に改変しています。詳細は リポジトリルートの ATTRIBUTION.md を参照。

Cloudflare Email Service

Cloudflare Email Service、Email Routing、Email Sendingの仕様は更新されるため、すべての関連タスクで事前知識より最新情報の取得を優先する。

Cloudflare Email Serviceは、Cloudflare platform上でトランザクションメールを送信し、受信メールをroutingする。変更の速い製品なので、必ず現行仕様を取得してから進める。

本Skillと以下の一次情報が食い違う場合は、必ず一次情報を正とする。 Cloudflare docs、REST API spec、@cloudflare/workers-types、Agents SDK repoが正本であり、本Skillは作業開始用のガイドである。

Accountを伴うドメイン有効化やAPI操作の前には、Skill cloudflareで対象Accountを確定する。Wrangler CLIを実行するときはSkill wranglerの現行commandと安全規律に従う。本Skill内でAccount選択やWrangler共通規律を再定義しない。

最新情報の取得先

正本は cloudflare Skill の「最新情報の取得先」(docs MCP 第一手段、不通時の復旧、workers-types / config-schema の取得方法)。ここには本Skill固有の取得先だけを書く。

取得先取得方法使う場面
Cloudflare docs (MCP)cloudflare-docs MCPで email-service / email routing / send_email を検索既定の第一手段。API reference、上限、価格、最新機能
Email Service docs (Web)https://developers.cloudflare.com/email-service/MCP不通時
REST API spechttps://developers.cloudflare.com/api/resources/email_sendingEmail Sending REST APIのOpenAPI spec
Agents SDK docshttps://github.com/cloudflare/agents/tree/main/docsのdocs/email.mdを取得Agents SDKのemail handling

最初に前提条件を確認する

メール処理コードを書く前に、次の3点を確認する。

  1. ドメインが有効化済みか: pnpm wrangler email sending listでEmail Sendingが有効なドメインを確認する。対象ドメインがなければpnpm wrangler email sending enable userdomain.comを使うか、詳細をcli-and-mcp.mdで確認する。
  2. Bindingが設定済みか: Workersではwrangler.jsoncにsend_emailがあるか確認する。
  3. postal-mimeが必要か: メールの受信・解析を行う場合だけpnpm ls postal-mimeで確認する。

要件から実装方式を選ぶ

次の表から要件に合う経路を1つ選び、対応するreferenceだけを読む。

やりたいこと実装経路Reference
Cloudflare Workerからメールを送るWorkers binding(API key不要)sending.md
Cloudflare Agents SDKのAI agentからメールを送るAgent classのonEmail() + replyToEmail()sending.md
外部アプリやagentからメールを送る(Node.js、Go、Python等)Bearer tokenを使うREST APIrest-api.md
coding agentからメールを送る(Claude Code、Cursor、Copilot等)MCP tools、wrangler CLI、またはREST APIcli-and-mcp.md
受信メールを処理する(Email Routing)Workers email() handlerrouting.md
Email Sending / Email Routingを有効化するwrangler email sending enable / wrangler email routing enable、またはDashboardcli-and-mcp.md
到達性を改善し迷惑メールフォルダを避けるauthentication、content、compliancedeliverability.md

最短実装 — Workers Binding

wrangler.jsoncにbindingを追加し、env.EMAIL.send()を呼ぶ。fromのドメインは事前にpnpm wrangler email sending enable yourdomain.comで有効化しておく。

// wrangler.jsonc
{ "send_email": [{ "name": "EMAIL" }] }
const response = await env.EMAIL.send({
  to: "user@example.com",
  from: { email: "welcome@yourdomain.com", name: "My App" },
  subject: "Welcome!",
  html: "<h1>Welcome!</h1>",
  text: "Welcome!",
});

WorkersではAPI keyが不要なbindingを推奨する。利用者がWorker内からREST APIを使う理由を明示した場合(既存のAPI token workflowを使う等)は、rest-api.mdに従ってREST APIも利用できる。

完全なAPI、batch send、attachment、custom header、restricted binding、Agents SDK integrationはsending.mdを読む。

最短実装 — REST API

Workers以外のアプリ、または利用者が明示的にREST APIを指定したWorkersで使う。Workers bindingとの主な違いは次のとおり。

  • Endpoint: POST https://api.cloudflare.com/client/v4/accounts/{account_id}/email/sending/send
  • from objectはemailではなくaddressを使う: { "address": "...", "name": "..." }
  • replyToはreply_to (snake_case)
  • Responseは{ delivered: [], permanent_bounces: [], queued: [] }を返す(messageIdではない)

curl例、response format、error handlingはrest-api.mdを読む。

よくある間違い

間違い原因対処
wrangler configにsend_email bindingがないEmail ServiceはAPI keyではなくbindingを使うwrangler.jsoncに"send_email": [{ "name": "EMAIL" }]を追加
未検証domainから送信する初回送信前にEmail Sendingへのdomain登録が必要wrangler email sending enable userdomain.comを実行、またはDashboardで有効化
email handlerでmessage.rawを2回読むraw streamは1度しか読めず、2回目は空になる最初にbuffer化: const raw = await new Response(message.raw).arrayBuffer()
text fieldがない(HTMLのみ)plain textしか表示しないclientがあり、spam scoreにも影響するhtmlとtextを必ず両方用意
marketing/bulk sendに使うEmail Serviceはtransactional email用newsletterやcampaignは専用marketing email platformを使う
未検証の宛先へforwardするmessage.forward()は検証済みaddressに限定wrangler email routing addresses create user@gmail.comまたはDashboardで追加
架空addressでテストする存在しないaddressからのbounceでsender reputationが下がる開発中も自分が管理する実addressを使う
API tokenをソースコードに直書きするcommitされて漏えいするenvironment variableまたはCloudflare secretsを使う
from domain要件を無視するfromはEmail Serviceに登録済みのdomainである必要があるdomainを先に検証し、anything@that-domain.comから送信
REST APIのfromでemail keyを使うREST APIはemailではなくaddressを使うRESTは{ "address": "...", "name": "..." }、Workersは{ "email": "...", "name": "..." }
REST APIでreplyToを使うREST APIのfieldはsnake_caseREST APIはreply_to、Workers bindingはreplyTo

詳細リファレンス

要件に対応するreferenceだけを読む。すべてを一度に読み込まない。

完了報告

実装・検証後は、次の順で日本語の報告を返す。

  1. できるようになったこと(送信 / 受信 / routing / 到達性のどれか)
  2. 採用した経路(Workers binding / REST API / Email Routing / MCP tools)
  3. 確認したこと(domain有効化、binding、実送受信、error handling)
  4. 利用者に残る操作(Dashboard操作やdomain検証がある場合のみ)

token、secret、完全なAccount IDは報告に含めない。

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。

The English summary is being prepared. Showing the original description.

daishiman/harness-dev10Updated Oct 18, 2026

Webアプリの準備→要件定義→設計→実装→公開→品質ゲートを実行する内部オーケストレーター。Claude Codeの /build-app /improve-app、Codexの $build-app / $improve-app から明示的に委譲された場合、custom agent起動時、または利用者が $app-orchestrator を明示した場合だけ使用する。一般のアプリ相談から暗黙起動しない。

The English summary is being prepared. Showing the original description.

daishiman/harness-dev10Updated Oct 18, 2026

run-extract-blueprint が生成した章別ブループリントの忠実性を独立 context で評価したいとき、事実/推測区別と粒度と被覆を検証し draft_hash に束縛した PASS/FAIL verdict をローカル品質ゲート (C01 の周回内の受入判定・差し戻し) へ渡したいときに使う。

The English summary is being prepared. Showing the original description.

daishiman/harness-dev10Updated Oct 18, 2026

確認点で利用者が見る深さを選んだあと打ち合わせ資料を作り手とは別の目で確かめたいとき、正確さ・言葉・見た目・シンプルさの指摘を資料の編集なしで受け取りたいときに使う。

The English summary is being prepared. Showing the original description.

daishiman/harness-dev10Updated Oct 18, 2026

生成した handout 資料が初心者に伝わるか読みやすさレビューを依頼したいとき、独立 context のレビュアーから指摘と根拠つきの verdict を回収したいときに使う。

The English summary is being prepared. Showing the original description.

daishiman/harness-dev10Updated Oct 18, 2026

Notion ページを描画する直前に粒度を検証したいとき、info-collector-agent ページと同等の section 充足度を section_canonical_map 基準で機械検証したいときに使う。

The English summary is being prepared. Showing the original description.

daishiman/harness-dev10Updated Oct 18, 2026

See all skills by daishiman

Report a problem with this skill