August 17, 2026

Secure Internet-Native Fax Architecture

Trusted Carrier and Cloud Fax Federation

Technology Concept Paper

Author: Christopher Soans
Date: August 2026

Purpose

A migration architecture for replacing legacy fax transport with secure provider-authenticated digital document delivery while preserving fax-number addressing, enterprise workflows, and legacy interoperability at the carrier edge.

Figure 1. Secure Internet-Native Fax Architecture

Executive Summary

Fax remains embedded in healthcare, legal services, financial services, government, insurance, real estate, and many enterprise workflows. Although traditional fax was designed around the Public Switched Telephone Network (PSTN), much of today's fax traffic already originates or terminates on digital systems, cloud fax platforms, multifunction devices, and IP telecommunications networks.

This creates an architectural inefficiency. A document that begins digitally may be converted into fax modem signaling, transported as G.711 audio or T.38 fax relay, and subsequently converted back into a digital document at the destination.

Version 3.7 of the Secure Internet-Native Fax Architecture proposes a gradual replacement of this model with a secure digital fax ecosystem while preserving one of fax's most useful characteristics:

The user continues to send a document simply by specifying the destination fax number.

The architecture establishes a Trusted Secure Fax Federation consisting primarily of telecommunications carriers and authorized cloud fax providers. Fax-number resolution, destination-provider discovery, routing authorization, and service-capability discovery occur privately within this federation rather than through publicly accessible DNS.

The Internet may carry encrypted fax traffic, but it does not become a public fax directory.

Version 3.7 further simplifies the customer architecture by eliminating the requirement for a conventional fax machine, analog RJ-11 interface, or customer PSTN connection. Organizations adopting the new service migrate directly to an all-digital Secure Fax Gateway with a software-client, local HTTPS web interface, authenticated API and incoming fax routing via email environment.

The Secure Fax Gateway becomes a secure customer/enterprise document-communications appliance capable of supporting multiple fax numbers, departments, users, applications, encrypted queues, audit records, and high-availability configurations while keeping the architecture and hardware affordable, secure, simple, and scalable from a single fax number to multiple fax number support which can be bundled with the Fax Service provided by each Carrier.

Cloud fax providers become first-class federation participants and important migration accelerators. They operate scalable software-based environments supporting both Secure Internet-Native Fax and Secure T.38 for legacy carrier interworking.

Cloud providers should progressively migrate away from G.711 fax pass-through for carrier interconnection. When a destination remains on traditional fax infrastructure, the cloud provider hands the fax to an authorized carrier using authenticated and encrypted T.38. The carrier performs the final T.30/PSTN termination.

Secure Internet-Native Fax
↓
Secure T.38 Carrier Interworking
↓
Carrier T.30/PSTN Legacy Termination

The result is a practical migration strategy that modernizes fax without requiring organizations to abandon existing fax numbers, cloud APIs, enterprise applications, or familiar addressing conventions.

1. Design Objective

The primary objective is straightforward:

Preserve the fax number and familiar fax workflow while replacing the underlying telephone transport with secure digital document delivery.

A user should continue to perform essentially:

Destination: +1-555-555-1234
Document: invoice.pdf

SEND

The user does not need to know:

The destination IP address
The destination carrier
Whether the recipient uses a cloud fax provider
Whether the recipient has a Secure Fax Gateway
Whether T.38 is required
Whether PSTN fallback is required

Those decisions belong to the provider infrastructure.

2. Architectural Evolution

Legacy

Fax Machine
     |
   PSTN
     |
Fax Machine

Transitional IP Fax

Fax / Cloud Platform
        |
   G.711 or T.38
        |
      Carrier
        |
       PSTN

Secure Internet-Native Fax

Traditional fax remains supported at the carrier edge during migration but is no longer required at customer premises adopting the new architecture.

3. The Fax Number Remains the Universal Address

The E.164 telephone/fax number remains the principal customer-facing destination identifier.

+1-555-555-1234

The sender submits this number to its serving carrier or authorized cloud fax provider. The sender does not perform a public DNS query to determine where the number terminates.

This preserves the simplicity of traditional fax while hiding the complexity of digital routing.

4. Submit-and-Route Model

Deliver this authenticated document to this fax number.

The provider performs:

Customer authentication
Originating-number authorization
Destination-number resolution
Destination-provider discovery
Capability discovery
Security negotiation
Transport selection
Document delivery
Integrity verification
Delivery acknowledgement

The endpoint does not need intercarrier routing knowledge.

5. Trusted Secure Fax Federation

The architecture establishes a private federation of trusted fax service providers.

             TRUSTED SECURE FAX FEDERATION

        +----------------+----------------+
        | |
        v v
Telecommunications                Authorized Cloud
     Carriers Fax Providers
        | |
        +----------------+----------------+
                         |
                 Secure Routing
                 Authentication
                 Number Resolution
                 Capability Discovery

Participation is restricted. An ordinary Internet host cannot join the federation simply by publishing a DNS record.

6. Federation Participants

Telecommunications Carrier

Telephone-number authority
Number portability
Subscriber authentication
Secure Native Fax
Federation routing
38 interworking
PSTN/T.30 legacy termination

