Email Authentication: MailParse vs Postmark Inbound

Why Email Authentication Capability Matters For Inbound Parsing

Email authentication is not only about outbound deliverability. When your product ingests user replies, support emails, and automated notifications, you need reliable verification that the message comes from who it claims. SPF, DKIM, and DMARC form the core of email-authentication for inbound pipelines. Without accurate and accessible authentication results, you risk processing spoofed messages, mis-attributing senders, or creating security gaps in workflows like ticket creation, user provisioning, or financial approvals.

Developers evaluating an inbound email processing service should look closely at how the platform captures, normalizes, and exposes authentication results. Key questions include:

• Does the service surface SPF, DKIM, and DMARC verdicts as structured fields, or do you have to parse raw headers like Authentication-Results yourself
• Can you inspect alignment details that DMARC depends on, such as adkim and aspf
• Is ARC parsing available for forwarded and mailing list scenarios where SPF breaks
• What delivery modes exist for consuming authentication results - webhook only, or is REST polling supported too
• How does the service behave with multiple DKIM signatures, complex header rewriting, or non-ASCII domains

The sections below compare how two developer-focused options handle email authentication in the inbound path: a modern parsing platform and Postmark Inbound. The focus is specifically on authentication accuracy, data shape, and the developer experience of consuming those results.

How MailParse Handles Email Authentication

MailParse inspects inbound SMTP sessions and the full MIME content to produce structured, explicit authentication outcomes. Results are normalized into dedicated SPF, DKIM, DMARC, and ARC objects so you do not need to parse Authentication-Results strings manually. The platform preserves raw headers for audit, while also computing alignment against the visible From domain with clear booleans and policy metadata.

Authentication Data Model

The webhook and REST payloads include an authentication block with fields designed for policy decisions and security automation:

• SPF: result, domain evaluated, mechanism matched, scope used (mfrom or helo), IP evaluated, and aligned boolean vs header From domain
• DKIM: array of signatures with result, domain, selector, canonicalization, body length tag, signature age, and aligned boolean per signature
• DMARC: result, policy discovered, organizational domain, adkim and aspf, aligned boolean, disposition recommendation, and explanations when fails
• ARC: chain depth, result, and per-seal outcomes for forwarded flows

This structure lets you codify rules like: allow if DMARC passes, or if DKIM passes and aligns even when SPF fails due to forwarding, or quarantine when DMARC fails and there is no valid ARC chain.

Webhook Delivery And HMAC Verification

Webhook events include an HMAC signature header so you can verify integrity before processing. The payload carries both the normalized authentication objects and the original headers, so audits and forensics are straightforward.

REST Polling API For Fault Tolerance

In addition to webhooks, a REST polling API lets you fetch messages by time range or by authentication state. Teams often combine both: accept webhooks for low latency, then run a periodic poller to reconcile any missed deliveries during maintenance windows.

For broader implementation guidance on how this data fits in your stack, see the Email Infrastructure Checklist for SaaS Platforms and the Top Inbound Email Processing Ideas for SaaS Platforms.

How Postmark Inbound Handles Email Authentication

Postmark Inbound focuses on a clear webhook that delivers parsed bodies, attachments, and headers. For authentication, the service typically adds results to Authentication-Results and related headers such as Received-SPF, and passes them through in the JSON payload's Headers array. That means SPF, DKIM, and DMARC outcomes are available, but they are not exposed as first class structured fields. Developers need to parse header values to extract verdicts and alignment signals.

In practice, you will inspect the Headers collection for entries named Authentication-Results or Received-SPF, then parse tokens like spf=pass, dkim=pass, and dmarc=pass. If you need alignment details or ARC interpretation, you will either parse additional parameters from the header or implement your own logic to map domains to Organizational Domains for DMARC alignment rules. Postmark's inbound webhook does not provide a REST polling alternative, so reliability hinges on your webhook availability and Postmark retry behavior.

Developers who are comfortable with header parsing can achieve robust email-authentication verification using this approach. For teams that prefer explicit fields and policy-aware alignment booleans, additional code is required on top of postmark-inbound payloads.

Side-by-Side Comparison - Email Authentication Features

Feature	MailParse	Postmark Inbound
Structured SPF result field	Yes - with mechanism, IP, scope, and alignment	No - parse from headers like Authentication-Results or Received-SPF
Structured DKIM result with multiple signatures	Yes - array with selector, domain, canonicalization, alignment	No - tokens available in headers, developer must parse
Structured DMARC verdict and alignment booleans	Yes - includes policy, adkim, aspf, disposition	No - DMARC status appears in Authentication-Results
ARC chain interpretation	Yes - chain depth and result	Headers included, interpretation left to developer
Original headers preserved	Yes	Yes
Webhook delivery	Yes - HMAC signed	Yes
REST polling option	Yes - fetch by time and filters	No - webhook only
Explicit alignment flags for SPF and DKIM	Yes - aligned per mechanism and signature	No - must compute alignment from headers
DMARC policy metadata surfaced	Yes - adkim, aspf, policy, org domain	Not as distinct fields
Edge-case normalization for forwarding	Yes - favors DKIM or ARC when SPF breaks	Developer must implement logic

