Email Deliverability: MailParse vs CloudMailin

Why email deliverability matters when you are processing inbound email

When developers talk about email deliverability, they often think about outbound reputation. For inbound platforms, deliverability means something different: ensuring reliable receipt of legitimate messages into your application, with minimal delay and zero loss. If support tickets, signup confirmations, legal documents, or IoT reports arrive via email, missed messages equal broken workflows and unhappy users. A great email parsing service must accept mail for your domains and instant addresses consistently, validate authenticity signals, preserve the original MIME, and ship normalized data to your webhook or polling client every time.

This topic comparison focuses on inbound email-deliverability capabilities. We will examine how a modern parser handles DNS and MX setup, TLS and MTA hygiene, spam and abuse controls that do not block legitimate senders, webhook resiliency, and API ergonomics. We then compare these details to CloudMailin, a cloud-based inbound email processing service, and finish with hands-on code and a side-by-side feature table.

How MailParse handles email deliverability

The platform is built to make inbound acceptance dependable at scale without sacrificing developer ergonomics. Here is a technical deep-dive of the pieces that affect email deliverability:

DNS and MX configuration for reliable acceptance

• Bring-your-own-domain: point MX records for your domain or subdomain to the service's inbound hosts. Use at least two MX records with different priorities to spread risk and shorten failover time. Keep TTLs moderately low during initial cutover to speed changes.
• Instant addresses: for quick tests and temporary integrations, generate unique receiving addresses without touching DNS. This isolates experiments, improves traceability, and avoids domain-level changes during development.
• SPF, DKIM, DMARC: not required to receive mail, but the platform validates these signals and includes results in the parsed JSON so your app can choose to trust, flag, or quarantine messages.

Connection security and protocol hygiene

• TLS-by-default: opportunistic TLS is supported for SMTP sessions. Modern ciphers and protocols are preferred to reduce downgrade risks. The service maintains a broad compatibility range so older but legitimate senders can still deliver.
• MTA behaviors that favor receipt: no greylisting that delays first-time senders, reasonable concurrency windows, and sender reputation checks tuned to avoid rejecting legitimate transactional traffic.

MIME parsing that preserves meaning

Great deliverability does not end at SMTP acceptance. If the parser loses nuance, your application loses context. The platform turns MIME into structured JSON with a focus on fidelity and predictability. See the MIME Parsing: A Complete Guide | MailParse for deeper details. A typical payload includes:

{
  "id": "evt_01HV4E5GGQ4B8S6XJ4H3F2C9Q2",
  "received_at": "2026-05-02T10:15:41Z",
  "envelope": {
    "mail_from": "bounces@example.com",
    "rcpt_to": ["inbox@yourdomain.com"],
    "helo": "mx.sender.net",
    "remote_ip": "203.0.113.10"
  },
  "headers": {
    "message-id": "<abc123@example.com>",
    "subject": "New ticket #1427",
    "from": "Support <support@example.com>",
    "to": "inbox@yourdomain.com",
    "dkim-signature": "v=1; a=rsa-sha256; ..."
  },
  "authentication": {
    "spf": {"result": "pass", "domain": "example.com"},
    "dkim": [{"result": "pass", "domain": "example.com"}],
    "dmarc": {"result": "pass", "domain": "example.com"}
  },
  "parts": [
    {"type": "text/plain", "charset": "utf-8", "content": "Hi, we need help with..."},
    {"type": "text/html", "charset": "utf-8", "content": "<p>Hi, we need help with...</p>"}
  ],
  "attachments": [
    {"filename": "screenshot.png", "content_type": "image/png", "size": 582134, "download_url": "https://api.example.test/attachments/att_123"}
  ],
  "dedupe_key": "msgid:abc123@example.com"
}

Important for deliverability: the payload includes a dedupe_key derived from the Message-ID and envelope so you can idempotently process webhook retries without creating duplicate tickets, and authentication so you can decide how to trust the sender.

Webhook delivery built for resilience

Webhooks are signed using HMAC SHA-256 and a shared secret. Each delivery includes a timestamp and signature header, so you can verify the event came from the platform and within an acceptable clock skew window. Retries use exponential backoff and jitter, and events are retained for redelivery from a dead-letter queue if your endpoint is down. See Webhook Integration: A Complete Guide | MailParse for best practices like idempotency, signature verification, and 2xx-only success handling.

Polling API for belt-and-suspenders reliability

