Email Believability Index (EBI) Specification — v1.3

Status: Draft

Last Updated: 2026-01-11

Primary Goal: Provide a machine-verifiable, auditable, and actionable summary of email authentication and integrity signals (DKIM / SPF / DMARC / ARC), including security posture (vulnerabilities) — not just “pass/fail.”

EBI is designed to be:

• Deterministic (same input → same output)
• Auditable (verdict backed by evidence)
• Composable (embeddable into other systems)
• Policy-friendly (supports routing / allowlist / quarantine decisions)

1. Overview

1.1 What is EBI?

EBI (Email Believability Index) is a structured JSON response that summarizes the authenticity and integrity of an email message by analyzing:

• Domain alignment and policy enforcement (DMARC)
• Sender authorization (SPF)
• Message signing and integrity (DKIM)
• Forwarding/intermediate authentication chains (ARC)
• Known vulnerability conditions and weak configurations

EBI deliberately surfaces edge cases and vulnerabilities (e.g., weak DKIM canonicalization, partial body signing, relaxed alignment), allowing downstream systems to assess risk beyond basic “pass/fail.”

1.2 Analogy

EBI is analogous to OCSP for email authentication: a standardized response format that conveys a verdict and supporting evidence.

1.3 Non-goals

• EBI does not define how emails are transported or retrieved.
• EBI does not attempt to replace full raw forensic artifacts. It references or summarizes them.
• EBI does not include PII beyond what is required for authentication analysis.

1.4 Static .eml Limitations

When analyzing static .eml files (as opposed to live SMTP sessions), certain authentication mechanisms cannot be verified directly:

• SPF cannot be verified because .eml files lack the SMTP envelope information (MAIL FROM, connecting IP) required for SPF evaluation.
• DKIM can be verified if the message contains DKIM-Signature headers and the signing domain’s public key is retrievable via DNS.
• ARC chains provide a mechanism to recover original authentication results from forwarded messages.

2. Response Schema

2.1 Top-level Object

An EBI response MUST be a JSON object with the following structure.

{
  "ebi_version": "1.3",
  "request_id": "string",
  "timestamp": "RFC3339 string",
  "message_id": "string | null",

  "subject": "string | null",
  "from": "string | null",
  "to": ["string"],

  "verdict": { /* VerdictObject */ },
  "score": { /* ScoreObject */ },

  "dkim": { /* DKIMObject */ },
  "spf": { /* SPFObject */ },
  "dmarc": { /* DMARCObject */ },
  "arc": { /* ARCObject | null */ },

  "findings": [ /* FindingObject[] */ ],

  "metadata": { /* MetadataObject */ }
}

2.2 Field Reference

* score MAY be null only when the system cannot compute any reliable verdict (e.g., missing message headers, parser failure). In that case verdict.status SHOULD be INCONCLUSIVE.

3. Verdict Object

3.1 VerdictObject Schema

{
  "status": "AUTHENTIC" | "PARTIAL" | "FAILED" | "UNSAFE" | "INCONCLUSIVE",
  "confidence": "HIGH" | "MEDIUM" | "LOW",
  "code": "string",
  "summary": "string",
  "explanation": "string | null",
  "flags": ["string"]
}

3.2 status Semantics

3.3 confidence

Confidence reflects the reliability of the verdict given available evidence.

3.4 Verdict Codes

The code field provides machine-readable detail about why a particular verdict was reached.

3.5 Verdict Determination Priority

Implementations MUST evaluate verdict conditions in the following priority order (first match wins):

1. UNSAFE — If any DKIM signature has body_length.limited = true (l= tag present)
2. FAILED — If any DKIM signature has expired (finding DKIM_SIGNATURE_EXPIRED present) AND DKIM was NOT verified via ARC or Authentication-Results (see §3.6)
3. FAILED — If no DKIM signatures AND neither DKIM nor SPF passed (NO_AUTH_MECHANISMS)
4. FAILED — If DMARC result is FAIL
5. FAILED — If neither DKIM nor SPF passed but signatures were present (ALL_AUTH_FAIL)
6. PARTIAL — If DKIM passed but uses weak cryptography (SHA-1), confidence=MEDIUM
7. AUTHENTIC — If DKIM AND SPF AND DMARC all passed
8. PARTIAL — If DKIM OR SPF passed (but not all three), confidence=MEDIUM
9. INCONCLUSIVE — Otherwise, confidence=LOW

