Parsimony — Ecosystem

The infrastructure behind
every message Parsimony sends.

Parsimony's chat agents, marketing automation, and cloud ERP all depend on one unglamorous thing working every time: the email actually arrives. parsimony.work is where Parsimony documents that delivery layer — authenticated, observable, and resilient — as its own system.

01 / What it is

What parsimony.work publishes

Parsimony.work describes itself as the email infrastructure behind Parsimony, built for what happens after the send button: identity, routing, reputation, retries, encryption, and the feedback loop back to the sender. The site frames email not as a single message but as a delivery system with hops and handoffs, each one authenticated and logged.

It describes an outbound path — application event, policy and authentication, queue and relay, then the recipient — built on the open standards SPF, DKIM, DMARC, MTA-STS, and TLS-RPT, running on Cloudflare's edge. It also separates transactional mail (an order confirmation, a password reset) from marketing mail, so a queued campaign never competes with a message a customer is waiting on.

Operator's noteParsimony.work states that credentials for sending mail live in the server environment, not in a browser bundle — the site calls this "least privilege by default." That is a design principle it publishes, not a certification Parsimony claims to hold.

02 / Why it matters

Why an ERP and automation vendor runs its own mail

An ERP holds the invoice. A chat agent answers the ticket. An automation sequence recovers the abandoned cart. Every one of those systems ends the same way: an email leaves. If that email lands in spam, or never arrives, the work upstream — the accounting, the customer service, the campaign — did not finish.

Treating delivery as a solved, invisible layer is how deliverability problems go unnoticed until a customer says they never got the invoice. Documenting the sending stack in the open, at a separate domain built for exactly that, is Parsimony's answer: the same authentication and observability discipline the platform expects of the businesses it serves, applied to itself.

03 / Glossary

SPF, DKIM, and DMARC, plainly

These are open, widely adopted email standards — not a Parsimony product and not unique to any vendor. Any domain that sends email can publish them.

01

SPF — Sender Policy Framework

A DNS record that lists which mail servers are allowed to send email for a domain. A receiving server checks the sending IP against that list before trusting the message.

02

DKIM — DomainKeys Identified Mail

A cryptographic signature added to each outgoing message. The receiving server checks the signature against a public key in DNS to confirm the message was not altered after it was sent.

03

DMARC — Domain-based Message Authentication, Reporting and Conformance

A policy layered on top of SPF and DKIM. It tells receiving servers what to do when a message fails those checks — quarantine, reject, or do nothing — and asks them to report the results back to the domain owner.

04

MTA-STS

A policy that requires encrypted TLS transport when mail is delivered to a domain, so a message cannot be silently downgraded to an unencrypted connection in transit.

05

TLS-RPT

The reporting standard paired with MTA-STS: receiving servers send back a report when a TLS connection to the domain fails, surfacing transport problems instead of hiding them.

04 / Observability

What deliverability monitoring means

Accepted by a mail server is not the same as delivered to an inbox. Delivered is not the same as read. Deliverability monitoring is the practice of tracking a message past the moment it leaves — whether SPF and DKIM checks passed, whether the connection to the receiving server was encrypted, whether a bounce or a DMARC report came back — so a failure surfaces as a signal to investigate rather than a customer complaint.

Parsimony.work frames this as tracing the event, understanding the failure, and improving the next send: a feedback loop, not a one-time setup. That loop is general practice across the industry; what parsimony.work adds is publishing it as part of how Parsimony builds.

FAQ

Common questions

01

What is parsimony.work?

Parsimony.work is the companion site that documents the email infrastructure behind Parsimony's own product: authenticated sending, standards-based identity, and observability on every message.

02

What do SPF, DKIM, and DMARC do?

SPF (Sender Policy Framework) lists which mail servers are allowed to send for a domain. DKIM (DomainKeys Identified Mail) signs each message so the receiving server can verify it was not altered in transit. DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receiving systems what to do when SPF or DKIM checks fail, and reports the results back to the sender.

03

What are MTA-STS and TLS-RPT?

MTA-STS is a policy that requires mail servers to use encrypted TLS transport when delivering to a domain, closing the door on downgrade attacks. TLS-RPT is the companion reporting standard: it tells the sending domain when a TLS connection failed, so problems surface instead of hiding in a delivery log.

04

What does deliverability monitoring mean?

Deliverability monitoring is the practice of tracking a message past the moment it is accepted by a mail server — whether it was signed correctly, whether it reached the inbox, and whether the receiving side reported a problem — so a sender can catch and fix authentication or reputation issues before they affect more mail.

05

Why does an ERP and automation vendor run its own email infrastructure?

Parsimony's chat agents, marketing automation, and ERP all depend on transactional and marketing email actually arriving — an order confirmation, a support reply, an automated follow-up. Rather than treat delivery as someone else's problem, Parsimony documents its own sending stack in the open at parsimony.work.

Elsewhere in the ecosystem

Where this fits in Parsimony

Email infrastructure is the delivery layer under three Parsimony products: the automation that sends the campaign, the ERP that sends the invoice, and the chat agents that answer before an email is even needed.

Visit parsimony.work

Pricing

Automate is public.
ERP and agents are quoted.

Parsimony Automate has public monthly plans — see Automate pricing. Chat agents, voice agents, and Cloud ERP are quoted to the job. Call or send the form and we put a package together.

  1. 01

    Cloud ERP

    Managed ERPNext on Frappe Cloud. Quoted to the job.

    Quoted
  2. 02

    Automate

    CRM, funnels, two-way text, workflows, and websites on one login.

    $59 / $199 / $497 a month · self-serve
  3. 03

    AI chat and voice agents

    Chat on your site and help desk, voice on your phone line. Quoted to the job.

    Quoted