Authorized Cloud Fax Provider

Customer fax APIs
Web/mobile fax applications
Enterprise integrations
Secure Native Fax
Software T.38 services
Encrypted document queues
Federation participation
Fax-number service under authorized delegation

Cloud fax providers do not need to become telecommunications carriers merely to participate.

7. Private DNS and Routing Resolution

DNS or an ENUM-derived mechanism may provide the federation's distributed resolution technology. However, this DNS environment is not publicly queryable. Resolution occurs only through authenticated provider infrastructure.

Provider A
    |
    | Mutual Authentication
    | Encrypted Federation Session
    v
Private Fax Resolution
    |
    v
Authoritative Provider

A customer cannot directly ask where a fax number terminates. Instead, the customer asks its provider to send the fax to the number, and the provider performs the lookup.

8. Internet Transport Without Public Discovery

The architecture makes an important distinction between the control plane and data plane.

Private Control Plane

Provider A ================= Provider B

Authentication
Private DNS
Number resolution
Authorization
Capability discovery

Secure Internet Data Plane

Provider A
     |
     | Authenticated + Encrypted
     v
Public Internet
     |
     v
Provider B

The Internet can therefore provide inexpensive, ubiquitous packet transport without exposing the fax directory or customer endpoints publicly.

9. Provider Credentials

Federation participation should use strong cryptographic identities rather than ordinary reusable credentials alone.

Provider certificates
Mutual TLS
Federation-issued identities
Number-range authorization
Service authorization
Certificate revocation
Automated credential rotation

Provider Identity:       VERIFIED
Federation Membership:   VALID
Fax Service Authority:   VALID
Number Authority:        VALID
Credential Status:       ACTIVE

A compromised provider credential can therefore be revoked.

10. Number Authority and Fax-Service Delegation

The provider controlling the telephone number does not necessarily have to operate the customer's fax platform.

+1-555-555-1234
       |
       v
Telephone Carrier
       |
       | Fax Service Delegation
       v
Cloud Fax Provider
       |
       v
Enterprise Customer

The federation distinguishes between Number Authority and Fax Service Authority. This supports cloud fax services without allowing providers to claim arbitrary telephone numbers.

11. New Customer-Premises Model

Version 3.7 removes the traditional fax machine from the preferred customer architecture. The customer migrates directly to a Secure Fax Gateway.

The gateway requires no:

RJ-11 port
Analog telephone interface
Customer PSTN line
Fax modem chipset
Analog telephone-line circuitry

This substantially simplifies the hardware.

12. Software Client as the Primary Fax Interface

Users interact with the Secure Fax Gateway through authenticated software.

User Workstation
       |
       | Authenticated encrypted LAN session
       v
Secure Fax Gateway
       |
       v
Serving Provider

The software, API, and local HTTPS web interface can provide:

Send fax
Receive fax
Fax inbox
Fax history
Delivery status
Sender verification
Search
Print
Export
Forward
Department routing

A user can therefore fax without a physical fax machine.

13. Receiving Faxes Digitally

Incoming documents are delivered to the gateway rather than automatically printed.

Incoming Secure Fax
        |
        v
Secure Fax Gateway
        |
        +--> Verify transaction
        +--> Verify document integrity
        +--> Encrypt at rest
        +--> Apply routing policy
        |
        v
Encrypted User/Department Queue
        |
        v
Authorized Software Client, API, local HTTPS web interface or destination Email address

This provides substantially better privacy than leaving received documents unattended on a fax machine.

14. Multiple Fax Numbers per Gateway

Because the gateway is digital, one appliance can support one or many fax numbers.

+1-555-1000
+1-555-1001
+1-555-1002
+1-555-1003
+1-555-1004
|
v
Secure Fax Gateway

The gateway can map numbers to logical destinations:

+1-555-1000 → General Office
+1-555-1001 → Accounting
+1-555-1002 → Human Resources
+1-555-1003 → Legal
+1-555-1004 → Purchasing

No separate physical fax line is required for each number.

15. Enterprise Fax Routing

The gateway can route incoming documents according to destination fax number, user, department, application, security policy, sender, document classification, or business workflow.

16. Enterprise Application Integration

The Secure Fax Gateway can expose an authenticated local API.

ERP / EHR / CRM
       |
       | Secure API
       v
Secure Fax Gateway
       |
       v
Trusted Fax Network

This allows applications to submit documents without user intervention while continuing to use fax-number addressing.

17. High-Availability Enterprise Gateways

Large organizations should be able to deploy redundant gateways.

Gateway state and encrypted queues could be replicated according to enterprise policy.

18. Cloud Fax Providers as Migration Accelerators

Cloud fax providers may already serve very large populations through APIs, web portals, desktop applications, mobile applications, email gateways, enterprise fax servers, and multifunction printers.

Migrating the provider's infrastructure can therefore migrate large customer populations without individually replacing customer equipment. This makes cloud providers strategically important to rapid adoption.

19. Software-Based Cloud Fax Architecture

Version 3.7 proposes that cloud fax providers implement scalable software-based fax service environments.

Both pools can scale horizontally.

20. Secure Native Fax Service Pool

Native fax instances handle destinations participating in the federation.

