Email Authentication: MailParse vs Amazon SES

Why Email Authentication Matters When Choosing an Inbound Email Parsing Service

Email authentication is not only a sending-side problem. If your application ingests inbound messages - support replies, automated bounce reports, supplier notices, customer uploads - your backend needs to verify who actually sent the email. Validating SPF, DKIM, and DMARC on receipt prevents spoofing, improves trust scoring, helps triage abuse, and ensures that downstream automations act on legitimate content. For developer teams building email-driven workflows, email-authentication should be first-class data in your parsing pipeline, not an afterthought.

This comparison focuses on the email authentication capabilities of two options: a developer-focused parsing platform and Amazon SES for receiving. You will see how SPF, DKIM, and DMARC verdicts are surfaced, what JSON structure you can consume, how webhooks or functions are wired, and how each handles edge cases like forwarding or multiple DKIM signatures.

For a wider perspective on production readiness, see these related resources:

How MailParse Handles Email Authentication

The platform validates SPF, DKIM, and DMARC at ingest so developers receive a single structured payload that includes the raw message, parsed MIME, and normalized authentication results. You get fine-grained details - not just pass or fail - which makes it straightforward to implement policy decisions in code.

What gets validated

SPF - Evaluates HELO and MAIL FROM identities against the sender IP using RFC 7208. Includes handling for redirect and include, DNS lookup limits, and temp-error detection.
DKIM - Verifies each DKIM-Signature with selector lookups, canonicalization support for simple and relaxed, l-tag handling, and aggregated results per signature.
DMARC - Computes alignment against Header From, applies p and sp policies with relaxed or strict alignment, and surfaces the final disposition alongside the policy discovered in DNS.
Authentication-Results - Parses and normalizes existing Authentication-Results headers from upstream relays for visibility without trusting them blindly.
ARC - Exposes the ARC-Seal and ARC-Message-Signature chain when present so your app can make informed decisions for forwarded messages where SPF may fail.

Webhook and REST payload shape

On inbound delivery, a webhook is POSTed to your endpoint with a JSON body. You can also poll a REST endpoint to retrieve the same fields. A simplified excerpt looks like this:

{
  "id": "evt_3f92d7",
  "timestamp": "2026-04-29T13:12:44Z",
  "envelope": {
    "helo": "mail.outbound.example.net",
    "mail_from": "bounce@mailer.example.net",
    "rcpt_to": ["inbox+ticket-842@yourapp.io"],
    "remote_ip": "203.0.113.45"
  },
  "header_from": "alerts@example.com",
  "authentication": {
    "spf": {
      "domain": "example.net",
      "result": "pass",
      "scope": "mfrom",
      "explanation": null
    },
    "dkim": [
      {
        "domain": "example.com",
        "selector": "s1",
        "canonicalization": "relaxed/relaxed",
        "result": "pass",
        "covered_headers": ["from","to","subject","date","message-id"]
      },
      {
        "domain": "mailer.example.net",
        "selector": "m2026",
        "canonicalization": "relaxed/relaxed",
        "result": "pass",
        "covered_headers": ["from","to","subject"]
      }
    ],
    "dmarc": {
      "header_from": "example.com",
      "alignment": { "spf": "relaxed", "dkim": "relaxed" },
      "result": "pass",
      "policy": { "domain": "example.com", "p": "quarantine", "sp": "none", "pct": 100 },
      "disposition": "none",
      "reason": null
    },
    "arc": {
      "chain_present": true,
      "sets": 2,
      "evaluated": false
    },
    "raw_authentication_results": [
      "mx.receiver.net; spf=pass smtp.mailfrom=mailer.example.net; dkim=pass header.d=example.com; dmarc=pass header.from=example.com"
    ]
  },
  "mime": {
    "subject": "Production alert",
    "text": "...",
    "html": "...",
    "attachments": []
  }
}

With this structure you can implement rules like: accept only DMARC aligned messages, quarantine when DMARC fails with a reject policy, or whitelist specific selectors for transactional streams. The same payload includes the complete raw message for archival or reprocessing.

How Amazon SES Handles Email Authentication

Amazon SES (AWS Simple Email Service) provides email receiving with optional processing via receipt rules. You define a receipt rule set for your domain, then attach actions such as S3 storage, SNS notifications, or Lambda invocations. When a message is received, SES evaluates authentication signals and provides verdicts in the receipt context.

What SES exposes