3.6 Expired Signatures with ARC/Authentication-Results

When DKIM authentication is derived from a trusted source (ARC chain or Authentication-Results header), an expired signature SHOULD NOT force a FAILED verdict. The rationale:

• The x= expiry tag limits replay window — preventing reuse of signed emails after a certain time
• ARC and Authentication-Results record what authentication looked like at the time of receipt
• If the receiving server verified DKIM while the signature was valid, subsequent expiry is irrelevant
• The authentication already happened; the expiry is historical fact, not current failure

In this case, the DKIM_SIGNATURE_EXPIRED finding remains (severity HIGH) as evidence, but verdict determination continues to the next priority level.

4. Score Object

4.1 Purpose

The score provides a single numeric projection of believability for UI display and policy thresholding.

Important: the score is not a replacement for the richer EBI structure. It is derived from the verdict and findings.

4.2 ScoreObject Schema

{
  "value": 0,
  "scale": { "min": 0, "max": 100 },
  "band": "EXCELLENT" | "GOOD" | "CAUTION" | "DANGEROUS" | "UNKNOWN",
  "method": "EBI_SCORE_V1",
  "components": {
    "base": 0,
    "finding_penalty": 0,
    "confidence_adjustment": 0
  },
  "notes": "string | null"
}

4.3 Bands

4.4 Scoring Method: EBI_SCORE_V1

Step A — Base score from verdict.status

Step B — Finding penalties

For each element in findings, subtract:

Total finding penalty MUST be capped at -60.

Step C — Confidence adjustment

Step D — Clamp

score = clamp(base + finding_penalty + confidence_adjustment, 0, 100)

Step E — Band mapping

Band is determined from the ranges in §4.3.

5. Findings

5.1 FindingObject Schema

{
  "id": "string",
  "severity": "CRITICAL" | "HIGH" | "MEDIUM" | "LOW" | "INFO",
  "title": "string",
  "summary": "string",
  "details": "string | null",
  "evidence": {
    "type": "HEADER" | "DNS" | "DERIVED" | "BODY" | "OTHER",
    "key": "string | null",
    "value": "string | null"
  },
  "recommendation": "string | null"
}

5.2 Finding IDs

Finding IDs are stable strings suitable for rule-based policy. See §13 for the complete registry.

6. DKIM

6.1 DKIMObject Schema

{
  "result": "PASS" | "FAIL" | "NONE" | "TEMPERROR" | "PERMERROR",
  "from_domain_match": true,
  "domain": "string | null",
  "selector": "string | null",
  "signatures": [
    {
      "domain": "string",
      "selector": "string",
      "result": "PASS" | "FAIL" | "TEMPERROR" | "PERMERROR",
      "canonicalization": {
        "header": "simple" | "relaxed" | "unknown",
        "body": "simple" | "relaxed" | "unknown"
      },
      "body_length": {
        "limited": false,
        "value": null
      },
      "timestamp": "RFC3339 string | null",
      "hash_algo": "rsa-sha256" | "rsa-sha1" | "ed25519-sha256" | "unknown",
      "signed_headers": ["string"]
    }
  ]
}

6.2 Field Semantics

result

The effective DKIM result. This may be derived from (in priority order):

1. Direct verification — Cryptographic verification of DKIM-Signature headers in the message
2. Authentication-Results header — If direct verification fails but the message contains an Authentication-Results header showing dkim=pass (see §6.4)
3. ARC chain — If no direct DKIM signatures but a valid ARC chain exists with dkim=pass at the origin (i=1)

When the result comes from Authentication-Results, metadata.raw.evidence_refs SHOULD include "Authentication-Results". When the result comes from ARC, metadata.raw.evidence_refs SHOULD include "ARC-Authentication-Results".

from_domain_match

Indicates whether the DKIM signing domain (d=) matches or is a parent of the From header domain. This is a DKIM-level observation independent of DMARC evaluation.

• true: The d= domain matches the From domain (exact or subdomain)
• false: No match

body_length.limited

Indicates whether the DKIM signature uses the l= tag to limit body signing.

• limited: false — Entire body is signed. Safe.
• limited: true — Only first N bytes signed. Attacker can append content. This MUST generate a DKIM_PARTIAL_BODY_SIGNED finding with CRITICAL severity and result in UNSAFE verdict.

