Security at MailCheckup. Architectural safeguards & privacy controls.

1. Data protection & encryption architecture

MailCheckup treats all customer email lists with strict operational confidentiality. Customer data moves through an encrypted pipeline engineered to prevent unauthorized access at every boundary:

• Transport Security (TLS 1.3): All network traffic between your client application, web browser, and our ingestion endpoints is protected by TLS 1.3 with Perfect Forward Secrecy. We enforce modern cipher suites (TLS_AES_256_GCM_SHA384) with an HSTS preload configuration (max-age=63072000). Plaintext HTTP traffic is rejected immediately.
• Ephemeral Volatile RAM Processing: Uploaded CSV files and API payloads are parsed line-by-line in volatile memory. Operating system swap paging is strictly disabled using mlock, and temporary memory structures are scrubbed using explicit_bzero immediately after socket closure. Plaintext customer records are never written to unencrypted staging disks.
• Storage Encryption at Rest (AES-256 GCM): Completed result exports and workspace audit logs are encrypted using AES-256 in Galois/Counter Mode (GCM). Encryption keys are rotated automatically and maintained in dedicated hardware security modules (HSMs).
• Cryptographic Webhook Signatures: Every automated callback includes the X-MailCheckup-Signature header generated using HMAC-SHA256 digests. Senders verify payloads with timing-safe comparison:

// Node.js Verification Example
const crypto = require('crypto');

function verifyWebhookSignature(rawPayload, timestamp, signatureHeader, secret) {
  const hmac = crypto.createHmac('sha256', secret);
  const expected = hmac.update(`${timestamp}.${rawPayload}`).digest('hex');
  return crypto.timingSafeEqual(Buffer.from(signatureHeader), Buffer.from(expected));
}

# Python Verification Example
import hmac, hashlib

def verify_webhook_signature(raw_payload: bytes, timestamp: str, signature: str, secret: str) -> bool:
    payload_to_sign = f"{timestamp}.".encode('utf-8') + raw_payload
    expected = hmac.new(secret.encode('utf-8'), payload_to_sign, hashlib.sha256).hexdigest()
    return hmac.compare_digest(signature, expected)

2. Threat matrix & defensive controls

Our threat model is evaluated against the OWASP Top 10 API Security Risks and Cloud Security Alliance standards. The matrix below outlines primary vectors and our verified defensive standards:

3. GDPR Article 28 data processor obligations

Under the EU General Data Protection Regulation (GDPR) and UK GDPR, MailCheckup operates strictly as a Data Processor. Our legal entity is Secuno LLC. You (the customer) retain sole authority as the Data Controller over your lists:

• Processing Purpose: We process customer email addresses solely for the narrow purpose of executing deliverability verification requested by your workspace. We never use customer data for secondary profiling, machine learning model training, or data enrichment.
• Zero Lead Reselling Guarantee: We explicitly contract that customer contacts will never be sold, brokered, rented, or shared with third-party advertisers or data brokers. Your lists belong exclusively to your workspace.
• Subprocessor Transparency: Infrastructure subprocessors are limited to tier-1 SOC 2 certified compute and cloud hosting facilities (AWS, Hetzner edge nodes) and Stripe for payment authorization. Subprocessors are bound by equivalent Article 28 data protection covenants.
• Self-Service Right to Erasure (Article 17): Workspace administrators can trigger immediate hard cryptographic deletion of any uploaded list, CSV export, or result summary at any time from the billing and list dashboard.

4. Why MailCheckup never sends email (RFC 5321 Demystified)

A frequent concern for email senders is whether verification will alert the recipient or trigger spam filters. MailCheckup proves mailbox reachability without ever delivering an email message:

• 1. Direct TCP Handshake: Our dialer initiates a standard TCP connection on port 25 to the authoritative Mail Exchanger (MX) server published by the recipient domain.
• 2. Authoritative EHLO Identification: Our dialer transmits standard EHLO identification using fully qualified, Forward-Confirmed Reverse DNS (FCrDNS) hostnames matching our registered domain.
• 3. Mailbox Probe (MAIL FROM / RCPT TO): We issue a standard envelope probe: MAIL FROM:<verify-probe@mailcheckup.net> followed by RCPT TO:<prospect@example.com>. The destination mail server responds with a definitive status code (e.g., 250 OK, 550 Mailbox Not Found, or 451 Greylisted).
• 4. Immediate Connection Teardown (QUIT): The moment the RCPT TO response code is received, our dialer transmits QUIT and closes the socket. The DATA command is never issued. Exactly zero bytes of message body, subject line, or campaign content are transmitted. The recipient never receives an email, and no notification appears in their inbox.

5. Responsible vulnerability disclosure policy

We welcome submissions from security researchers and operate under safe harbor for ethical research. Please direct disclosures to security@mailcheckup.net. When submitting vulnerability reports, please observe the following guidelines:

• Provide minimal reproduction steps, proof-of-concept scripts, or HTTP request captures.
• Do not attempt to access, extract, or tamper with customer data or workspaces other than your own test account.
• Refrain from executing Distributed Denial of Service (DDoS) attacks, brute-force credential stuffing, or spamming production support channels.
• Our engineering team acknowledges valid vulnerability reports within 24 hours and provides status updates until remediation is complete.

6. Frequently asked security questions