Separate four contracts
- Effective From
- The address Ghost puts in
data.fromfor this newsletter. - Postmark coverage
- A confirmed exact Sender Signature or a verified domain covering that effective address.
- Message stream
- Newsletter traffic should use the intended broadcast stream independently of sender verification.
- Provider result
- Codes 400, 401, 406, and accepted requests describe different boundaries.
Browser-local release planner
Find the first failing sender boundary
No real sender address, recipient address, Server API token, message body, subscriber list, Ghost configuration, Postmark payload, DNS value, or raw log is requested or transmitted.
- First boundary
- Decision
- Next action
- Exit condition
- Safety rule
What the two send paths actually do
At adapter commit f827884, #buildMessage serializes From: data.from || fromEmail. Constructor validation proves a fallback exists; it does not prove the fallback is selected on a real newsletter send.
At reviewed Ghost commit 4324cc8, SendingService.send passes from: emailRenderer.getFromAddress(post, newsletter, useFallbackAddress) to the provider. The normal newsletter setting therefore owns the effective From unless Ghost deliberately selects its fallback path.
Build coverage from active newsletters
- Privately inventory the effective From chosen by every active newsletter, including newsletters that override the publication default.
- For one address, confirm that exact Sender Signature. For several addresses under one owner-controlled domain, prefer Domain Verification.
- If newsletters use more than one domain, cover every domain or every outlier address. One verified domain cannot authorize another.
- Test the configured
fromEmailseparately as a fallback. Do not use that fallback test as the production newsletter release gate.
This page uses only categorical counts and states. Do not paste newsletter addresses, Postmark tokens, DNS values, subscriber data, request payloads, or raw logs.
Use the exact Postmark error class
- 400
- Sender Signature not found. The effective request From is not covered by a signature or verified domain.
- 401
- Sender signature not confirmed. Coverage exists but is not yet confirmed.
- 406
- Inactive recipient. This is a recipient suppression boundary, not a sender-signature failure.
Postmark's official API error table separates these codes. Changing the sender to repair 406 can hide the real recipient state and create a second identity problem.
Keep sender identity and stream policy separate
The reviewed adapter defaults MessageStream to broadcast, which matches newsletter traffic. A covered sender can still fail a separate stream policy, and a correct broadcast stream cannot authorize an uncovered From. Record both values on one controlled request.
Minimal release gate
- Every active Ghost newsletter maps to one privately recorded effective From.
- Each effective address is covered by a confirmed Sender Signature or verified domain.
- The outbound request shows the intended From and
MessageStream=broadcast. - One consenting controlled recipient receives a test or has a precise provider outcome.
- A fresh receiver header proves the intended visible From and same-message DKIM or SPF alignment under DMARC.
- The fallback path is tested independently and is not mistaken for the normal newsletter path.
Use the local sender inventory to count streams and domains without uploading addresses or message content.
Primary references
- ghost-postmark-email-adapter issue 21: README verifies the wrong sender boundary
- Reviewed adapter From and MessageStream serialization at commit f827884
- Reviewed Ghost newsletter sender handoff at commit 4324cc8
- Postmark developer guide: the visible From must be a confirmed signature or belong to a verified domain
- Postmark developer API error codes