What is email deliverability?
Email deliverability is the ability to get legitimate messages to their intended recipients, including the practical question of inbox placement. A successful send API response, acceptance by a recipient mail server, and appearance in an inbox are different observations.
For a SaaS invitation, start with the user's report and the message's actual status. Did the application intend to send it? Did the provider accept the request? Did the receiving server accept the message, defer it, or reject it? Only then investigate placement or whether the recipient recognized the message.
The examples here are original synthetic diagnostics using reserved domains and addresses. They are not real mail traffic, a live domain audit, or evidence that ShowMeYourSaaS has a deliverability problem. The downloadable resources help structure an investigation without sending test messages.
Download the diagnostic checklist and worksheet
The text pack contains four synthetic cases, an authentication interpretation exercise, a step-by-step diagnostic checklist, and a blank incident form. The CSV records symptoms, available evidence, unknowns, next checks, and initially open status.
Use your provider's message ID and event timeline to correlate a legitimate incident. Avoid copying message bodies, invitation tokens, or unnecessary personal data into broadly shared records. Keep access to original logs appropriate to their sensitivity.
The files make no DNS changes and contain no reusable authentication keys. Authentication-Results lines in the exercise are illustrative strings, not signed evidence. Inspect the receiving system's trusted results for a real message before reaching a conclusion.
Locate the failure stage before changing DNS
Application intent is the first stage. An eligible invitation may have failed before reaching the email provider because a job was never created or an application condition prevented the send. A DNS change cannot repair that missing application event.
Provider acceptance is another stage. Resend's event documentation distinguishes email.sent, meaning an API request succeeded and delivery will be attempted, from email.delivered, meaning delivery to the recipient's mail server succeeded. That server-level acceptance does not establish inbox placement.
A temporary delivery problem and a permanent rejection need different handling. Inspect the actual event and SMTP response, then follow your provider's documented retry and suppression behavior. Repeatedly resending to a permanently rejected address can make an incident worse.
An open-tracking event is not a reliable proof that a human read or understood a message. Privacy features and automated retrieval complicate tracking. For an invitation flow, the permitted in-product acceptance event can answer a different and often more useful question.
Understand SPF, DKIM, and DMARC alignment
SPF checks whether the sending system is authorized for the envelope-sender domain. DKIM verifies a signature associated with a signing domain. DMARC evaluates authentication alignment with the visible From domain. A passing authentication result for an unrelated domain is not automatically aligned.
DMARC can pass through an aligned passing SPF result or an aligned passing DKIM result. It does not require both mechanisms to pass for every individual message. A mailbox provider can still require a sender to configure both under its broader sending requirements.
Consider a synthetic message with From mail.example.test. If SPF and DKIM pass only for other.test, those successes do not establish DMARC alignment with example.test. If an aligned DKIM signature passes while SPF fails, DMARC can still pass through DKIM.
Use the exact DNS values issued for your sending configuration, then verify the resulting messages. Resend's domain documentation explains its SPF and DKIM setup. Do not copy a sample provider include or selector blindly, publish multiple competing SPF policies, or jump to an enforcement policy before understanding all legitimate sending sources.
Check the receiving provider's current requirements
Google's guidance for mail to personal Gmail accounts requires SPF or DKIM for all senders. Its bulk-sender requirements, applying at roughly 5,000 or more messages per day to personal Gmail accounts, include SPF, DKIM, and DMARC; a DMARC policy of none can satisfy that policy-setting requirement. Alignment and other requirements also apply.
For bulk marketing and subscribed messages, Google requires one-click unsubscribe and a clearly visible unsubscribe link in the message body. Review the official guidance for the exact scope, sending infrastructure, formatting, and spam-rate requirements rather than treating authentication as the whole checklist.
These are Gmail's published requirements, not a universal specification for every receiving service. Other providers can apply different policies, and requirements can change. Check the destinations relevant to your audience. Meeting a provider's stated requirements still does not guarantee inbox placement.
Interpret evidence with the right trust boundary
View authentication results added by the receiving infrastructure you trust. RFC 8601 explains that Authentication-Results headers need an appropriate trust boundary. A sender can place header-like text in a message; reading that text alone does not establish that a trusted receiver performed the checks.
The diagnostic pack includes an intentionally non-verifiable header exercise. It shows domain relationships so you can practice interpreting alignment. It cannot prove a DKIM signature, SPF evaluation, or a real message's route because there is no signed message or live SMTP transaction behind it.
DNS records show published configuration at the time you inspect them. A real message can still use a different envelope sender, a different DKIM selector, or a path that modifies its content. Compare configuration with the actual received message rather than assuming a verified-domain dashboard settles every incident.
Work through four synthetic incidents
Case D1 has an accepted API request and recipient-server acceptance, while the user reports no inbox message. Investigate placement, the recipient's search and filtering context, and whether the expected address was used. Do not describe server acceptance as proof that the user ignored the email.
Case D2 has passing SPF and DKIM under an unrelated domain but failed DMARC alignment. Inspect the actual From, envelope sender, and signing domain. Case D3 has failed SPF but aligned passing DKIM; DMARC can pass, so investigate other evidence before blaming SPF alone.
Case D4 records a permanent mailbox rejection. Respect the provider's suppression behavior and investigate the legitimate address or account correction through the product's authorized process. Do not bypass suppression simply to make an internal sent count increase.
Keep transactional invitations relevant to the action requested. For onboarding emails, use clear context and an expected next step. Separate promotional subscription management from essential account workflows according to your actual provider and product policies.
Close the investigation with a verified outcome
Record the failure stage, evidence, change, and result. A completed DNS setup task is different from a verified message result. If placement remains unknown, leave it unknown rather than marking the incident resolved from an API success.
Review recipient expectations, complaints, invalid addresses, and sending patterns alongside technical authentication. There is no universal warmup schedule or single bounce threshold in this guide; use current provider guidance and evidence from your own permitted sending.
Resources and primary sources were checked October 27, 2026. The synthetic cases test interpretation, not live infrastructure. Recheck provider requirements before changing a production sending configuration.