Code Examples - Validating SPF, DKIM, And DMARC

Webhook Example - Structured Authentication Payload

The following example shows a webhook payload that exposes explicit email-authentication results. You verify the HMAC, then branch on the authentication object.

{
  "id": "msg_9f12c",
  "timestamp": "2026-04-25T10:12:22Z",
  "envelope": {
    "mailFrom": "alice@sender.example",
    "rcptTo": ["support@yourapp.io"],
    "clientIp": "203.0.113.9"
  },
  "headers": {
    "From": "Alice <alice@sender.example>",
    "To": "Support <support@yourapp.io>",
    "Subject": "Login issue",
    "Authentication-Results": "mx.example; spf=pass smtp.mailfrom=sender.example; dkim=pass header.d=sender.example; dmarc=pass header.from=sender.example"
  },
  "authentication": {
    "spf": {
      "result": "pass",
      "domain": "sender.example",
      "mechanism": "ip4",
      "scope": "mfrom",
      "ip": "203.0.113.9",
      "aligned": true
    },
    "dkim": [
      {
        "result": "pass",
        "domain": "sender.example",
        "selector": "s1",
        "canonicalization": "relaxed/relaxed",
        "aligned": true
      }
    ],
    "dmarc": {
      "result": "pass",
      "domain": "sender.example",
      "orgDomain": "sender.example",
      "policy": "reject",
      "adkim": "s",
      "aspf": "s",
      "aligned": true,
      "disposition": "none"
    },
    "arc": {
      "result": "none",
      "chain": 0
    }
  }
}

Node.js example routing decisions:

app.post("/inbound", verifyHmac, (req, res) => {
  const auth = req.body.authentication;
  const fromHeader = req.body.headers.From;

  if (auth.dmarc.result === "pass" && auth.dmarc.aligned) {
    return accept(res, "DMARC aligned");
  }

  // Forwarding-safe path: DKIM aligned is enough even if SPF failed
  const alignedDkim = (auth.dkim || []).some(sig => sig.result === "pass" && sig.aligned);
  if (alignedDkim) {
    return accept(res, "DKIM aligned");
  }

  // No alignment, quarantine or flag for review
  flagMessage(req.body.id, fromHeader, auth);
  return accept(res, "Flagged - no alignment");
});

function verifyHmac(req, res, next) {
  // Compute and verify signature header before processing
  next();
}
function accept(res, reason) {
  console.log("Accepted inbound:", reason);
  res.status(200).end();
}

REST Polling Example - Reliability Backstop

Use REST polling to reconcile any messages your webhook missed. Filter by authentication results to prioritize review queues.

# Fetch the last 15 minutes of mail where DMARC failed
curl -s "https://api.example.com/v1/inbound?since=2026-04-25T09:57:00Z&dmarc.result=fail" \
  -H "Authorization: Bearer <token>" | jq '.items[] | {id, from: .headers.From, dmarc: .authentication.dmarc}'

Postmark Inbound - Parse Authentication From Headers

Postmark Inbound provides authentication results in headers inside the webhook. You can extract them like this:

{
  "From": "alice@sender.example",
  "FromFull": { "Email": "alice@sender.example", "Name": "Alice" },
  "To": "support@yourapp.io",
  "Cc": "",
  "Subject": "Login issue",
  "TextBody": "I cannot log in",
  "HtmlBody": "<p>I cannot log in</p>",
  "Headers": [
    { "Name": "Authentication-Results", "Value": "mx.postmark; spf=pass smtp.mailfrom=sender.example; dkim=pass header.d=sender.example; dmarc=pass header.from=sender.example" },
    { "Name": "Received-SPF", "Value": "pass ..." }
  ],
  "Attachments": []
}

Node.js header parsing example:

app.post("/postmark-inbound", (req, res) => {
  const headers = req.body.Headers || [];
  const ar = headers.find(h => h.Name.toLowerCase() === "authentication-results");
  let spf = "none", dkim = "none", dmarc = "none", aligned = false;

  if (ar) {
    const v = ar.Value.toLowerCase();
    spf = /spf=(pass|fail|softfail|neutral|none|temperror|permerror)/.exec(v)?.[1] || "none";
    dkim = /dkim=(pass|fail|none|temperror|permerror)/.exec(v)?.[1] || "none";
    dmarc = /dmarc=(pass|fail|none)/.exec(v)?.[1] || "none";
    // Simple alignment heuristic - robust alignment requires org domain extraction
    const fromHeader = (req.body.From || "").split("@")[1] || "";
    const dkimDomain = /header\.d=([^;\s]+)/.exec(v)?.[1] || "";
    aligned = dkim === "pass" && dkimDomain.endsWith(fromHeader);
  }

  if (dmarc === "pass" || aligned) {
    // Proceed
  } else {
    // Flag or quarantine
  }
  res.status(200).end();
});

This approach is reliable if you consistently parse Authentication-Results and handle edge cases. Keep in mind that Postmark Inbound is webhook-only, so you should set up robust retries on your side. For a broader operational checklist, review the Email Deliverability Checklist for SaaS Platforms.

Performance And Reliability - Handling Edge Cases In Email Authentication

• Forwarding breaks SPF: When a message is forwarded, the forwarding server's IP often fails the original domain's SPF. A practical inbound pipeline should prefer DKIM alignment or a valid ARC chain over SPF in these cases. MailParse surfaces DKIM alignment and ARC chain results explicitly so routing can remain deterministic.
• Multiple DKIM signatures: Some senders sign with both 2048-bit and 1024-bit keys, or with a list provider domain and the brand domain. The platform should report each signature separately with alignment booleans so you can accept the first aligned pass. Postmark Inbound includes all raw headers, but you must parse signature domains from Authentication-Results or the individual DKIM-Signature headers yourself.
• DMARC alignment policies: Strict alignment requires exact domain match, while relaxed allows Organizational Domain alignment. A good parser will compute that using the PSL. If alignment is not available as a field, you need to implement org domain derivation and compare against header From. This is additional work for postmark-inbound users.
• ARC evaluation: Some enterprise relays add ARC to preserve authentication. If ARC validates with a reputable chain, you may treat the message as authenticated even when SPF fails. An explicit ARC result is convenient for policy engines.
• Internationalized domains and Unicode headers: Authentication evaluation should normalize punycode and handle IDNA safely. Headers should be preserved so audits remain reproducible.
• Operational resilience: Webhook-only delivery couples your ingestion pipeline to your application health. A REST polling option reduces operational risk, since you can recover messages after outages without manual requeue steps.

Verdict - Which Is Better For Email Authentication

For teams that want authentication results as explicit, structured fields with alignment, ARC, and DMARC policy details out of the box, MailParse provides a faster path to secure decisions. The REST polling API is a practical advantage when you need fault tolerance beyond webhooks.

If you are comfortable parsing headers and maintaining your own DMARC alignment and ARC evaluation logic, Postmark Inbound can deliver what you need through its webhook. You will trade some development time to parse and interpret Authentication-Results, and you will rely on webhook availability without a polling option.

Both approaches can be made secure. The difference is how much parsing logic you prefer to build and operate yourself, and whether you want a webhook-only model or the flexibility of REST polling for recovery. For additional architecture ideas and patterns that benefit from strong authentication, see the Top Email Parsing API Ideas for SaaS Platforms.

FAQ

Do SPF, DKIM, and DMARC always agree

No. SPF can fail due to forwarding, DKIM can fail if an intermediary modifies the message body or headers, and DMARC can still pass if at least one of SPF or DKIM passes and aligns with the header From domain. Your inbound logic should prefer DMARC where available, and fall back to DKIM alignment or ARC when forwarding is likely.

What does DMARC alignment actually check

DMARC alignment checks that the domain in either the SPF identity (Mail From) or the DKIM signature's d= tag aligns with the visible From domain. Strict alignment requires an exact match, relaxed alignment allows Organizational Domain matches. The adkim and aspf tags in DNS publish which mode each pathway should follow.

How do I handle multiple DKIM signatures in practice

Evaluate each signature independently. Accept if any signature passes and aligns with the header From domain. Keep diagnostics for all signatures for troubleshooting. If none align, but ARC validates and DMARC would otherwise pass, you can follow your policy to accept with lower trust or flag the message.

Why is REST polling valuable if I already use webhooks

Webhooks are ideal for low latency. REST polling is a safety net that lets you reconcile messages missed during deployments, network issues, or rate limiting. Polling by authentication state is especially useful when you need to triage messages with DMARC failures separately from the main queue.

Can I rely on Authentication-Results alone without structured fields

Yes, many systems do. You will need robust parsing, attention to corner cases, and a way to compute alignment using the Public Suffix List for Organizational Domains. If you prefer less custom parsing and more direct fields for policy decisions, a structured model can save time and reduce errors.