SPF verdict - Available as spfVerdict.status in the Lambda event or in SNS delivered JSON when using receipt rules.
DKIM verdict - dkimVerdict.status indicates pass or fail. SES validates the message against DKIM signatures present in the headers.
DMARC verdict and policy - dmarcVerdict.status and dmarcPolicy reflect evaluation against the sender's domain policy.
Raw message - You can configure an action to store the raw email in S3 for further parsing.

SES gives you essential email-authentication signals but you will typically combine multiple AWS services to build a complete pipeline. A common architecture uses an S3 action to store the raw message, an SNS action to fan out receipt notifications, and a Lambda function to implement business logic. For teams already operating inside AWS, this is familiar. For others, it increases setup effort and cognitive load.

Important notes for developers:

The receipt object includes SPF, DKIM, and DMARC verdicts but does not expose per-signature detail like selectors or covered headers. If you need that, you must fetch the raw email from S3 and parse DKIM manually.
At the time of writing, the receipt event does not include an ARC verdict. If forwarded mail is common in your workflows, you will need to implement ARC evaluation yourself using the raw message.
Scaling is tied to AWS account limits and Lambda concurrency. Latency is usually low, but cold starts and network egress to downstream systems should be considered.

Side-by-Side Comparison of Email Authentication Features

Feature	MailParse	Amazon SES
SPF verdict in structured JSON	Yes - domain, scope, result, explanation	Yes - `spfVerdict.status` only
DKIM details	Per-signature array with domain, selector, result, canonicalization	Aggregate verdict via `dkimVerdict.status`
DMARC alignment computation	Yes - alignment against Header From plus discovered policy and disposition	Yes - `dmarcVerdict.status` and `dmarcPolicy`
ARC exposure	Exposes chain presence and metadata for downstream evaluation	Not exposed in receipt event
Authentication-Results normalization	Parsed and included for observability	Only via raw message parsing
Delivery mechanism	Direct webhook POST and REST polling	Receipt rules to SNS, S3, or Lambda
Setup complexity	Simple - provision address, set webhook, start receiving	Higher - domains, rule sets, IAM, permissions, optional S3, SNS, Lambda
Best for	Teams that want immediate JSON with rich auth signals	Teams deeply invested in AWS who prefer Lambda-centric workflows

Code Examples: Developer Experience for Email Authentication

MailParse example: accept only DMARC-aligned messages

Node.js Express endpoint that verifies DMARC alignment from the webhook payload and archives the message only when it passes or when policy is none.

import express from "express";
import crypto from "crypto";

const app = express();
app.use(express.json({ limit: "10mb" }));

// Optional verification of webhook signature
function verifySignature(req) {
  const sig = req.header("X-Mail-Signature");
  const timestamp = req.header("X-Mail-Timestamp");
  const secret = process.env.WEBHOOK_SECRET;
  const payload = timestamp + "." + JSON.stringify(req.body);
  const hmac = crypto.createHmac("sha256", secret).update(payload).digest("hex");
  return crypto.timingSafeEqual(Buffer.from(sig), Buffer.from(hmac));
}

app.post("/inbound", async (req, res) => {
  if (!verifySignature(req)) return res.status(401).send("bad signature");

  const auth = req.body.authentication;
  const dmarc = auth?.dmarc;

  const passes = dmarc?.result === "pass";
  const policy = dmarc?.policy?.p || "none";

  // Example policy: accept if pass, or if policy is none
  if (passes || policy === "none") {
    // Archive, create ticket, etc.
    console.log("Accepted message", req.body.id, "result:", dmarc?.result);
    return res.status(200).send("ok");
  }

  // Quarantine or flag if policy is quarantine or reject
  console.warn("Rejected message", req.body.id, "result:", dmarc?.result, "policy:", policy);
  return res.status(202).send("quarantined");
});

app.listen(3000, () => console.log("listening on 3000"));

Amazon SES example: evaluate SPF, DKIM, DMARC in a Lambda function

This Node.js handler reads verdicts directly from the SES receipt event. If you need more detail, fetch the raw message from S3 and perform additional parsing.

export const handler = async (event) => {
  const record = event.Records[0];
  const ses = record.ses;
  const r = ses.receipt;

  const spf = r.spfVerdict?.status || "UNKNOWN";
  const dkim = r.dkimVerdict?.status || "UNKNOWN";
  const dmarc = r.dmarcVerdict?.status || "UNKNOWN";
  const policy = r.dmarcPolicy || "none";

  const accepted =
    dmarc === "PASS" ||
    (dmarc !== "FAIL" && policy === "none");

  if (accepted) {
    console.log("Accepting message", ses.mail.messageId, { spf, dkim, dmarc, policy });
    // Optionally read raw email from S3 if you configured an S3 action
    return { disposition: "ACCEPT" };
  } else {
    console.warn("Quarantining or flagging", ses.mail.messageId, { spf, dkim, dmarc, policy });
    // SES Receipt Rules determine final action, Lambda can write flags to a datastore
    return { disposition: "QUARANTINE" };
  }
};