6.3 Guidance

• Weak DKIM conditions SHOULD be expressed via findings (e.g., relaxed body canonicalization, partial body signing, sha1).
• When body_length.limited is true, the value field contains the byte count from the l= tag.

6.4 Authentication-Results Fallback (RFC 8601)

When analyzing forwarded emails (e.g., emails forwarded as attachments), DKIM signatures may fail re-verification due to transit modifications such as:

• Header reordering or whitespace normalization
• Line ending changes
• Character encoding adjustments

However, the original receiving server verified DKIM successfully at the time of receipt and recorded this in the Authentication-Results header (defined by RFC 8601).

Implementations SHOULD trust Authentication-Results when ALL of the following conditions are met:

1. The message contains DKIM-Signature headers (signatures were present)
2. Direct cryptographic verification fails or returns neutral
3. An Authentication-Results header exists with dkim=pass
4. The passing DKIM domain in Authentication-Results matches a signature’s d= domain

When Authentication-Results is used: - A finding with ID DKIM_VIA_AUTH_RESULTS (severity INFO) SHOULD be added - metadata.raw.evidence_refs SHOULD include "Authentication-Results"

Security note: The Authentication-Results header represents a trusted assertion from the original receiving mail server. This is comparable to trusting ARC chains — both rely on the integrity of headers from upstream servers.

7. SPF

7.1 SPFObject Schema

{
  "result": "PASS" | "FAIL" | "SOFTFAIL" | "NEUTRAL" | "NONE" | "TEMPERROR" | "PERMERROR",
  "domain": "string | null",
  "mail_from": "string | null",
  "helo": "string | null",
  "ip": "string | null",
  "explanation": "string | null",
  "dns_lookups": 0
}

7.2 Static .eml Limitations

For static .eml files, SPF cannot be verified directly because:

• The SMTP envelope sender (MAIL FROM) is not preserved in .eml format
• The connecting IP address is not available

In this case: - result SHOULD be "NONE" unless inferred from a valid ARC chain - A finding with ID SPF_NOT_VERIFIABLE (severity INFO) SHOULD be added

7.3 SPF from ARC or Authentication-Results

If a valid ARC chain exists (see §9) and the ARC-Authentication-Results at instance i=1 contains SPF results, those MAY be used as the effective SPF result.

Alternatively, if the message contains an Authentication-Results header with SPF results (see §6.4 for trust model), those MAY be used.

The explanation field SHOULD note "From ARC chain" or "From Authentication-Results header" as appropriate.

7.4 Guidance

• DNS lookup count may matter for risk and operational debugging.
• SPF neutrality or softfail SHOULD appear as findings when relevant to policy.

8. DMARC

8.1 DMARCObject Schema

{
  "result": "PASS" | "FAIL" | "NONE" | "TEMPERROR" | "PERMERROR",
  "policy": "none" | "quarantine" | "reject" | "unknown",
  "pct": 100,
  "alignment": {
    "dkim": true,
    "spf": true,
    "mode": "relaxed" | "strict" | "unknown"
  },
  "domain": "string | null",
  "rua": ["string"],
  "ruf": ["string"],
  "explanation": "string | null"
}

8.2 DMARC Result Derivation

The effective DMARC result may come from multiple sources (in priority order):

1. Authentication-Results header — If message contains Authentication-Results with dmarc= result (see §6.4 for trust model)
2. ARC chain — If valid ARC chain exists with dmarc=pass at origin (i=1)
3. Direct DMARC check — Via DNS lookup of _dmarc.<from-domain>
4. Implicit pass — If DKIM alignment passes (signing domain matches From domain) and DKIM passes, DMARC is considered to pass even without explicit DMARC record

When the result comes from Authentication-Results, the explanation field SHOULD note "Determined from Authentication-Results header".

8.3 Alignment for Static .eml

For static .eml files: - alignment.dkim — Can be determined (signing domain vs From domain) - alignment.spf — SHOULD be false or null (cannot verify SPF alignment without envelope)

9. ARC (Authenticated Received Chain)

9.1 Overview

ARC provides a mechanism to preserve authentication results across mail forwarding. When an email is forwarded, the original DKIM signature may break, but ARC headers record what authentication looked like at each hop.