Native Instance 1
Native Instance 2
Native Instance 3
...
Native Instance N

The service can scale according to transaction volume, geographic location, customer population, provider peering, and availability requirements. Because the system transfers digital documents rather than real-time modem audio, cloud-native scaling becomes substantially easier.

21. Software T.38 Service Pool

Cloud providers should also maintain scalable T.38 capability during the migration period.

T.38 Instance 1
T.38 Instance 2
T.38 Instance 3
...
T.38 Instance N

These instances provide interoperability with carriers serving legacy fax destinations. The cloud provider does not need a PSTN interface.

22. Elimination of G.711 as the Preferred Cloud/Carrier Fax Interconnect

Where cloud providers currently exchange fax traffic with carriers using G.711 fax pass-through, Version 3.7 recommends migration toward T.38.

Digital Document
      |
      v
Fax Modem Representation
      |
      v
G.711 Audio
      |
      v
Carrier

For a known fax transaction, this is unnecessary when both platforms support fax relay.

23. Secure T.38 Cloud/Carrier Interconnection

The preferred transitional interconnect becomes:

Cloud Fax Provider
        |
        | Authenticated
        | Encrypted T.38
        v
Carrier Fax Gateway
        |
        v
Legacy Fax Network

The exact protection mechanism should be standardized or profiled appropriately, since T.38/UDPTL itself should not be assumed to provide confidentiality and authentication.

24. Carrier Ownership of Legacy Termination

The carrier owns the boundary between the secure digital fax ecosystem and legacy T.30/PSTN fax.

The cloud provider does not need to convert customer documents into G.711 fax audio.

Cloud Fax Provider
        |
     Secure T.38
        |
        v
Carrier Fax Gateway
        |
     T.30 / PSTN
        |
        v
Legacy Fax

The carrier performs the final legacy interworking.

25. Receiving Legacy Fax for a Cloud Customer

The cloud provider therefore requires T.38 capability but no analog/PSTN termination capability.

26. ECM for Legacy Fax

Carrier gateways should support T.30 Error Correction Mode (ECM) for legacy fax sessions. When the remote fax supports ECM, ECM should normally be preferred.

Legacy Fax
    |
    | T.30 + ECM
    v
Carrier Fax Gateway

However, ECM must be negotiated. A carrier gateway cannot force a legacy fax machine that does not support ECM to use it.

Remote Fax supports ECM
        |
       YES
        |
        v
Prefer ECM

Remote Fax does not support ECM
        |
        v
Receive using non-ECM T.30

27. ECM and T.38 Protection Are Different

ECM protects fax-image transmission behavior. T.38 redundancy or FEC protects against IP transport loss. Encryption and authentication protect against interception and unauthorized communication.

28. T.38 FEC and Redundancy

T.38/UDPTL can provide packet-loss protection through redundancy and standardized FEC mechanisms, subject to implementation and interoperability support.

Packet 1: A
Packet 2: B + A
Packet 3: C + B + A

FEC instead generates recovery information derived from multiple data units.

A ──┐
B ──┤
C ──┼──> Recovery Information
D ──┘

Where interoperable, FEC can be considered as part of a managed carrier/cloud T.38 profile.

29. Avoiding Unnecessary G.711-to-T.38 Switching

Traditional VoIP fax may initially establish G.711 and switch to T.38 after detecting fax tones.

SIP
|
G.711
|
Fax Detection
|
Re-INVITE
|
T.38

A dedicated cloud fax provider already knows that the transaction is fax. Therefore, where carrier interfaces permit, the session can be established as fax-specific transport from the beginning.

Cloud Fax Platform
        |
        | Fax transaction
        v
Carrier Fax Service
        |
        v
Secure T.38

This removes another possible failure point.

30. Multiple Carrier Relationships for Cloud Providers

Cloud fax providers may maintain multiple authorized carrier interconnects for capacity, geographic diversity, disaster recovery, and service continuity. This does not mean that a fax number is simultaneously published to several arbitrary carriers or that T.38 media relays independently decide where a fax should fail over.

The normal redundancy model is intra-carrier: a carrier exposes one logical fax service backed by a pool of T.38 gateways. The carrier's SIP, SBC, fax controller, service controller, or other routing layer monitors gateway health and selects an available media gateway before a session is established. T.38 itself is the fax-relay/media function and should not be treated as the primary failover-control mechanism.

Intra-Carrier Gateway Redundancy

A cloud provider should normally address a carrier's logical fax service rather than a permanently fixed T.38 gateway. The carrier may operate multiple gateways behind that service for load distribution, maintenance, and failure isolation.

Inter-Carrier Diversity

A large cloud provider may optionally maintain a second or additional authorized carrier relationship. Selection between carriers is performed by the cloud provider's routing and policy layer based on reachability, service health, geography, capacity, commercial policy, or disaster-recovery requirements. This transport diversity does not change the authoritative identity or routing ownership of the destination fax number.

Destination Number
       |
       v
Cloud Routing Policy
       |
Primary Carrier Healthy?
     /          \
   YES           NO
    |             |
    v             v
Carrier A      Carrier B

Active-Session Failure