For teams that want active monitoring or redundancy, a REST endpoint lets you poll for messages that your webhook did not acknowledge. That means even if your consumer had a short outage, you can reconcile offline and keep the ingress path totally lossless.

Operational controls that protect good senders

• Attachment controls: oversized attachments are stored out-of-band and streamed via secure URLs, avoiding webhook timeouts.
• Allow and block lists: when required, you can allowlist known SMTP senders to bypass reputation blocks and prevent false positives.
• Metrics and alerting: dashboards and API endpoints expose acceptance rate, temporary deferrals, and permanent rejects by reason, so you can detect upstream sender issues fast.

For a bigger-picture overview of the inbound developer surface, read the Email Parsing API: A Complete Guide | MailParse.

How CloudMailin handles email deliverability

CloudMailin is a cloud-based inbound email processing service. It accepts mail for static addresses and for your domains once you point MX records at the targets listed in its dashboard. The platform focuses on delivering parsed content to your HTTP endpoint quickly and reliably.

• DNS setup: bring-your-own-domain by updating MX records to the documented CloudMailin endpoints. Use multiple MX records, observe their recommended TTLs, and validate using their verification checks to confirm routing.
• Webhook delivery: CloudMailin posts a JSON document to your URL. You confirm authenticity by verifying the X-CloudMailin-Signature header. Retries occur on non-2xx responses with backoff until the message is delivered or a retention window is reached.
• Payload: the JSON generally includes envelope details, headers, text and HTML parts, and attachment metadata or links. SPF, DKIM, and DMARC results can be included depending on configuration, allowing you to classify and route mail based on trust signals.
• Security and hygiene: TLS is supported for SMTP acceptance and for webhook delivery via HTTPS. The service balances abuse controls to minimize false rejects, which is central to inbound deliverability.
• Ecosystem: integration options focus on HTTP webhooks. There is less emphasis on a polling model, so design around webhooks, retries, and your own idempotency and reconciliation logic.

Overall, CloudMailin provides a straightforward path to dependable inbound acceptance, with a smaller ecosystem and fewer built-in integrations compared to larger developer platforms.

Side-by-side comparison: inbound email-deliverability features

Capability	This platform	CloudMailin
Bring-your-own-domain via MX	Yes - multiple MX priorities recommended, quick DNS verification	Yes - set MX to dashboard-provided targets
Instant disposable receiving addresses	Yes - create programmatically for tests and per-integration isolation	Yes - static addresses available
SPF, DKIM, DMARC results in payload	Yes - detailed JSON block for trust decisions	Available - include results depending on setup
Webhook signature and timestamp	Yes - HMAC SHA-256 with timestamp for replay protection	Yes - HMAC signature header
Retry policy and dead-letter redelivery	Yes - exponential backoff, jitter, and manual redelivery	Yes - backoff retries until retention policy
Polling API for missed events	Yes - reconcile backlog independent of webhooks	Primarily webhooks - polling not a standard pattern
Attachment handling	Stored out-of-band with secure links to avoid webhook bloat	Attachment metadata and links in payload
Operational metrics for acceptance and rejects	Yes - API and dashboards for acceptance rates and reasons	Yes - delivery and error logs available
Ecosystem and integrations	Broad - SDKs, examples, and workflow patterns	Smaller ecosystem - webhook-centric integrations

Code examples: verifying authenticity and building for reliability

Verify webhook signatures - Node.js

Verifying signatures is foundational to secure, reliable ingestion. This prevents spoofing, protects against replay, and gives you a stable contract for delivery acknowledgments.

// Node.js - Express middleware example
import crypto from 'crypto';
import express from 'express';

const app = express();
app.use(express.raw({ type: '*/*' })); // get raw body for signature calc

// HMAC verification for this platform
function verifyPlatformSignature(req, secret) {
  const timestamp = req.header('X-Platform-Timestamp');
  const signature = req.header('X-Platform-Signature'); // hex digest
  if (!timestamp || !signature) return false;

  // Prevent replay - allow small clock skew only
  const age = Math.abs(Date.now() - Number(timestamp));
  if (age > 5 * 60 * 1000) return false;

  const hmac = crypto.createHmac('sha256', secret);
  hmac.update(timestamp + '.' + req.body);
  const expected = hmac.digest('hex');
  return crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected));
}