EBI uses ARC to recover original authentication results when direct verification is not possible.

9.2 ARCObject Schema

{
  "result": "PASS" | "FAIL" | "NONE" | "TEMPERROR" | "PERMERROR",
  "chain_valid": true,
  "instances": [
    {
      "i": 1,
      "cv": "pass" | "fail" | "none" | "unknown",
      "auth_results": "string | null",
      "signing_domain": "string | null"
    }
  ]
}

9.3 Field Semantics

chain_valid

Indicates whether the ARC chain is trustworthy:

• true — All instances have cv of pass or none (for i=1)
• false — Any instance has cv=fail

CRITICAL: Authentication results from ARC MUST NOT be trusted if chain_valid is false.

instances

Array of ARC set instances, sorted by i value (ascending). Each instance represents a hop in the forwarding chain.

• i — Instance number (1 = origin, 2 = first forwarder, etc.)
• cv — Chain validation status at this hop
• auth_results — Summary of authentication results (e.g., "dkim=pass spf=pass dmarc=pass")
• signing_domain — Domain that signed this ARC set (d= from ARC-Seal)

9.4 Trusting ARC Results

When chain_valid is true, the authentication results from instance i=1 (the origin) MAY be used as effective results:

IF arc.chain_valid = true AND arc.instances[0].i = 1:
  effectiveDkim = parseResult(arc.instances[0].auth_results, "dkim")
  effectiveSpf = parseResult(arc.instances[0].auth_results, "spf")  
  effectiveDmarc = parseResult(arc.instances[0].auth_results, "dmarc")

9.5 ARC Parsing

ARC headers are parsed from:

1. ARC-Seal — Contains i=, cv=, d= (signing domain)
2. ARC-Authentication-Results — Contains original auth results at each hop

Example ARC-Authentication-Results:

ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.d=example.com;
       spf=pass smtp.mailfrom=example.com;
       dmarc=pass header.from=example.com

10. Metadata

10.1 MetadataObject Schema

{
  "source": {
    "system": "string",
    "version": "string | null"
  },
  "analysis": {
    "mode": "LIVE" | "BATCH" | "TEST",
    "elapsed_ms": 0
  },
  "raw": {
    "header_hash": "string | null",
    "body_hash": "string | null",
    "evidence_refs": ["string"]
  }
}

10.2 Guidance

• header_hash and body_hash allow correlation without storing raw content.
• evidence_refs MAY contain internal URIs to stored raw artifacts.
• When authentication results come from ARC, evidence_refs SHOULD include "ARC-Authentication-Results".

11. Implementation Requirements

11.1 Determinism

Given identical inputs, an implementation MUST produce identical EBI outputs (except for timestamp and request_id).

11.2 Evidence-first

Every non-trivial verdict decision SHOULD be supported by either:

• an explicit auth result (SPF/DKIM/DMARC/ARC)
• or a corresponding finding with evidence

11.3 ARC Chain Validation

Implementations MUST:

• Parse all ARC-Seal headers to extract cv= values
• Set chain_valid = false if ANY instance has cv=fail
• Only trust ARC authentication results when chain_valid = true

11.4 Backward Compatibility

• Clients MUST treat unknown fields as ignorable.
• Fields MAY be added in future versions.

12. Example Response

This example demonstrates a forwarded email where original DKIM verification happens via ARC chain.