An active T.38 session should not be assumed to move seamlessly from one media gateway to another. Unless the participating infrastructure explicitly implements synchronized session-state replication and supports such recovery, failure of the active T.38 gateway normally causes that fax attempt to fail. The transaction can then be retried through another healthy gateway or carrier path.

Active Fax
    |
T.38 Gateway 1
    |
    X gateway/session failure
    |
Retry Transaction
    |
    v
T.38 Gateway 2

This limitation is another reason Secure Internet-Native Fax remains the preferred long-term transport: a native document transaction can support transaction identifiers, verified block state, reconnection, and resumable delivery without depending on continuity of a real-time T.38 media relay.

31. Native Fax Takes Precedence

T.38 remains a migration technology. It should not be selected when both sides can communicate natively.

32. Cloud-to-Cloud Native Fax

Cloud-to-cloud transactions illustrate why native fax is valuable.

The native architecture becomes:

Cloud A
   |
   | Secure Internet-Native Fax
   v
Trusted Federation
   |
   v
Cloud B

The document remains digital throughout.

33. Gateway-to-Gateway Native Fax

Enterprise A
Software Client, API or local HTTPS web interface
      |
      v
Fax Gateway A
      |
      | Secure Native Fax
      v
Trusted Provider Network
      |
      v
Fax Gateway B
      |
      v
Enterprise B
Software Client, API, local HTTPS web interface or Email

No T.30, T.38, G.711, or PSTN is necessary for this transaction.

34. Native Fax Reliability

Secure Native Fax can use modern reliable transport rather than T.38-style real-time fax relay. A document may be divided into authenticated blocks:

Document
   |
   +-- Block 1
   +-- Block 2
   +-- Block 3
   +-- Block 4
   +-- Block 5

The receiver verifies each block. If necessary, it requests only missing or invalid data.

Blocks 1-420: VERIFIED
Block 421: MISSING
Blocks 422-600: VERIFIED

REQUEST:
Block 421

35. Transport and Document Reliability

Transport Layer

TCP, QUIC, or another suitable reliable secure transport can recover ordinary packet loss.

Fax Application Layer

The fax protocol verifies document completeness, block integrity, transaction identity, page/document metadata, and final document integrity.

This avoids unnecessary repeated transmission of already-received document data.

36. Native Fax Keepalive

An active native fax transaction can support authenticated keepalive messages. These are distinct from traditional T.30 fax signaling. When document traffic is flowing normally, additional keepalives need not be sent.

A keepalive may include limited authenticated transaction state.

37. Resumable Fax Transactions

If a connection is interrupted, native fax can resume rather than restart the entire transmission.

Transaction FX-100482
Blocks 1-6417: VERIFIED

Connection interrupted

Reconnect

Receiver:
Resume at Block 6418

This is particularly valuable for large documents or unstable network conditions.

38. Document Integrity

A cryptographic integrity mechanism can verify that the final document is identical to what the sender transmitted.

Sender Document
      |
      v
Authenticated Document Digest
      |
      v
Secure Transmission
      |
      v
Receiver Verification

A successful transport connection alone should not constitute final document acceptance.

39. Verified Delivery Receipt

Final delivery acknowledgement can be generated only after successful document verification.

Transaction: FX-83920417

Destination:
+1-555-555-2000

Origin Identity:
VERIFIED

Transport:
SECURE NATIVE FAX

Document Integrity:
VERIFIED

Pages:
12

Delivery:
CONFIRMED

Such receipts can provide substantially better audit information than conventional fax confirmation pages.

40. Encryption in Transit

All native fax communication over untrusted infrastructure must be encrypted and authenticated.

Customer
   ||
   || Encrypted
   \/
Provider A
   ||
   || Encrypted
   \/
Provider B
   ||
   || Encrypted
   \/
Customer

Provider authentication prevents arbitrary Internet systems from impersonating federation members.

41. End-to-End Document Protection

Where required and technically appropriate, Secure Native Fax can additionally support recipient-specific document encryption.

This is distinct from transport encryption. The architecture should therefore distinguish Encrypted-in-transit Secure Fax from True End-to-End Protected Fax.

42. Encrypted Gateway Storage

Documents stored on customer gateways should be encrypted at rest.

User authentication
Department authorization
Retention periods
Automatic deletion
Audit trails
Administrative controls
Encryption-key management

This is particularly important when one gateway serves many users.

43. Sender Authentication

The originating provider verifies that the customer is authorized to use the claimed fax number.

Customer Identity:        VERIFIED
Origin Fax Number:        AUTHORIZED
Provider Identity:        VERIFIED
Transaction Identity:     VALID

The receiving provider therefore does not need to trust arbitrary self-reported fax header information.

44. Protection Against Unsolicited Direct Internet Fax

An arbitrary Internet host cannot directly discover and send to a protected Fax Gateway.

Unknown Internet Host
|
X
Enterprise Fax Gateway

Instead:

Authenticated Customer
        |
        v
Authorized Provider
        |
        v
Trusted Federation
        |
        v
Destination Provider
        |
        v
Destination Gateway

This creates a strong foundation for anti-spoofing and abuse controls.

45. Number Portability

The fax number remains independent of the physical or cloud endpoint.

Before:

+1-555-555-1000
|
Carrier A

After:

+1-555-555-1000
|
Cloud Provider B

The sender continues using the same number. Federation routing changes automatically.

46. Cloud API Preservation

Existing cloud fax APIs should not require fundamental changes.

POST /fax

destination = +1-555-555-1234
document = invoice.pdf

The provider determines internally whether delivery uses Secure Native Fax, Secure T.38, or Carrier PSTN termination. This is one of the architecture's strongest migration advantages.

47. Updated End-to-End Routing Decision

The customer is insulated from all of these decisions.

48. Revised Transport Hierarchy

Tier 1 — Secure Internet-Native Fax

Preferred whenever the destination supports it.

Tier 2 — Secure T.38

Used between digital providers and carriers for legacy fax interworking.

Tier 3 — T.30/PSTN

Confined to the carrier legacy edge.

G.711 fax pass-through is no longer a preferred architectural tier and should progressively disappear from participating cloud-provider/carrier fax interconnections.

49. Clean Separation of Responsibilities

CUSTOMER DOMAIN

Software Clients
Enterprise Applications
Secure Fax Gateway

        |
        v

CLOUD / DIGITAL FAX DOMAIN

Cloud APIs
Secure Native Fax
Software T.38
Encrypted Queues
Federation Participation

        |
        v

CARRIER DOMAIN

Number Authority
Federation Routing
Secure T.38 Gateways
T.30 Termination
PSTN Legacy Access

This makes each participant responsible for the technology best suited to its environment.

50. Customer Responsibility

Fax users
Fax numbers assigned to departments
Local access policies
Gateway deployment
Software clients
Enterprise application integration
Document-retention policy
Internal mail-server integration and fax-number-to-email routing policy

The customer does not manage PSTN fax infrastructure.

51. Cloud Provider Responsibility

Customer authentication
APIs
Web/mobile clients
Secure Native Fax
Software T.38
Encrypted document processing
Customer queues
Federation credentials
Number-service delegation
Carrier T.38 relationships
Transaction auditing

It does not need to maintain analog customer interfaces.

52. Carrier Responsibility

Telephone-number authority
Number routing
Number portability
Federation routing
Legacy PSTN connectivity
30 fax termination
ECM negotiation with legacy fax machines
Secure T.38 interworking
Legacy network transition

This keeps legacy telephony functions where they naturally belong.

53. Migration Phase One — Cloud Interconnect Modernization

Cloud providers currently using G.711 with carriers migrate to Secure T.38.

G.711
|
v
Secure T.38

Existing customer APIs and numbers remain unchanged.

54. Migration Phase Two — Secure Fax Federation

Carriers and authorized cloud providers join the Trusted Secure Fax Federation. Native-capable destinations become discoverable privately at the provider level.

Fax Number
    |
    v
Private Federation
    |
    v
Native Capability

Native transactions begin bypassing T.38/PSTN.

55. Migration Phase Three — Customer Gateway Adoption

Enterprise customers replace conventional fax machines with Secure Fax Gateways and software clients.

Fax Machine + Phone Line

↓

Secure Fax Gateway + Software

Multiple existing fax numbers can consolidate onto a single gateway environment.

56. Migration Phase Four — Native Fax Becomes Dominant

Secure Native Fax
       ↑
       ↑
       ↑

Secure T.38
       ↓

PSTN/T.30
       ↓

Legacy traffic progressively decreases. Eventually, T.38 and PSTN become compatibility services rather than the primary fax network.

57. Commercial Opportunities

Carriers can offer:

Secure Fax Gateway service
Managed enterprise fax
Secure T.38 termination
Federation routing
Number management
Verified fax identity
High-availability fax
Compliance-oriented services

Cloud providers can offer:

Secure fax APIs
Native fax service
Encrypted fax storage
Enterprise workflow integration
Multi-number services
Secure delivery receipts
High-volume fax automation

This provides economic incentives for both provider classes to participate.

58. Standards Strategy

The architecture should reuse open standards wherever appropriate.

E.164 — Fax-number identity.

DNS / ENUM concepts — Private distributed number-to-provider resolution.

T.30 — Legacy Group 3 fax procedures at carrier PSTN boundaries.

ECM — Legacy fax error correction when negotiated.

T.38 — Carrier/cloud legacy fax relay.

UDPTL Redundancy/FEC — T.38 packet-loss mitigation where supported.

TLS / Mutual TLS — Provider and customer authentication.

QUIC or another suitable secure reliable transport — Potential basis for Native Fax document transport.

Modern authenticated encryption — Confidentiality and integrity.

New protocol elements should be introduced only where existing standards cannot meet the native-fax requirements.

59. Federation Governance

A trusted federation requires governance covering:

Provider admission
Identity validation
Number authority
Fax-service delegation
Security requirements
Certificate issuance
Credential revocation
Interoperability testing
Abuse handling
Incident response
Privacy requirements
Audit requirements
Service availability
Routing integrity

Cloud-provider participation should accelerate adoption without weakening carrier-grade trust.

60. Security Principles