Performance and Reliability in Authentication Evaluation

DNS lookups and timeouts

Authentication checks rely on DNS. SPF can involve multiple includes and redirects, and DKIM requires TXT fetches per selector. A robust receiver should implement caching, concurrency limits, and clear timeouts to avoid stuck evaluations.

The parsing platform performs controlled DNS lookups with caps on SPF mechanisms and lookups. Results include temp-error states so your app can differentiate network issues from policy failures.
Amazon SES operates inside AWS with optimized resolvers. Verdicts are computed reliably, but the receipt event does not differentiate granular DNS failure causes. You will see statuses like TEMPFAIL or FAIL without deeper metadata.

Forwarding and mailing lists

Forwarders often break SPF because the envelope sender does not match the forwarding IP. DKIM usually survives unless the message is modified. DMARC provides a balanced approach by allowing alignment via either SPF or DKIM.

The parsing platform exposes ARC headers so your application can choose to trust a valid ARC chain when SPF fails after forwarding. It also includes per-signature DKIM details to reason about which identity aligns.
SES provides DMARC and DKIM verdicts. ARC is not presented in the receipt event. To evaluate ARC you need to fetch the raw message and implement ARC validation logic yourself.

Multiple DKIM signatures and alignment

Transactional systems sometimes sign with both the primary domain and a mailer subdomain. Your app may need to know which signature aligned with Header From for DMARC pass.

The parsing platform returns a DKIM array so you can map selectors to domains and decide which signature to trust in downstream workflows.
SES reports an aggregate DKIM verdict. For per-signature data you must parse the raw headers.

Idempotency and retries

In production, webhooks may be retried and Lambda may be invoked more than once.

Webhook deliveries include stable event IDs so you can implement idempotent processing with a simple seen-set.
SES retries depend on the action configuration. Lambda is at-least-once, so apply idempotency in your handler using the message ID or a dedupe store.

Verdict: Which Is Better for Email Authentication?

If you need immediate, developer-friendly JSON that includes SPF, DKIM, DMARC, ARC visibility, and normalized Authentication-Results, with minimal setup and a simple webhook-first workflow, MailParse offers the most actionable surface for inbound email-authentication.

If you already run your stack on AWS and prefer to orchestrate with receipt rules, SNS, S3, and Lambda, Amazon SES provides reliable verdicts for SPF, DKIM, and DMARC. Be prepared to add raw message parsing for deeper details like per-signature DKIM, ARC evaluation, or custom normalization. The learning curve is steeper due to IAM and multi-service wiring, but the platform scales well inside AWS.

Either route can be production-ready. Choose the one that best reduces glue code in your pipeline and gives your developers the signals they need to make safe decisions on inbound email.

FAQ

What is the difference between SPF, DKIM, and DMARC on inbound email?

SPF verifies that the connecting IP is authorized to send for the envelope domain. DKIM verifies a cryptographic signature in the message headers that ties the content to a domain. DMARC uses alignment rules and a published policy to decide how to treat messages based on SPF and DKIM results relative to the Header From domain. On receipt, you evaluate all three to determine whether to accept, flag, or quarantine the message.

Does Amazon SES validate DMARC for received emails?

Yes. In the SES receipt event, you will see dmarcVerdict.status and dmarcPolicy. If you need to understand which identifier aligned or why a failure occurred, fetch the raw email and parse headers such as Authentication-Results, DKIM-Signature, and From.

How should I handle forwarded emails that fail SPF?

Forwarding often breaks SPF because the forwarder's IP is not authorized for the original domain. Rely on DKIM and DMARC alignment first. If available, evaluate ARC to preserve original authentication. As a rule of thumb: do not reject solely on SPF fail if DKIM passes and DMARC aligns.

Can I trust the Authentication-Results header from upstream systems?

Treat it as telemetry, not ground truth. Always perform your own SPF, DKIM, and DMARC checks or use a receiver that does so on your behalf and surfaces normalized results. Upstream Authentication-Results can be spoofed by malicious senders unless it is added by a trusted relay you control.

Do I need strict alignment for DMARC to pass?

Not necessarily. DMARC supports relaxed alignment by default, which allows subdomain relationships to pass. Many senders publish relaxed alignment to reduce breakage across forwarding and multi-tenant setups. Strict alignment is an option if you require exact domain matches and have tight control over your sending paths.