← Back to Research

Existing Standards

1. DKIM (DomainKeys Identified Mail)

RFC: 6376 Status: Widely deployed

What it does: - Domain-level signing - Message integrity verification - Public keys in DNS

Limitations: - Domain-wide keys (not per-user) - No sender authorization proof - No revocation mechanism beyond DNS TTL - Breaks with message modification (forwarding)

Relation to our work: We extend DKIM's cryptographic approach to per-user granularity

2. ARC (Authenticated Received Chain)

RFC: 8617 Status: Growing adoption (Gmail, Yahoo support)

What it does: - Preserves authentication through forwarding - Chain of custody for message path - Each hop signs the previous authentication

Limitations: - Still domain-based (not user-based) - Focused on preserving DKIM/SPF through forwarding - No sender authorization model

Relation to our work: Our "chain" field is inspired by ARC's approach

3. S/MIME

Standard: RFC 8551 Status: Niche usage, mostly enterprise

What it does: - End-to-end message signing - Per-user certificates - PKI-based trust model

Limitations: - Requires certificate infrastructure - Heavy weight (X.509) - Poor UX (certificate management) - Not SMTP-level (application layer)

Relation to our work: Similar goal (user-level auth) but we operate at SMTP level for better compatibility

4. DANE (DNS-Based Authentication of Named Entities)

RFC: 7672 (SMTP) Status: Limited adoption (you're implementing this!)

What it does: - TLSA records in DNSSEC - Certificate pinning - MTA-to-MTA authentication

Limitations: - Transport security, not message authentication - Requires DNSSEC - Server-level, not user-level

Relation to our work: Complementary - DANE secures transport, we authenticate sender

Related Proposals & Research

1. PGP/GPG for Email

Status: Declining usage

Lessons learned: - Key management is the hardest problem - Must be transparent to users - Web of trust doesn't scale - Simpler is better

How we differ: - Server-managed keys (easier UX) - Short-lived subkeys (reduce key compromise impact) - DNS publication (no key servers needed)

2. Brand Indicators for Message Identification (BIMI)

Status: Emerging standard

What it does: - Visual indicator (logo) for authenticated senders - Requires DMARC + VMC (Verified Mark Certificate)

Relation to our work: BIMI proves you need strong auth for value-add features

3. MTA-STS (SMTP MTA Strict Transport Security)

RFC: 8461 Status: Growing adoption

What it does: - Policy file for TLS enforcement - Prevents downgrade attacks - Delivered via HTTPS

Relation to our work: Similar pattern - policy via HTTPS (.well-known/mta-sts.txt vs our revocation list)

4. Autocrypt

Status: Niche (Delta Chat, some clients)

What it does: - Automatic key exchange via email headers - Opportunistic encryption - No PKI required

Lessons learned: - Key exchange in-band works - Simplicity drives adoption - Client-side key management viable

How we differ: We're SMTP-level, they're application-level

Academic Research

"Practical Email Authentication" (2019)

Authors: Foster, Larson, et al.

Key findings: - DKIM adoption ~85% of major domains - SPF ~90% but often misconfigured - DMARC ~30% (growing fast) - Authentication reduces spam by ~60%

Implications: Strong foundation to build on

"Measuring DANE TLSA Adoption" (2021)

Source: APWG

Key findings: - DANE adoption <1% of mail servers - Chicken-and-egg problem (requires DNSSEC) - When used, reduces MITM risk significantly

Implications: We face similar bootstrap challenges

"User Key Management in Email" (2018)

Authors: Ruoti, et al.

Key findings: - Users won't manage keys manually - Automation is essential - Trust-on-first-use (TOFU) acceptable for most users - Short-lived keys reduce concerns

Implications: Our subkey rotation model aligns with research

Industry Implementations

1. Google Authenticated Mail

Status: Internal research (not public)

Rumored features: - Per-user authentication for Gmail - Integration with account security - Likely feeds into BIMI

2. Proton Mail

Approach: End-to-end PGP

Lessons: - Works well in closed ecosystem - Struggles with external email - Key management still a UX challenge

3. Virtru / DataMotion

Approach: Gateway-based encryption

Lessons: - Enterprise adoption requires transparency - Compliance features drive adoption - Centralized key management accepted in enterprise

Open Questions & Research Gaps

1. Key Discovery

Problem: How do senders find recipient's preferred authentication method?

Options: - DNS SRV records - MX-level capability advertisement - In-band negotiation

Our approach: DNS publication (simple, cacheable)

2. Key Rotation

Problem: How often should keys rotate?

Research needed: - Balance security vs operational overhead - Measure impact of rotation on deliverability - Determine optimal subkey lifetime

Our proposal: 30 days (data-driven decision needed)

3. Revocation Propagation

Problem: How quickly can revocation propagate?

Challenge: - DNS caching (TTL) - Policy service caching - Network partitions

Our approach: Well-known HTTPS endpoint + aggressive caching (5min TTL)

4. Forwarding & Mailing Lists

Problem: How to preserve authentication through transformation?

ARC solves this for DKIM, but: - Mailing lists often break signatures - Forwarding services may not add ARC

Our approach: Chain field similar to ARC, but at SMTP level

Standards Track Path

Potential RFC Process

  1. Internet-Draft (6 months)
  2. Publish specification
  3. Gather community feedback

  4. Reference implementation

  5. IETF WG (12 months)

  6. Present at MailAuth WG
  7. Iterate based on feedback

  8. Security review

  9. Proposed Standard (18 months)

  10. Multiple interoperable implementations
  11. Deployment experience
  12. RFC publication

Alternative: Start as Experimental RFC

  • Faster path
  • Allows field testing
  • Can evolve to Standards Track later

Related Technologies to Monitor

  1. ACME (RFC 8555) - Automated certificate issuance (key rotation ideas)
  2. WebAuthn - Public key authentication (user key management UX)
  3. did:web - Decentralized identifiers (future integration?)
  4. DNSSEC - Essential for secure key publication
  5. JOSE/JWT - JSON signing standards (proof format inspiration)

Competitive Analysis

Why this hasn't been done before?

  1. Complexity: Per-user keys harder than domain keys
  2. Adoption: Chicken-and-egg (senders need receivers to support)
  3. Key Management: Hard UX problem
  4. DKIM "good enough": Domain-level auth sufficient for most use cases

Why now?

  1. Increased threat landscape: CEO fraud, sophisticated phishing
  2. Compliance requirements: GDPR, SOC2 demand non-repudiation
  3. Better crypto: Ed25519 is fast, small, simple
  4. Cloud infrastructure: Key management as a service viable
  5. Your platform: Integrated stack (MTA + API + client) enables smooth UX

Recommended Reading

  1. RFC 6376 - DKIM Signatures
  2. RFC 8617 - ARC
  3. RFC 8551 - S/MIME
  4. RFC 7672 - DANE for SMTP
  5. "Why Johnny Can't Encrypt" - Classic UX research on key management
  6. "SoK: Secure Email Architecture" - Comprehensive survey
  7. NIST SP 800-177 - Email Security Guidelines

Next Research Steps

  1. [ ] Survey enterprise customers on demand for per-user auth
  2. [ ] Benchmark Ed25519 verification performance at scale
  3. [ ] Analyze DKIM deployment data for adoption insights
  4. [ ] Prototype key rotation automation
  5. [ ] Study certificate transparency logs for revocation patterns
  6. [ ] Interview email security researchers for feedback