{
  "ebi_version": "1.3",
  "request_id": "req_a1b2c3d4",
  "timestamp": "2026-01-11T10:30:00Z",
  "message_id": "<forwarded-msg@example.com>",

  "subject": "Important Document",
  "from": "sender@example.com",
  "to": ["recipient@company.com"],

  "verdict": {
    "status": "AUTHENTIC",
    "confidence": "HIGH",
    "code": "ALL_PASS",
    "summary": "All authentication mechanisms passed.",
    "explanation": "Email appears genuine.",
    "flags": []
  },

  "score": {
    "value": 85,
    "scale": {"min": 0, "max": 100},
    "band": "GOOD",
    "method": "EBI_SCORE_V1",
    "components": {
      "base": 95,
      "finding_penalty": -10,
      "confidence_adjustment": 0
    },
    "notes": "AUTHENTIC + 2 findings"
  },

  "dkim": {
    "result": "PASS",
    "from_domain_match": true,
    "domain": "example.com",
    "selector": null,
    "signatures": []
  },

  "spf": {
    "result": "PASS",
    "domain": "example.com",
    "mail_from": null,
    "helo": null,
    "ip": null,
    "explanation": "From ARC chain",
    "dns_lookups": 3
  },

  "dmarc": {
    "result": "PASS",
    "policy": "quarantine",
    "pct": null,
    "alignment": {"dkim": true, "spf": false, "mode": "relaxed"},
    "domain": "example.com",
    "rua": [],
    "ruf": [],
    "explanation": "Determined from ARC authentication chain"
  },

  "arc": {
    "result": "PASS",
    "chain_valid": true,
    "instances": [
      {
        "i": 1,
        "cv": "none",
        "auth_results": "dkim=pass spf=pass dmarc=pass",
        "signing_domain": "forwarder.com"
      },
      {
        "i": 2,
        "cv": "pass",
        "auth_results": "dkim=none spf=none dmarc=none",
        "signing_domain": "mx.company.com"
      }
    ]
  },

  "findings": [
    {
      "id": "DKIM_VIA_ARC",
      "severity": "INFO",
      "title": "DKIM verified via ARC chain",
      "summary": "Original DKIM signature was verified by forwarder.com.",
      "details": "The email was forwarded and the original DKIM signature was replaced with an ARC chain.",
      "evidence": {"type": "HEADER", "key": "ARC-Authentication-Results", "value": "dkim=pass"},
      "recommendation": "ARC provides trustworthy authentication for forwarded emails."
    },
    {
      "id": "DKIM_RELAXED_BODY_CANON",
      "severity": "MEDIUM",
      "title": "Relaxed body canonicalization",
      "summary": "Relaxed canonicalization permits whitespace modifications without invalidating signature.",
      "details": null,
      "evidence": {"type": "DERIVED", "key": "dkim.canonicalization.body", "value": "relaxed"},
      "recommendation": "Consider simple canonicalization for high-integrity messages."
    }
  ],

  "metadata": {
    "source": {"system": "ebi-service", "version": "1.2.0"},
    "analysis": {"mode": "LIVE", "elapsed_ms": 156},
    "raw": {
      "header_hash": null,
      "body_hash": null,
      "evidence_refs": ["ARC-Authentication-Results"]
    }
  }
}

13. Finding ID Registry

This section is normative. Implementations SHOULD use these exact IDs.

13.1 DKIM Findings

13.2 SPF Findings

13.3 DMARC Findings

13.4 ARC Findings

14. Changelog

v1.3

• Added Authentication-Results (RFC 8601) as fallback source for DKIM/SPF/DMARC when direct verification fails (§6.4)
• Updated DKIM result derivation priority to include Authentication-Results (§6.2)
• Updated SPF and DMARC sections to reference Authentication-Results as a source (§7.3, §8.2)
• Added new finding: DKIM_VIA_AUTH_RESULTS
• Improved support for forwarded-as-attachment emails where DKIM signatures break in transit
• Expired signatures no longer force FAILED verdict when ARC or Authentication-Results vouches for DKIM (§3.6)

v1.2

• Added comprehensive ARC chain parsing and trust model (§9)
• Documented verdict determination priority order (§3.5)
• Added verdict codes table (§3.4)
• Documented static .eml limitations for SPF (§7.2)
• Added SPF/DMARC result derivation from valid ARC chains (§7.3, §8.2)
• Added new findings: DKIM_VIA_ARC, SPF_NOT_VERIFIABLE
• Clarified DKIM result can come from direct verification OR ARC (§6.2)
• Added ARC_CHAIN_FAIL finding (§13.4)
• Promoted Finding ID Registry to normative (§13)
• Improved example to show ARC-based authentication

v1.1

• Added score object and scoring method (EBI_SCORE_V1).
• Added message_id to top-level fields.
• Renamed dkim.aligned to dkim.from_domain_match for clarity.
• Renamed body_length.present to body_length.limited with inverted semantics.
• Renamed BODY_LENGTH_LIMIT finding to DKIM_PARTIAL_BODY_SIGNED.
• Clarified that partial body signing (l= tag present) is the vulnerability, not its absence.
• Clarified verdict semantics for UNSAFE.
• Improved schema structure and implementation requirements.
• Added common finding IDs appendix with severity guidance.

v1.0

• Initial draft.