01
SMTP infrastructure
Mail transport roles, listeners, submission paths, routing, TLS and controlled administrative boundaries.
Controlled research, testing and systems engineering
Building and validating secure email infrastructure.
Email Infrastructure Lab is an independently developed technical environment for researching SMTP services, DNS authentication, secure application submission, controlled message workflows, monitoring, backup and recovery.
The environment is operated as a controlled Lab. Production deployment, unrestricted SMTP access and unsolicited bulk messaging are not authorized.
- Public website active
- HTTPS enabled
- PTR reassessment required
Controlled scopeOwned infrastructure and verified recipients
Evidence-awareReported, observed and tested states remain separate
Responsible useNo open relay, scraped lists or unsolicited campaigns
Change controlledBackups, review gates and rollback before deployment
Platform purpose
Email infrastructure is more than an SMTP server
The Lab brings together identity, authorization, DNS, transport, feedback, monitoring and recovery so each technical decision can be understood as part of a controlled system.
02
DNS authentication
MX, SPF, DKIM, DMARC, hostname alignment and reverse-DNS relationships documented together.
03
Canonical authorization
Environment, brand, sender, recipient, suppression, content and route are checked before transport.
04
Durable processing
Logical Messages remain distinct from transport Attempts, retries and asynchronous queue work.
05
Monitoring and evidence
Host health, service state, certificates, exposure, backup integrity and protected conditions are reviewed.
06
Backup and recovery
Restoration begins in a non-sending state until security, credentials, queues and policy controls are reconciled.
Core technical capabilities
Infrastructure designed as one controlled system
Transport, identity and resilience are developed together so every operational change remains explainable and reviewable.
Transport
Secure SMTP infrastructure
Controlled submission, routing, TLS and administrative boundaries built around verified sender and recipient policy.
Identity
DNS authentication and alignment
Domain identity, authentication records and policy alignment evaluated as connected controls rather than isolated settings.
Resilience
Monitoring, backup and recovery
Health evidence, protected backups and non-sending restoration gates reduce risk during incidents and change.
Controlled workflow
Validation happens before SMTP transport
A queue can carry approved work, but it cannot independently authorize a message. Sensitive actions must be checked against canonical state and fail closed when required information is missing.
- 1
Define the objective
Environment, sender, recipient scope, timing and message limits are approved.
- 2
Validate identity and policy
Sender, recipient, suppression, content and route are checked.
- 3
Create canonical state
One logical communication becomes one Message with controlled Attempts.
- 4
Submit and correlate
Transport outcomes, replies, bounces and suppression events update the canonical record.
Illustrative message workflow
Security and responsible use
Public services and restricted systems remain separated
Public HTTPS and necessary mail transport are distinct from administrative APIs, databases, queues, metrics, workers and backup systems.
Review security and abuse controls →Non-negotiable boundaries
- No anonymous or open relay
- No purchased or scraped recipient lists
- No unknown-recipient campaigns
- No deceptive sender identities
- No public SMTP credentials
- No unsupported inbox-placement guarantees
Current Lab status
Progress is reported by evidence state
Green means verified, amber means pending or limited, grey means not yet inspected, and red means blocked or not authorized.
Public website
Static HTML site served by Nginx over the public domain.
Mail host
Stalwart service is active behind the dedicated mail hostname.
Reverse DNS / PTR
Provider reassessment is required after website and public platform maturity improvements.
Production deployment
Architecture and Lab validation do not authorize production or unsolicited bulk sending.
Last evidence update: . Status will be revised after controlled inspection and validation milestones.
Legitimate technical use cases
Built for responsible systems engineering
Application submission testing
Validate authenticated submission from approved applications and controlled sender identities.
DNS and authentication research
Evaluate domain identity, alignment and policy without claiming guaranteed delivery outcomes.
Reply and bounce processing
Use controlled fixtures to test event correlation, suppression and safe workflow stopping.
Relay and abuse prevention
Confirm unauthorized submission and arbitrary relay attempts are denied.
Backup and recovery exercises
Restore into an isolated, non-sending environment and validate integrity before release.
Technical education
Document architecture, governance, evidence and operational lessons for long-term learning.
Operational evidence
Proof must be real, sanitized and review-approved
Operational screenshots and status claims are published only when they are attributable, timestamped, sanitized and supported by direct evidence.
Explore public documentation →
Evidence framework active
- Host and OS
- Fresh direct evidence collected
- Nginx and Stalwart
- Active services observed
- PTR
- Provider reassessment required
- Backup and recovery
- Further practical validation pending
Quick answers
Frequently asked questions
Is Email Infrastructure Lab a bulk-email platform?
No. Unsolicited bulk messaging, unknown recipients, public relay access and unrestricted SMTP credentials are prohibited.
Is the platform production-ready?
No. Architecture, implementation, evidence validation and production authorization are separate gates.
What is the current PTR status?
The infrastructure provider requires reassessment after the public website and platform presentation have been further developed.
Does missing PTR stop all Lab work?
No. It limits external deliverability claims but does not block read-only inspection, internal validation, backup, documentation or controlled non-production work.
Knowledge before scale
Every operational change should be explainable, testable and reversible.
The Lab treats documentation, validation, responsible use and recovery as part of the infrastructure itself.