{"id":16744,"plugin_id":"plugins_6a67e30422d48191b8b02b1685c38401","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:13:43.713Z","digest":"0bf0646bf15582ea251dcf37996af3a00a8ade8a40f667803f4cd0fdbfecd74a","against":null,"payload":{"description":"Design and implement MailChannels production controls for downstream or multi-tenant outbound email. Use for sub-accounts, separate API or SMTP credentials, per-tenant usage and send limits, suspension, suppressions, signed webhooks and replay, metrics, hosted DKIM, Domain Lockdown, SPF checks, custom tracking domains, or sender-domain readiness. Verify current account limits and do not claim reputation isolation.","included_files":[{"relative_path":"agents/openai.yaml","size_in_bytes":287},{"relative_path":"references/control-plane.md","size_in_bytes":2905}],"name":"mailchannels-platform-operations","skill_md_contents":"---\nname: mailchannels-platform-operations\ndescription: Design and implement MailChannels production controls for downstream or multi-tenant outbound email. Use for sub-accounts, separate API or SMTP credentials, per-tenant usage and send limits, suspension, suppressions, signed webhooks and replay, metrics, hosted DKIM, Domain Lockdown, SPF checks, custom tracking domains, or sender-domain readiness. Verify current account limits and do not claim reputation isolation.\n---\n\n# MailChannels Platform Operations\n\nUse this skill for the delivery control plane regardless of application\nlanguage. Read\n[references/control-plane.md](references/control-plane.md) before implementing\nsub-accounts, webhooks, quotas, or domain operations.\n\n## Model boundaries first\n\nMap each tenant, customer, workload, or trust boundary to:\n\n- an authenticated application identity and owner;\n- an account or sub-account credential;\n- an application budget plus any provider-side limit;\n- a suppression and webhook scope;\n- an active, paused, suspended, or closed lifecycle state;\n- auditable credential issuance, rotation, and revocation.\n\nTreat separate credentials, limits, suppressions, and webhooks as operational\nboundaries. Do not call them reputation isolation unless current MailChannels\ndocumentation or support confirms the exact required behavior.\n\n## Provision safely\n\n1. Verify current account limits and resource behavior.\n2. Create a stable, non-secret tenant-to-provider mapping.\n3. Issue the narrowest credential into a secret store and retain only metadata.\n4. Set a provider-side send limit and an application-owned atomic budget.\n5. Enroll and validate the correct webhook scope.\n6. Configure DKIM and other required DNS, then run the domain check.\n7. Test independent pause, suspension, credential rotation, and recovery.\n\n## Operate delivery state\n\n- Treat send acceptance as submission rather than final delivery.\n- Verify raw webhook bytes, digest, freshness, key ID, and RFC 9421 Ed25519\n  signature before parsing events.\n- Store event identity transactionally before applying side effects.\n- Inspect and resend failed webhook batches only after confirming receiver\n  failure; never replay business effects blindly.\n- Reconcile complaints, opt-outs, and permanent failures with the correct\n  suppression scope.\n- Alert before tenant or parent capacity blocks critical traffic.\n\nTreat domain checks as configuration evidence, not a delivery or inbox-placement\nguarantee.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}