Buy MailAuth Preflight.
Catch missing SPF, DKIM, DMARC, and alignment errors before sending critical email campaigns.
Drop-In Integration Stage
OpenAPI 3.1 & Gateway Compatibleimport httpx
response = httpx.post(
"https://api.youstostore.com/v1/inspect",
headers={"X-API-Key": "sk_live_your_key"},
json={
"raw_mime": "From: noreply@acme.com\nTo: user@example.com\nSubject: Welcome...",
"sender_domain": "acme.com",
"providers": ["gmail", "yahoo"]
}
)
result = response.json()
print(result["spf"]) # {"result": "pass", "record": "v=spf1 ..."}
print(result["dkim"]) # {"result": "pass", "selector": "google"}
print(result["dmarc"]) # {"result": "pass", "policy": "reject"}Developer Tier
Growth Tier
RECOMMENDEDEnterprise Tier
MailAuth Preflight
**Eyebrow:** Pre-send email authentication linting
Engineering Pain & Fragility
A campaign can look correct in an editor and still leave your system with incomplete unsubscribe headers or missing sender-authentication records. Those failures often surface late: during a launch review, after a provider rejects mail, or when an engineer has to compare generated MIME against several policy documents by hand.
MailAuth Preflight provides that narrow control point. It is a pre-send linter—not a campaign platform, a deliverability score or a promise of inbox placement.
What the API Solves
Send raw MIME, the sender domain and, optionally, a provider selection of `gmail`, `yahoo` or both to `POST /v1/inspect`. The service:
- parses the supplied message as MIME and verifies that it contains a `From` header, a header/body boundary and a body; - checks for the RFC 8058 `List-Unsubscribe-Post: List-Unsubscribe=One-Click` header; - checks that `List-Unsubscribe` contains an HTTPS URL; - performs timeout-bounded DNS TXT lookups for SPF and DMARC signals on the sender domain; - reports SPF, DKIM and DMARC publication checks using a versioned policy response; - returns a top-level `pass`, `warn` or `fail` verdict, evidence for every check, and plain-language repairs.
The response is structured JSON, so the same result can block a deployment, annotate a pull request, populate an internal approval screen or create a support ticket.
How it works. Step by step.
Generate the final message.
Produce the raw MIME after your application or email service has applied template data and headers.
Submit it before release.
Call `POST /v1/inspect` with your API key, `raw_mime` and `sender_domain`. MIME is limited to 512 KiB.
Run message and domain checks.
MailAuth parses the MIME and checks the unsubscribe and sender-authentication signals currently implemented.
Read the verdict and evidence.
Each check has a stable code, a `pass`, `warn` or `fail` status, and a short evidence string.
Apply the repairs.
The response names concrete changes, such as adding the one-click unsubscribe header or publishing/correcting a DNS record.
Re-run the gate.
Inspect the corrected MIME and domain configuration before your application hands the campaign to its sending provider.
Built for enterprise production standards.
**Inspection of the real outbound artifact
**Inspection of the real outbound artifact:** Test raw MIME rather than relying only on fields copied from a template editor.
**RFC 8058 header checks
**RFC 8058 header checks:** Detect a missing one-click POST header and a missing HTTPS unsubscribe target.
**Live DNS signals
**Live DNS signals:** Inspect sender-domain TXT records at request time for the SPF and DMARC checks implemented by the resolver adapter.
**Actionable repairs
**Actionable repairs:** Return specific header or DNS work instead of a generic “deliverability issue.”
**Versioned results
**Versioned results:** Include `policy_version` so a stored decision can be tied to the rule response used at inspection time.
**Machine-readable verdicts
**Machine-readable verdicts:** Use stable JSON fields and check codes in CI, release workflows and internal tooling.
**Strict input boundaries
**Strict input boundaries:** Reject malformed requests and cap raw MIME at 512 KiB.
**No MIME-body retention in the service flow
**No MIME-body retention in the service flow:** The implementation parses the body in memory and does not write it to the application store.
Ideal use cases & engineering workflows.
MailAuth Preflight fits teams that already have a sending system but need a dependable release check:
- SaaS companies sending product updates, account notices or lifecycle campaigns; - email platforms and agencies approving messages for multiple sender domains; - marketing-operations teams that need engineering-grade checks without manually reading MIME; - developers maintaining notification pipelines or custom email infrastructure; - compliance and deliverability specialists who want repeatable evidence attached to releases.
- Gate a generated campaign sample in CI before a template is promoted. - Inspect the final production MIME immediately before a bulk release. - Validate one-click unsubscribe headers after switching email vendors or template engines. - Check sender-domain SPF and DMARC publication during domain onboarding. - Turn a failed check into an internal ticket with the exact repair text. - Store the policy version and verdict digest alongside a campaign approval record.
Why buy instead of building internally?
A useful preflight gate needs safe MIME parsing, bounded inputs, DNS timeouts, stable errors, versioned results, authentication and operational controls. The maintenance burden starts after the first script works: parsers meet unusual messages and every integration invents its own output format.
MailAuth Preflight packages the narrow workflow behind one contract. Your team owns the decision—warn, block or request review—without owning another public API surface and its security and operational plumbing. It also keeps the linter independent from your email service provider, which makes the gate easier to retain when the sending stack changes.
Security, privacy and operational integrity.
API keys are sent in the `X-API-Key` header. The scaffold indexes keys by SHA-256 digest rather than storing plaintext keys in its key store, supports revocation, and resolves tenant identity from the authenticated principal rather than accepting it in the request body.
Mail MIME can contain personal data, credentials and internal links. The MailAuth inspection path does not persist the supplied MIME or write request bodies to its application logs. Request logs use request IDs and route/status metadata. The product contract calls for redacted diagnostics and 30-day retention of policy version, verdict digest and usage—not MIME bodies—when that production persistence is enabled.
Live DNS access is timeout-bounded. The service exposes health checks, metrics, structured errors and rate-limit retry metadata. Tests cover authenticated inspection, malformed MIME, metering, key handling and contract exposure. These controls are not a certification or production SLA.
Architectural Scope & Production Boundaries
Questions & answers for engineering leads.
No. Your system sends the message. MailAuth receives a raw MIME sample for inspection and returns a result before release. You can call it from any workflow that can make an HTTPS request.
Deploy MailAuth Preflight in minutes.
Start with our developer tier on Polar.sh Merchant of Record. Automated EU VAT invoices, instant API key generation, and 99.99% edge uptime SLA.