eXplicit Consent-Identified Mail (XCIM)
XCIM is a draft email protocol for associating independently issued, identity-backed permission evidence with an application, a recipient, defined communication purposes, and currently authorized sending infrastructure.
XCIM is designed to complement SPF, DKIM, DMARC, ARC and existing unsubscribe mechanisms. It does not replace them, guarantee inbox placement, or establish universal legal compliance.
Introduction
Email authentication mechanisms can identify sending infrastructure and domain responsibility, but they do not independently establish that a particular recipient authorized a particular application to send a defined category of communication.
XCIM introduces a portable consent receipt issued by an independent issuer after identity-provider-backed authentication and an explicit decision presented on issuer-controlled infrastructure.
The signed receipt records the historical decision. Verification combines that receipt with current revocation state, application identity, sender-domain bindings, issuer policy, and receiver-local trust.
Read the protocol introduction →Current documents
| Document | Type | Status | Link |
|---|---|---|---|
| XCIM Protocol Overview | Informative | Available | View |
| XCIM Trust and Threat Model | Informative | Drafting | Not yet linked |
| XCIM Core Protocol v0.1 | Normative | Publication pending | Status |
| Receipt Format | Normative | Drafting | Not yet linked |
| Consent Manifest | Normative | Drafting | Not yet linked |
| Message Binding | Normative | Drafting | Not yet linked |
| Registry and Discovery | Normative | Drafting | Not yet linked |
| Transparency and Current State | Normative | Drafting | Not yet linked |
| Conformance Vectors | Test material | Not published | Not yet linked |
Relationship to the email stack
| Mechanism | Primary assertion |
|---|---|
| SPF | Which hosts are authorized to use a domain in the SMTP path. |
| DKIM | Which domain signed selected message content and headers. |
| DMARC | Alignment and handling policy for authenticated domain identities. |
| ARC | Preservation of authentication results across intermediaries. |
| List-Unsubscribe | A standardized mechanism for requesting subscription removal. |
| Double opt-in | A confirmation event normally retained within sender or ESP-controlled infrastructure. |
| XCIM | Independently issued, identity-backed, purpose-specific permission evidence with separately resolved current state. |
XCIM adds a positive permission signal. Receivers continue to evaluate malware, phishing, reputation, content, abuse patterns, and local policy.
Implementation and deployment
XCIM is designed for multiple independent issuers, local receiver trust, portable receipts, and verification that does not require a per-message call to a commercial issuer.
Reference architecture
- Issuer-hosted consent presentation
- Vendor-owned OAuth/OIDC application identity
- Signed consent receipts
- Application and sender-domain epochs
Verification distribution
- Append-only issuance and revocation events
- Public root anchoring profile
- Resolver-based local verification
- Receiver-local issuer trust policy
Emabled is the managed reference issuer and commercial implementation operated by We Are 14 Inc. It is not part of the normative protocol and is not the only issuer the protocol is designed to support.
Development and governance
XCIM was initiated by We Are 14 Inc. and remains under founder-led Phase 0 governance while the v0.1 byte-level formats, test vectors, security model, and reference implementation are completed.
XCIM is not currently an IETF standard, is not operated by an independent foundation, and does not yet claim a formal multi-stakeholder working group.
Related work
XCIM complements established email authentication and unsubscribe mechanisms, depends on OpenID Connect for the v1 identity profile, borrows transparency patterns from Certificate Transparency, and uses authenticated data structures for independently checkable history and state.
Review related protocols and standards →