Why email deliverability matters for inbound email parsing
Email-deliverability is not only about sending messages to inboxes. For inbound workflows, it is about ensuring reliable email receipt every time a customer, system, or vendor sends your application a message. If your service cannot accept an email due to DNS drift, TLS misconfiguration, webhook timeout, or MIME oddities, critical workflows fail. Signups that rely on reply-to-verify loops stall, support tickets do not get created, and automated billing workflows break. Choosing an inbound email platform means choosing a deliverability strategy that covers DNS configuration, transport security, parsing correctness, retries, and monitoring end to end.
In this comparison, we evaluate how two platforms handle inbound email deliverability: a purpose-built parsing service and Amazon SES, the AWS Simple Email Service for receiving and processing email. We focus on the capabilities that keep messages flowing under real-world conditions, not just on feature lists.
For a practical checklist you can implement right away, see the Email Deliverability Checklist for SaaS Platforms. If you are planning foundational work, the Email Infrastructure Checklist for SaaS Platforms provides a solid baseline.
How MailParse handles email deliverability
This platform is designed for inbound-first workflows. It issues instant email addresses, accepts messages, parses MIME into structured JSON, then delivers that JSON to your application via webhook or a REST polling API. The deliverability model targets the entire path from DNS to your consumer code.
DNS and MX configuration
- Flexible addressing: use provider-issued addresses for zero-DNS setup during development, or point a subdomain's MX records at the platform for production.
- Clear DNS guidance: lower MX preference values are treated as higher priority. Keep MX TTLs moderate, such as 300 to 900 seconds, to balance agility during migrations with DNS cache stability.
- SPF and DKIM: these records affect outbound trust. For inbound receipt, focus on correct MX targets and consistent TTLs. If you forward messages elsewhere, consider SRS to preserve SPF.
Transport security and acceptance
- Opportunistic TLS with modern ciphers. If a sender offers STARTTLS, inbound gateways negotiate encryption. If not, SMTP gracefully continues so you do not lose messages from legacy systems.
- Consistent acceptance semantics. Temporary upstream errors trigger sender retries in accordance with SMTP 4xx guidance, reducing drop risk during transient network issues.
Parsing integrity
- Streaming MIME parsing to structured JSON, including headers, text, HTML, and attachments. This reduces backpressure on your webhook and removes the need to write MIME handling code.
- Normalization of common edge cases such as missing charsets, mixed line endings, and nested multiparts, so your application receives consistent fields every time.
Delivery to your application
- Webhook-first delivery with automatic retries on non-2xx responses. Retries follow exponential backoff to reduce thundering herds while keeping time-to-recovery short.
- Idempotent events identified by a stable message or event ID so you can safely retry database operations without double processing.
- REST polling as a fallback. If your webhook is down for maintenance, poll a queue endpoint, process, then acknowledge to prevent re-delivery.
Monitoring and observability
- Delivery logs and per-message status make it easy to confirm whether an email was accepted, parsed, and delivered to your webhook.
- Latency indicators help you spot upstream congestion or downstream endpoint slowness before it becomes visible to users.
The net effect is predictable inbound email deliverability: correct DNS setup, secure transport when available, robust parsing, and resilient delivery mechanisms all the way to your application code.
How Amazon SES handles email deliverability
Amazon SES is part of AWS and is widely used for sending. It also supports inbound receiving in specific regions. Deliverability on SES is robust, but you assemble the pipeline from several AWS components. This yields fine-grained control with a steeper learning curve.
DNS and inbound setup
- Region-bound MX: you set your domain or subdomain MX to an AWS regional endpoint like inbound-smtp.region.amazonaws.com. Receiving regions are limited, so choose a region that supports inbound.
- Domain verification: while often discussed for sending, domain identity is a common prerequisite in SES workflows and worth completing up front.
Receipt rules and processing
- Receipt rule sets define what happens to inbound mail. Common actions include storing the raw MIME in S3, publishing to an SNS topic, invoking a Lambda, or adding headers.
- Spam and virus scanning can be enabled per rule to reduce noise.
- TLS requirements can be configured so that only encrypted connections are accepted.
Parsing and application delivery
- SES delivers raw emails. You parse MIME yourself, often in Lambda. Libraries like the Node.js mailparser can convert RFC 5322 text into usable JSON.
- For webhook-style consumption, you may wire SNS to an HTTPS endpoint that receives notifications and then fetches the raw message from S3.
Observability and operations
- CloudWatch metrics and logs cover SES, Lambda, SNS, and S3. You gain deep visibility, but it spans multiple services, which increases operational surface area.
- Retries vary by component. SNS retries to HTTPS endpoints on non-2xx. Lambda has its own retry and dead letter queue options. You coordinate these to prevent duplication and ensure delivery.
The result can be highly reliable inbound pipelines, provided you maintain the supporting AWS infrastructure and keep rule sets, IAM permissions, and parsing code in sync.
Side-by-side comparison of email deliverability features
| Deliverability feature | MailParse | Amazon SES |
|---|---|---|
| Setup time for inbound | Minutes with provider-issued addresses or simple MX change | Moderate to complex due to rule sets, S3 or Lambda, and IAM |
| DNS guidance | Focused inbound docs, MX-first, clear TTL recommendations | Comprehensive AWS docs, but spread across multiple services |
| TLS for inbound SMTP | Opportunistic TLS with graceful fallback | Configurable TLS requirement per receipt rule |
| Parsing to JSON | Built in, structured JSON published to webhook or API | Do it yourself in Lambda or external service |
| Webhook delivery | Native, with automatic retries and idempotent event IDs | Via SNS HTTPS, with SNS-managed retries |
| REST polling fallback | Available for maintenance windows or failover | Not native, requires custom code or periodic S3 scans |
| Spam and virus scanning | Provider-side filtering and normalization | Enable spam and virus scanning per receipt rule |
| Operational complexity | Single platform, minimal moving pieces | Multiple AWS services, IAM, and region constraints |
| Monitoring and logs | Message-level statuses and delivery logs | CloudWatch across SES, SNS, Lambda, and S3 |
| Handling malformed MIME | Parser normalizes common edge cases | Developer-managed parsing, quality depends on your code |
Code examples
Webhook receiver with MailParse
The platform pushes a JSON payload representing the parsed email. Your only job is to validate, process idempotently, and return HTTP 200. Here is an Express.js example that logs core fields, stores attachments, and guards against duplicate processing.
import express from "express";
import crypto from "crypto";
const app = express();
app.use(express.json({ limit: "25mb" }));
// Optional: verify a shared secret header if configured on the webhook
function verifySignature(req) {
const sig = req.get("X-Signature") || "";
const body = JSON.stringify(req.body);
const expected = crypto.createHmac("sha256", process.env.WEBHOOK_SECRET).update(body).digest("hex");
return crypto.timingSafeEqual(Buffer.from(sig), Buffer.from(expected));
}
const seen = new Set(); // replace with a durable store in production
app.post("/inbound", (req, res) => {
// if you set a secret, uncomment the check below:
// if (!verifySignature(req)) return res.status(401).send("invalid signature");
const event = req.body;
const id = event.id || event.messageId;
if (seen.has(id)) return res.status(200).send("duplicate");
seen.add(id);
// Core fields provided by the parser
const { from, to, subject, text, html, headers, attachments = [] } = event;
console.log("From:", from);
console.log("Subject:", subject);
console.log("First 120 chars:", (text || html || "").slice(0, 120));
// Store attachments
for (const a of attachments) {
// a has fields like filename, contentType, size, and a base64 or URL for retrieval
// persist or upload as needed
}
// Acknowledge promptly to avoid retries, then process asynchronously
res.status(200).send("ok");
});
app.listen(3000, () => console.log("Inbound webhook listening on 3000"));If you need a maintenance window, switch your integration to polling temporarily. Process unacknowledged messages in batches, then re-enable the webhook. This pattern keeps email deliverability resilient even when you deploy frequently.
Amazon SES inbound via SNS and S3
With amazon-ses you typically configure a receipt rule to write raw MIME to S3 and publish an SNS notification. Your HTTPS endpoint confirms the SNS subscription, then retrieves the object from S3 and parses it. The following example shows a Lambda function that parses the message using a Node.js library and posts structured JSON to your application's inbound endpoint.
import { S3Client, GetObjectCommand } from "@aws-sdk/client-s3";
import fetch from "node-fetch";
import { simpleParser } from "mailparser"; // npm install mailparser
const s3 = new S3Client({});
export const handler = async (snsEvent) => {
for (const record of snsEvent.Records) {
const msg = JSON.parse(record.Sns.Message);
// SES stores the raw email in S3 and adds bucket + object keys
const bucket = msg.receipt.action.bucketName;
const key = msg.receipt.action.objectKey;
const obj = await s3.send(new GetObjectCommand({ Bucket: bucket, Key: key }));
const raw = await streamToString(obj.Body);
const parsed = await simpleParser(raw);
const payload = {
id: parsed.messageId,
from: parsed.from?.text,
to: parsed.to?.text,
subject: parsed.subject || "",
text: parsed.text || "",
html: parsed.html || "",
headers: Object.fromEntries(parsed.headerLines.map(h => [h.key, h.line])),
attachments: (parsed.attachments || []).map(a => ({
filename: a.filename, contentType: a.contentType, size: a.size
}))
};
// Deliver to your app
const resp = await fetch(process.env.INBOUND_WEBHOOK_URL, {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify(payload)
});
if (!resp.ok) {
// Let Lambda retry or send to a dead letter queue
throw new Error(`Webhook failed with ${resp.status}`);
}
}
};
async function streamToString(stream) {
const chunks = [];
for await (const chunk of stream) chunks.push(chunk);
return Buffer.concat(chunks).toString("utf-8");
}This pattern is reliable and scalable on amazon ses, but it involves several moving parts: SES rules, S3 storage, SNS delivery semantics, IAM permissions, Lambda concurrency, and your webhook endpoint. It is powerful, yet the complexity requires disciplined operations.
Performance and reliability under real conditions
DNS drift and cutovers
For inbound reliability, treat DNS as code. Use version-controlled templates for MX records, keep TTLs modest, and schedule cutovers during low-traffic windows. Validate that your registrar and DNS provider accept the MX target exactly as published by your email platform. After a cutover, query authoritative nameservers directly to confirm propagation before removing old records.
Latency and retries
- Webhook paths should acknowledge quickly. Persist the payload, enqueue a job, then reply to the sender with HTTP 200. Slow handlers cause retry storms that can look like deliverability failure.
- Use idempotency keys. Store last-seen event IDs, message IDs, or hashes. Treat re-deliveries as expected rather than as errors.
- Graceful backoff. Whether your provider retries or SNS does it for you, confirm exponential backoff is in place and set a maximum retry horizon.
MIME edge cases
- Test with messages that include inline images, calendar invites, plain-text only bodies, and complex multipart alternatives.
- Expect non-ASCII headers, duplicate header fields, and missing charsets. Your parser or platform should normalize these without data loss.
Monitoring the full pipeline
- Seed inboxes: routinely send test emails from different providers and geographic regions. Alert when any step shows persistent latency or failure.
- Correlate logs: connect SMTP acceptance timestamps, parsing time, webhook delivery time, and application processing time to spot where delays accumulate.
Looking for practical inbound patterns that push reliability further, such as reply-to-ticket processing and approval workflows by email, browse Top Inbound Email Processing Ideas for SaaS Platforms.
Verdict: which is better for email deliverability?
If your goal is fast, reliable inbound email with minimal infrastructure and strong parsing correctness, MailParse delivers a focused developer experience that simplifies DNS, parsing, and delivery semantics. The combination of webhook-first delivery with retries and a polling fallback is pragmatic for teams that deploy frequently and value operational clarity.
If you need deep integration with the AWS ecosystem, amazon ses is excellent. You get granular control over TLS requirements, spam and virus scanning, and downstream processing with Lambda, S3, and SNS. The tradeoff is increased complexity. You must design, test, and monitor multiple services to achieve the same end-to-end email deliverability guarantees.
In short, choose the platform that matches your operating model. If you prefer smaller blast radius and out-of-the-box JSON parsing, go with MailParse. If you are already all-in on AWS and want to compose a pipeline from building blocks, amazon-ses is a strong option. Both can achieve high reliability when configured and monitored well.
FAQ
Do I need SPF, DKIM, or DMARC for inbound email deliverability?
SPF and DKIM primarily protect outbound sender reputation. For inbound receipt, deliverability depends on correct MX records, transport security, and resilient delivery to your application. That said, if you forward emails from your inbound flow to other destinations, implement SRS and preserve DKIM signatures where possible to avoid failures at the next hop. DMARC policies might influence forwarding behavior, so test forwarding scenarios carefully.
How can I test end-to-end inbound reliability?
Automate seed tests. Send messages hourly from multiple providers, include attachments and non-ASCII headers, and verify that each message appears in your application with the expected fields. Alert on missing messages or delivery latency beyond a threshold. Correlate SMTP acceptance, parsing timestamps, and webhook delivery logs to pinpoint bottlenecks.
What message size limits should I enforce?
Set a maximum allowed size that fits your application's needs and provider constraints, such as 10 to 25 MB. Enforce the limit at your webhook or Lambda entry point and return a clear error path in your application UI. If users routinely send large attachments, prefer streaming storage and link sharing rather than embedding massive payloads in email.
How do webhook failures affect email deliverability?
They do not block SMTP acceptance. The provider should accept the message, then deliver to your webhook asynchronously with retries. Your responsibility is to acknowledge quickly, store payloads durably, and process idempotently. If an outage persists, switch to a polling fallback or a dead letter workflow to keep data flowing.
Is TLS required to receive email?
It depends on your policy. Opportunistic TLS improves privacy without rejecting legacy senders. Strict TLS requirements increase security but can reduce deliverability from older systems. On amazon ses you can enforce TLS in receipt rules. With most inbound platforms, opportunistic TLS is enabled by default, which offers a practical balance.