Federation routing is never publicly accessible.
Customer gateways do not query intercarrier DNS directly.
Providers must authenticate to the federation.
Customers must authenticate to their providers.
Originating fax-number authority must be verified.
Native fax must use authenticated encryption.
38 crossing untrusted infrastructure must be appropriately protected.
Destination endpoint information is not unnecessarily disclosed.
Stored documents must be appropriately protected.
Final delivery requires document-integrity verification.

61. Compliance-Oriented Architecture

The system can provide technical safeguards useful for regulated environments, including:

Encryption in transit
Encryption at rest
Access controls
Verified sender identity
Audit records
Document integrity
Secure delivery confirmation
Retention controls
Optional end-to-end encryption

These capabilities can assist organizations subject to requirements such as HIPAA, but the technology by itself does not establish legal or regulatory compliance.

62. Version 3.7 Architectural Principles

The fax number remains the universal user-facing destination identifier.
The provider—not the customer—performs destination-provider discovery.
Fax-number resolution remains private to trusted carriers and authorized cloud fax providers.
The Internet may provide transport without becoming a public fax directory.
The customer Fax Gateway is entirely digital.
No customer RJ-11 or PSTN connection is required.
Software clients and enterprise applications become the primary endpoints.
A single gateway can support many fax numbers, users, departments, and applications.
Cloud providers operate scalable software-based Secure Native Fax environments.
Cloud providers also operate scalable software T.38 environments during migration.
Cloud/carrier G.711 fax interconnections should progressively migrate to Secure T.38.
Cloud providers need not operate PSTN termination infrastructure.
Carriers perform final legacy T.30/PSTN termination.
ECM is preferred for carrier-to-legacy fax sessions when negotiated and supported.
38 redundancy/FEC independently protects the IP relay layer.
Cloud providers may use multiple authorized carrier interconnects for capacity and service diversity, while gateway redundancy is normally implemented behind each carrier's logical fax service and failover decisions are made by signaling/routing control rather than by T.38 media relays.
Secure Internet-Native Fax always takes precedence when both destinations support it.
Native fax supports modern block integrity, selective recovery, keepalives, and resumability.
Existing enterprise cloud-fax APIs can remain substantially unchanged.
The Secure Fax Gateway may optionally route received faxes to internal email addresses by destination fax number using the enterprise's local LAN and configured mail server, without exposing internal email addresses to the federation.
Large enterprise customers may optionally associate fax numbers with Secure Direct Fax Submission portals or APIs that deliver into enterprise-controlled gateways without requiring persistent document storage by intermediary carriers or cloud fax providers.
T.30, T.38 and PSTN progressively become legacy-edge technologies rather than the foundation of fax.

63. Internal Fax-to-Email Delivery

The Secure Fax Gateway may optionally deliver received faxes to internal enterprise email addresses based on the destination fax number. This is an internal LAN integration feature: the gateway uses the customer's configured local mail server or mail-relay address rather than requiring the carrier or cloud fax provider to store or forward the document through an external email service.

Incoming Fax Number
       |
       v
Secure Fax Gateway
       |
       +--> +1-555-1001 --> ap@company.example
       +--> +1-555-1002 --> hr@company.example
       +--> +1-555-1003 --> legal@company.example
       |
       v
Local LAN / Enterprise Mail Server
       |
       v
Authorized Internal Mailbox

The gateway can maintain a local routing table that maps each fax number to one or more internal email recipients, distribution groups, or enterprise workflow mailboxes. The enterprise administrator controls these mappings and may combine email delivery with the gateway's normal encrypted queue, API, or software-client delivery.

Local Mail-Server Integration

The enterprise configures the Fax Gateway with the address of an approved internal SMTP submission or mail-relay service, appropriate authentication credentials or certificates, and permitted sender/recipient policy. Delivery should remain on the organization's trusted LAN or approved private enterprise network whenever the organization requires documents to remain within its controlled environment.

Secure Fax Gateway
       |
       | authenticated SMTP submission
       | or enterprise-approved mail transport
       v
Internal Mail Server / Relay
       |
       +--> Department Mailbox
       +--> User Mailbox
       +--> Distribution Group
       +--> Workflow Mailbox

Security and Delivery Policy

Fax-to-email should be optional per fax number. For sensitive environments, the enterprise may require encrypted mail transport, message encryption or protected attachments, restricted distribution groups, data-loss-prevention controls, retention policies, and audit logging. The gateway should record both fax acceptance and internal mail-delivery status so that a successful fax receipt is not confused with successful mailbox delivery.

Fax Transaction:       RECEIVED / VERIFIED
Gateway Queue:         STORED
Internal Mail Submit: ACCEPTED
Mailbox Delivery:      CONFIRMED or PENDING
Destination Route:     legal@company.example

This feature keeps the external fax architecture unchanged. Carriers and cloud providers deliver the fax to the enterprise's Secure Fax Gateway; only after verified receipt does the enterprise-controlled gateway perform local fax-number-to-email routing. No internal email address needs to be exposed through the Trusted Fax Federation.

64. Optional Secure Direct Fax Submission (SDFS)

Large enterprise fax customers may optionally associate one or more fax numbers with a secure web portal or API that allows external customers, patients, partners, or applications to submit documents digitally. This capability is called Secure Direct Fax Submission (SDFS). It supplements rather than replaces Secure Internet-Native Fax and legacy fax reception.