app.post('/webhooks/inbound', (req, res) => {
  const ok = verifyPlatformSignature(req, process.env.PLATFORM_SECRET);
  if (!ok) return res.status(401).send('Invalid signature');

  const event = JSON.parse(req.body.toString());
  // Idempotency: dedupe by event.id or event.dedupe_key
  // Process message...
  return res.status(204).send(); // 2xx to stop retries
});

app.listen(3000);

Verify CloudMailin signatures - Python

# Flask example
import hmac, hashlib
from flask import Flask, request, abort

app = Flask(__name__)
SECRET = b'your-cloudmailin-shared-secret'

def verify_cloudmailin_signature(raw_body, signature_header):
  if not signature_header:
    return False
  expected = hmac.new(SECRET, raw_body, hashlib.sha256).hexdigest()
  # Use hmac.compare_digest for constant-time comparison
  return hmac.compare_digest(signature_header, expected)

@app.route('/webhooks/cloudmailin', methods=['POST'])
def cloudmailin():
  sig = request.headers.get('X-CloudMailin-Signature')
  if not verify_cloudmailin_signature(request.get_data(), sig):
    abort(401)
  payload = request.get_json()
  # Idempotency: combine payload.get('headers', {}).get('Message-Id') with envelope data
  return ('', 204)

Polling missed events via REST

When you want maximum certainty that nothing slips through, pair webhooks with a lightweight polling loop. Fetch unacknowledged events and confirm processing explicitly.

# Bash + curl example
API_BASE="https://api.example.test/v1"
TOKEN="sk_live_abc123"

# Fetch a page of pending messages not yet acknowledged by webhook
curl -sS -H "Authorization: Bearer $TOKEN" \
  "$API_BASE/messages?status=pending&limit=50" | jq '.items[] | {id, received_at, subject: .headers.subject}'

# Acknowledge after you have safely persisted the message
curl -sS -X POST -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"status":"processed"}' \
  "$API_BASE/messages/evt_01HV4E5GGQ4B8S6XJ4H3F2C9Q2/ack"

MX configuration snippet

DNS hygiene is a big part of inbound deliverability. Always configure multiple MX records with sensible priorities. Example using a subdomain dedicated to inbound processing:

; Zone file snippet for inbound.yourdomain.com
inbound  300  IN  MX  10  mx1.inbound-host.example.
inbound  300  IN  MX  20  mx2.inbound-host.example.

; Optional - publish an MTA-STS policy if you want senders to require TLS
_mta-sts  3600 IN  TXT "v=STSv1; id=20260502T01"
mta-sts   3600 IN  CNAME mta-sts-host.example.

Use a dedicated subdomain for application email to reduce blast radius, keep SPF and DMARC policies for your primary domain independent, and simplify observability and testing.

Performance and reliability under real-world conditions

Inbound deliverability is tested at the edges, not on the happy path. Here are the scenarios that separate strong platforms from weak ones:

• Attachment-heavy senders: oversized messages are streamed to object storage and referenced by secure URLs to prevent timeouts. CloudMailin follows a similar pattern using metadata and links rather than inlining everything into the webhook payload.
• Temporary remote failures: if a sender temporarily fails the SMTP handshake, the receiving MTAs keep connections open appropriately and avoid aggressive throttling that would cascade into deferrals. Both platforms are tuned to accept legitimate transactional mail without greylisting delays.
• Webhook outages: robust retry with exponential backoff and jitter prevents retry storms and lets downstream systems recover gracefully. The platform adds an explicit polling path for reconciliation, while CloudMailin encourages webhook-first designs.
• Duplicate delivery prevention: both services encourage idempotency keys. In practice, combine the provider event ID, the Message-ID, and the envelope triplet (MAIL FROM, RCPT TO, and Date) to guarantee exactly-once processing in your application.
• Monitoring and alerts: acceptance rate, 4xx deferrals by reason, 5xx rejects by rule, and end-to-end webhook success rates should be tracked. Build alerts for sudden drops or spikes in rejects to catch DNS misconfigurations or upstream sender outages quickly.

Verdict: which is better for email deliverability?

Both services are capable of reliable inbound acceptance when correctly configured. CloudMailin offers a simple and solid webhook-centric approach. If your team prefers a broader developer surface, a polling fallback in addition to webhooks, and detailed authentication results in standardized JSON, MailParse is the safer choice for mission-critical email-deliverability pipelines. The competitor's smaller ecosystem and fewer integration patterns may require you to build more glue code yourself.

FAQ