What MailDignity is. (And what it isn't.)
A separate check for human boundaries, between the system that writes and the system that sends. Not another writer trying to approve its own output.
Two different jobs.
| What it is | What it isn’t |
|---|---|
A linter for specific human-boundary violations. | A grammar checker or a list of banned words. |
An independent PASS / REVIEW / FAIL gate for outbound workflows. | A numeric persuasion score or a guarantee of replies. |
A human reputation shield alongside your sending infrastructure. | An SPF, DKIM, DMARC or inbox-placement tester. |
A context-aware check, with Personal Mode for everyday email. | A blanket ban on meetings, compliments or follow-ups. |
A targeted repair that preserves supplied facts and tone. | A campaign generator that invents offers, proof or intentions. |
A zero-retention design for email content, with metadata-only history. | An archive of your drafts or a prospect database. |
An integration for outbound tools, LLMs and agents. | A replacement for Lavender, Grammarly or your deliverability stack. |
A linter for human boundaries.
A code linter does not simply say “this code feels bad”. It names a problem and points to where it occurs. MailDignity applies that idea to email semantics: a fixed demand on a stranger’s calendar, an invented prior conversation, a guilt-laden follow-up, or private-life information used as a sales hook.
The output is a verdict with named issues, severity, an explanation and verbatim evidence from your draft. It gives a sender something specific to inspect instead of a mysterious 0–100 score to optimise. The question is not whether your email sounds maximally persuasive; it is whether its persuasion depends on crossing a human boundary.
A deterministic guardrail for your agents.
A writer and a judge have different incentives. Your writing agent is trying to fulfil a campaign brief. An independent gate applies the same boundary framework after generation, without letting the writer declare its own success.
A model extracts candidate issues. Code validates quoted evidence and derives the final verdict from the severities of the issues that survive. PASS means no retained issues. REVIEW means a repair is worth considering. FAIL means the draft needs a human decision before sending. A repaired body is returned when available; a FAIL is not automatic permission to send its repair.
Connect it through the API, MCP, Gmail extension or Outlook add-in. Your workflow can keep PASS drafts, apply an available repair and re-check a REVIEW, and escalate a FAIL. The gate does not independently send your mail.
A human reputation shield.
A perfectly authenticated email can still annoy its recipient. Repeated fake familiarity, guilt and invasive personalisation can make an otherwise healthy domain unwelcome. MailDignity addresses that human layer—not DNS configuration and not a promise of inbox placement.
Use a writing coach for readability, deliverability tools for infrastructure, and MailDignity for the boundaries neither job is designed to judge. These checks are complementary. A clear, grammatically correct sentence can still demand something its reader never agreed to give.
Zero retention on email content.
MailDignity does not store the original body or repaired body at rest. Processing and brief repeat-check caching happen in memory. Dashboard history is an audit record, not a library of readable email drafts.
The saved audit projection contains only verdict, short summary, issue types with severity, and word count, alongside the account and operational information needed for usage tracking. Feedback never includes the flagged snippets. This keeps the record useful for quotas and reviewing patterns without saving the copy itself.
Content is processed by an AI service during an audit. Zero retention here describes what MailDignity persists; it does not remove the need to consider the other services in your own workflow.
A repair, not a generic rewrite.
A repair should remove the problematic move while preserving the message you intended to send. Keep the professional reference. Keep the offer, claims and tone that actually exist. Make a heavy ask lighter, remove a jab, or cut filler so the point is easier to find.
It must not turn “I’d like to talk” into “I have a proposal” when the draft never mentioned a proposal. It must not invent a case study, a shared connection or a result. A rewrite that becomes more polished by becoming less true is not a repair.
For cognitive overload, a meaningful repair is substantially shorter—not the same wall of text with different adjectives. Inspect the returned copy before applying it, especially when the relationship or purpose depends on context that was not supplied.
Personal Mode: relationship changes the reading.
Cold outreach is the default. Personal Mode, labelled Everyday email in the everyday correspondence controls, relaxes rules that only make sense between strangers. A friendly compliment to a colleague or a meeting invitation in an ongoing conversation should not be treated like an automated first-touch pitch.
It does not excuse hostility or deception. Nor does selecting a mode prove that a claimed relationship exists. Give the checker the context that matters, and treat its result as an assessment of that supplied material—not mind reading.
Where it stops.
- Not a lead scraper: it does not find prospects, enrich contact records or verify email addresses.
- Not an SPF checker: it does not test DNS, warm up domains or predict inbox placement.
- Not a campaign writer: it repairs a supplied draft rather than creating an outbound strategy.
- Not a universal fact checker: it cannot verify unknown results, offers, relationships or claims from copy alone.
- Not a legal or compliance opinion: a PASS is not permission to ignore consent, privacy law or platform rules.
- Not a guarantee of performance: respectful mail can still be irrelevant, badly timed or unanswered.
- Not a substitute for judgment: you remain responsible for the message and the decision to send it.