The objective is to preserve the familiar fax number as a universal document-intake identity while allowing a sender that does not have fax service to deliver a document securely through a browser or API.

Fax Number
     |
     +--> Secure Internet-Native Fax
     +--> Secure Web Submission
     +--> Secure API Submission
     +--> Carrier Legacy Fax Interworking
     |
     v
Enterprise Secure Fax Gateway

65. Enterprise-Controlled Digital Intake

SDFS should be implemented as an enterprise-controlled or carrier-facilitated submission path rather than as another cloud fax mailbox. The destination enterprise remains the authoritative recipient, and the portal or API maps the submitted document to an authorized enterprise fax number and its configured queue or workflow.

External Sender
       |
       | Authenticated encrypted upload
       v
Secure Submission Service
       |
       | Direct protected delivery
       v
Enterprise Secure Fax Gateway
       |
       +--> Verify document
       +--> Security/content screening
       +--> Encrypt at rest
       +--> Apply enterprise routing
       v
Authorized User / Application Queue

66. Carrier-Facilitated Portal Without Provider Document Retention

A carrier may optionally provide the public portal, authentication framework, availability infrastructure, rate limiting, and session establishment for a large enterprise customer. The architecture should not require the carrier or a cloud fax provider to persistently store the submitted document. Where practical, the payload should be streamed or forwarded directly into the enterprise-controlled Secure Fax Gateway or enterprise-controlled intake environment.

External Customer
       |
       v
Carrier-Facilitated Secure Portal
       |
       | Authenticate / authorize / establish session
       |==============================================>
                    protected document stream
                                      |
                                      v
                         Enterprise Secure Fax Gateway

The design should avoid absolute claims that document data never enters intermediary memory, because transient buffering may occur during network processing. The stronger requirement is that intermediary carrier or cloud systems are not required to retain persistent document copies and should minimize transient retention according to the service security profile.

67. End-to-End Protected Submission

For sensitive workflows, SDFS may support recipient-specific document encryption. The sender portal or API can obtain an authenticated public encryption key for the enterprise destination and encrypt the document so that intermediary infrastructure transports ciphertext without possessing the destination private key.

Sender Browser / Application
       |
       | Encrypt for Enterprise Destination
       v
================ CIPHERTEXT ================
       |
       v
Carrier / Network Infrastructure
       |
       v
Enterprise Secure Fax Gateway
       |
       | Decrypt inside enterprise-controlled boundary
       v
Enterprise Document Queue

68. Public Portal and Private Federation Separation

The public submission service must not expose the private carrier federation. A web portal or API is a controlled public submission edge, not a federation participant. Private fax-number resolution, provider discovery, and interprovider authorization remain restricted to authenticated carriers and authorized cloud fax providers.

TRUSTED FAX FEDERATION
Carrier <==================> Carrier / Authorized Cloud Provider
Private routing and provider authentication only

PUBLIC SUBMISSION EDGE
External Browser / API
       |
       | HTTPS / protected submission
       v
Authorized SDFS Service
       |
       v
Enterprise Secure Fax Gateway

69. Verified Association Between Portal and Fax Number

The enterprise and its carrier should cryptographically authorize the association between a public submission service and the fax number it represents. This allows a sender to verify that a portal or API is genuinely authorized to accept documents for the advertised fax number without granting the sender access to federation DNS or internal destination information.

For example, the service profile for +1-800-555-1000 may indicate that Secure Internet-Native Fax, Secure Web Submission, and Secure API Submission are enabled, while the public user sees only an enterprise-authorized HTTPS endpoint and verifiable service identity.

70. API-Based Direct Submission

SDFS should support APIs in addition to browser portals. This enables healthcare, financial, legal, insurance, government, and other applications to deliver documents directly to an enterprise fax identity without first converting the document into a telephone fax transmission.

Enterprise / Partner Application
       |
       | Destination: +1-800-555-1000
       | Document: claim.pdf
       v
Authorized Secure Submission API
       |
       v
Enterprise Secure Fax Gateway

71. Cryptographically Verifiable Submission Receipt

After the enterprise-controlled gateway has received and verified the complete document, it may issue a cryptographically verifiable receipt. The receipt should distinguish technical acceptance by the destination system from later human review or business-process completion.

SECURE FAX RECEIPT

Transaction: FX-8294017
Destination: +1-800-555-1000
Destination Identity: VERIFIED
Document Integrity: VERIFIED
Gateway Acceptance: CONFIRMED
Human Review: NOT ASSERTED
Receipt Signature: VERIFIED

72. Configurable Enterprise Submission Policy

SDFS is optional and should be configurable per fax number or service group. An enterprise may permit public web submissions for one number, partner-authenticated API submissions for another, and federation-only fax delivery for a third.

Secure Native Fax:       ENABLED
Secure Web Submission:   ENABLED
Secure API Submission:   PARTNER ONLY
Legacy Fax Reception:    ENABLED

Public submission endpoints should include strong abuse controls such as rate limiting, file validation, malware scanning where appropriate, size limits, authentication options, transaction logging, and enterprise-defined acceptance policies.

