SAAS EMAIL DELIVERABILITY — SYNTHETIC DIAGNOSTIC PACK
Original examples. Checked 2026-10-27.
https://showmeyoursaas.com/articles/email-deliverability/
Reserved example domains/IPs below are not real infrastructure.
No message was sent; no DNS lookup or signature verification is represented.

CASE D1 — ACCEPTED BY SERVER, PLACEMENT UNKNOWN
Application intent: recorded for synthetic invitation INV-101.
Provider request: accepted, synthetic message MSG-101.
Recipient server: accepted.
Recipient report: no message in inbox.
Established: server-level acceptance.
Unknown: placement, recipient filtering, whether intended address was used.
Next check: inspect permitted event history and recipient context.
Do not conclude the recipient read or ignored the message.

CASE D2 — PASSING AUTHENTICATION, UNALIGNED DOMAINS
Illustrative header-like text, NOT a verifiable message:
From: InviteDesk <invite@mail.example.test>
Return-Path: <bounce@other.test>
Authentication-Results: mx.receiver.test;
  spf=pass smtp.mailfrom=other.test;
  dkim=pass header.d=other.test;
  dmarc=fail header.from=mail.example.test
Synthetic sending IP: 192.0.2.10
Lesson: pass for other.test does not establish alignment with example.test.
Next check in real mail: trusted receiver result, actual envelope sender, signing domain, and provider-issued configuration.
These strings cannot establish SPF or verify a DKIM signature.

CASE D3 — ALIGNED DKIM CAN SUPPORT DMARC
Illustrative header-like text, NOT a verifiable message:
From: InviteDesk <invite@mail.example.test>
Authentication-Results: mx.receiver.test;
  spf=fail smtp.mailfrom=other.test;
  dkim=pass header.d=mail.example.test;
  dmarc=pass header.from=mail.example.test
Lesson: aligned passing DKIM can support DMARC despite failed SPF.
This says nothing about inbox placement or broader provider requirements.

CASE D4 — PERMANENT REJECTION
Synthetic event: recipient mailbox permanently rejected the message.
Established: permanent rejection, not merely missing open tracking.
Next check: legitimate address/account correction and provider suppression policy.
Do not bypass suppression or launch blind retries to increase a sent count.

DIAGNOSTIC SEQUENCE
1. Confirm the intended recipient and permitted account context.
2. Find application intent and the provider message reference.
3. Separate API acceptance, temporary delay, permanent rejection, and server acceptance.
4. For a real received message, inspect authentication results from trusted receiving infrastructure.
5. Compare visible From, envelope sender, and signing domain.
6. Check current requirements at relevant receiving providers.
7. Review recipient expectation, complaint/suppression evidence, and relevant sending pattern.
8. Make an authorized change only after locating its failure stage.
9. Verify the resulting evidence; retain unknown placement as unknown.

BLANK INCIDENT RECORD
Reference / owner / date:
Message purpose:
Permitted IDs:
Application intent:
Provider acceptance:
Receiving-server response:
Authentication / alignment evidence and trust source:
Placement evidence:
Suppression or complaint status:
Next check:
Authorized change:
Observed result:
Remaining unknown:
Review trigger:

CONFIGURATION NOTES
Use exact provider-issued DNS values; no reusable SPF include or DKIM key is supplied.
Inventory legitimate sending sources before changing DMARC enforcement.
A published DNS record is not proof that a particular message passed authentication.
Do not infer human reading from an open event alone.

PRIMARY REFERENCES
https://support.google.com/mail/answer/81126?hl=en
https://resend.com/docs/dashboard/domains/introduction
https://resend.com/docs/webhooks/event-types
https://www.rfc-editor.org/rfc/rfc7489.html
https://www.rfc-editor.org/rfc/rfc8601.html