Cron配信安全ゲート
自動送信は、以下の4つの高コストな方法で失敗します：誤った送信者ID（SPF/DKIM不一致 → スパムフォルダ）、誤った対象者（既に拒否した人）、レート上限なし（暴走ループ → ドメイン汚染）、ゾンビcron（キャンペーン終了後も送信を続ける）。このゲートはこれらすべてを10分で捕捉します。
ゲート（5項目すべてを通過する必要があります）
- ID：送信者アドレス + 表示名がこのキャンペーンに対して有効ですか？以下を確認：
- FromヘッダーがRFC-5322準拠であること — カンマを含む表示名は二重引用符で囲む必要があります（
"Last, First" <addr>）。そうしないとAPIは422エラーを返します。 - 送信ドメインに、選択したプロバイダー向けのSPF/DKIMが設定されていること。
- API呼び出しにカスタム
User-Agentを使用していること（素のurllib/requestsのデフォルトはボットブロックされます。例：Cloudflare 1010 — 本文を読み、認証失敗と決めつけないでください）。
- FromヘッダーがRFC-5322準拠であること — カンマを含む表示名は二重引用符で囲む必要があります（
- 対象者：リストはオプトインまたは公開されたプロフェッショナルコンテキストからのみ構築します。以前にオプトアウトした人を除外します。購入リストは使用しません。キャンペーンが明示的にSMS対象でない限り、電話番号は使用しません。
- 上限：実行ごとのハードキャップ（最大送信数）、1時間あたりのハードキャップ、およびグローバルキルスイッチ（cronが各送信前にチェックする1つの環境変数またはファイル）。上限なし = 有効にしないでください。
- コンテンツ：欺瞞的な主張なし、偽の緊急性なし、機能する購読解除/オプトアウト経路があること、メッセージが送信組織を明示していること。
- ライフサイクル：キャンペーンに終了日があること。cronが自動無効化されるか、オペレーターのカレンダーに見直しが予定されていること。「一時停止」状態は実際に機能していること（スケジューラーで確認し、フラグから推測しない）。
停止を意味する危険信号
- 「開封しなかった人には返信があるまで再送信しよう。」
- リストが、連絡先収集目的でディレクトリをスクレイピングして取得されたもの。
- 誰がコピーを承認したかを誰も言えない。
- cronが個人アドレスから送信している。
対象外
- トランザクションメール（既存顧客への領収書、配送通知）。
- 人間が送信ボタンを押す、人間参加型のキャンペーン。
例
依頼：「移行後、火曜日の配信cronを再度有効にしてください。」 以前：そのまま有効にし、30件のオプトアウトを含む古いリストに400通送信していることを発見。 以後：ゲートが2/5を捕捉 — 対象者リストが古く（オプトアウトが存在）、キルスイッチが未設定。両方を修正し（リスト再構築、環境キルスイッチ追加）、その後有効化。
バージョン
1.0.0 — DDGスターターシリーズ（配信cronを苦労して運用した経験から）。