73. Regulated-Industry Use Cases

SDFS may be particularly valuable in healthcare, finance, insurance, legal services, and government because it can reduce unnecessary third-party document persistence while providing authenticated delivery, encryption, integrity verification, access controls, and auditable receipt information. These technical capabilities can support regulated workflows but do not by themselves establish compliance with HIPAA or other legal requirements.

A healthcare organization, for example, could advertise a single document-intake number and allow authorized senders to use conventional fax, Secure Internet-Native Fax, a secure web portal, or a partner API. All permitted methods ultimately route into the same enterprise-controlled digital intake environment.

73. Strategic Significance

The principal innovation is not simply replacing PSTN fax with another IP fax protocol. It is the separation of fax identity from fax transport.

Today, the fax number, telephone network, fax modem, and destination machine are closely coupled. Version 3.7 separates them:

FAX IDENTITY
E.164 Number
     |
     v
TRUSTED RESOLUTION
Provider Federation
     |
     v
SECURE TRANSPORT
Native Fax / Secure T.38
     |
     v
DIGITAL DESTINATION
Gateway / Cloud / Application

That allows the fax number to survive even as the telephone fax network disappears underneath it.

74. Long-Term Architecture

The eventual ecosystem becomes remarkably simple.

Cloud services participate directly:

Legacy fax exists only at remaining carrier edges:

Secure Fax Ecosystem
        |
        | Secure T.38
        v
Carrier Legacy Gateway
        |
        | T.30/PSTN
        v
Remaining Fax Machine

As legacy machines disappear, this final segment disappears with them.

Conclusion

Version 3.7 of the Secure Internet-Native Fax Architecture establishes a cleaner distinction between modern digital fax and legacy telephone fax.

Organizations adopting the new technology no longer require a conventional fax machine, analog adapter, RJ-11 interface, or customer PSTN fax line. Instead, they deploy a Secure Fax Gateway connected to their data network.

Software clients and enterprise applications communicate directly with that gateway. Incoming documents are authenticated, verified, encrypted, queued, and delivered digitally to authorized users rather than automatically printed.

A single gateway can support numerous fax numbers and route them among departments, users, applications, and secure queues, making the architecture particularly suitable for enterprise deployments.

The gateway may also provide optional internal fax-to-email delivery. Enterprise administrators can map individual fax numbers to internal users, departments, distribution groups, or workflow mailboxes and have the gateway submit verified received documents through the organization's configured local mail server. This routing occurs entirely within the enterprise-controlled environment and does not require internal email addresses to be exposed to carriers, cloud fax providers, or the Trusted Fax Federation.

Cloud fax providers become scalable digital fax platforms. Their infrastructure supports both Secure Internet-Native Fax and software-based T.38, allowing large existing customer populations to migrate without abandoning established APIs and workflows.

T.38 resiliency is provided by the control architecture surrounding the media relay rather than by assuming that T.38 itself performs seamless failover. A carrier may place multiple T.38 gateways behind one logical fax service, with SIP/SBC/fax-control systems selecting healthy gateways. Cloud providers may also maintain alternate authorized carrier relationships for service diversity. If an active T.38 gateway fails, the fax should normally be retried through another healthy path unless explicit synchronized session-state recovery is supported.

For legacy fax destinations, cloud providers no longer need to transport fax modem audio using G.711 to telecommunications carriers. Instead, the preferred migration interface becomes authenticated and encrypted T.38.

The telecommunications carrier owns the remaining legacy boundary:

Secure T.38 → T.30/ECM → PSTN fax

ECM is used whenever supported and successfully negotiated with the legacy fax endpoint, while T.38 redundancy or FEC can independently protect the IP relay portion.

For destinations already participating in the Trusted Secure Fax Federation, neither T.38 nor PSTN is necessary. The document remains digital:

Software → Secure Fax Gateway → Secure Internet-Native Fax → Destination Gateway/Cloud Platform → Software

The federation itself remains private. Only authenticated telecommunications carriers and authorized cloud fax providers may perform number resolution and provider discovery. Customer endpoints never obtain unrestricted access to federation DNS or destination infrastructure.

This creates a deliberate migration path:

G.711 Fax Pass-Through
          ↓
Secure T.38
          ↓
Secure Internet-Native Fax

while simultaneously allowing:

Fax Machine + PSTN
          ↓
Secure Fax Gateway + Software
          ↓
Fully Digital Fax

The architecture therefore preserves the characteristics that have made fax useful—a universal telephone-number identifier, simple addressing, provider-mediated delivery, and confirmation of receipt—while progressively replacing the technologies that make traditional fax inefficient, difficult to secure, and dependent upon legacy telephone infrastructure.

For large enterprise and regulated-industry customers, optional Secure Direct Fax Submission extends the same fax-number identity to authenticated web and API intake. This permits direct digital submission and verifiable gateway acceptance while allowing the service to be designed without persistent document storage on intermediary carrier or cloud fax systems.

The long-term result is not simply fax over the Internet. It is a trusted, provider-authenticated, encrypted digital document-delivery network that preserves the fax number as its universal addressing system.

This work is licensed under a Creative Commons Attribution 4.0 International License (CC BY 4.0).