If your emails are going to spam, start with one affected email and its delivery history. Confirm that the receiving server accepted it, then inspect the authentication results on the copy that reached the recipient. After that, compare the sending domain, audience, volume, and content with sends that worked.
For a product team, the report often starts with a customer who cannot find a password reset or receipt. Your API returned success. Your dashboard says delivered. Neither tells you which folder the email reached. You need evidence from both the sending path and the receiving mailbox to choose the next fix.
First, identify what happened to the email
“Missing” can describe several different outcomes. Use the exact recipient, send time, and email ID to follow the attempt through your logs.
| What you can verify | What it means | What to check next |
|---|---|---|
| The send request was rejected | The sending service refused the request | The response body: authentication, sender verification, invalid input, or a sending limit |
| The recipient was suppressed | A sending policy blocked delivery to that address | The suppression reason and when it was recorded |
| The email was accepted or queued | The sending service has the request; delivery is still pending | Later events and any processing failure or delay |
| The email bounced | Delivery failed; the bounce response explains why | Whether the failure is permanent or temporary, and the receiving server's response |
| A delivery event was recorded | The receiving mail server accepted the email | The recipient's spam folder, filtering rules, or workplace quarantine |
| The recipient found it in spam | You have a confirmed placement problem for this email | Its original headers, authentication results, and sending context |
In Samva, message.delivered means the recipient's mail server accepted the email. It does not confirm inbox placement. A message.failed event can carry a processing error or suppression reason; inspect the details before calling every failure a bounce.
If the email remains queued, follow the send through processing before investigating spam filters. If it bounced, preserve the full diagnostic response. A nonexistent mailbox needs a different action from a temporary rate limit or an authentication rejection. Repeated manual resends can create duplicates while an earlier attempt is still pending.
Suppression is also a separate issue. Check the recipient in Blocks in your workspace and read the bounce and suppression explanation. Do not clear a block merely to retry a missing email. Establish why it exists and whether the address is valid and the recipient wants the email.
Inspect authentication on the received copy
Ask the affected recipient for the email's original source or full headers. An ordinary forwarded copy may change the evidence. If a workplace gateway quarantined it, the recipient's mail administrator may need to retrieve the original headers and filtering verdict.
Find the receiving system's Authentication-Results header. Record these identities alongside the pass or fail results:
- The visible
Fromdomain: the sender the recipient sees. - The SPF identity, commonly shown as
smtp.mailfrom: the envelope sender domain. - The DKIM signing domain, shown as
header.dord=in the signature, and selectors=. - The DMARC result and the visible From domain it evaluated.
SPF and DKIM can pass while DMARC fails if neither authenticated identity aligns with the visible From domain. Alignment depends on the domain relationship and the configured strict or relaxed mode. The SPF, DKIM, and DMARC guide explains those relationships.
For example, an email might show From: receipts@example.com, an SPF pass for an unrelated sending-service domain, and a DKIM pass for that same unrelated domain. Those two passes alone do not authenticate example.com for DMARC. Verify the signing and envelope identities your application actually uses.
Use the headers to choose the DNS lookup:
| Check | Input to use | What the result can establish |
|---|---|---|
| SPF checker | The envelope sender domain | Whether its published SPF record authorizes the intended sending setup |
| DKIM checker | The signing domain and selector from the email | Whether the matching public key is discoverable |
| DMARC checker | The visible From domain | The published policy and alignment settings |
A DNS lookup describes records available now. It does not prove that an earlier email passed authentication, or that its DKIM signature validates. Compare the lookup with the receiver's result on the actual email. After a configuration change, test through the same application path and inspect a new received copy.
Gmail's sender requirements distinguish requirements for all senders from additional bulk-sender requirements. Check the receiving provider's current rules as well as your sending platform's verification status. In Samva, domain verification supplies your required sending records; DMARC is a separate policy you manage.
If authentication passes, narrow the pattern
Passing authentication establishes identity. It cannot guarantee an inbox placement. Make a small comparison sheet before changing your whole setup:
| Compare | Evidence to collect |
|---|---|
| One receiving provider versus several | Recipient domain, delivery response, and confirmed folder placement |
| One workplace versus unrelated mailboxes | Quarantine verdict or mail-admin trace for the affected workplace |
| Password resets versus announcements | Email purpose, template version, From domain, and recipient selection |
| Before versus after the problem began | Changes to DNS, sending service, links, audience, or send volume |
Start with several recent affected examples and, where available, a successful example from the same sending stream. An email to your own test inbox is useful for inspecting headers and layout. It does not establish where every customer's copy lands.
For Gmail traffic, Postmaster Tools can add reputation, authentication, spam-rate, and delivery-error evidence. Its data covers personal Gmail accounts, is delayed, and may be absent at low volume. A low user-reported spam rate does not prove good placement: automatic filtering can leave fewer emails in the inbox for people to report.
Keep those figures separate from your sending platform's complaint rate. They can use different populations and denominators. Likewise, an open event does not prove that a person read the email or that it reached the inbox. See the limits of engagement tracking before using opens as your success measure.
Check who received it and what changed
For each affected email type, identify why the recipient expected it. A password reset should correspond to a request. A product announcement needs an appropriate subscribed audience. An old account record alone does not explain why someone should receive today's announcement.
Review recent imports, subscription sources, complaints, and invalid addresses. Honor opt-outs across the paths that select recipients. Keep essential account email focused on the action the customer triggered; use the transactional versus marketing email guide when the purpose is unclear.
For promotional and subscribed email, check that opting out works. Where bulk-sender rules apply, a footer link alone is not the complete one-click mechanism. The List-Unsubscribe guide explains the headers and request handling.
If the problem followed a new domain, a migration, or a sharp volume increase, hold further expansion while you investigate. Compare the affected batches with the earlier traffic. Follow a domain warm-up plan that uses delivery results to decide when to increase volume. Sending extra email solely to build history gives recipients no additional reason to want it.
Review the actual email, including its links
Open the final rendered email with its real variable values. Check that the sender is recognizable, the subject describes the contents, and the requested action is clear. Inspect the destination of each link, including redirects and tracking domains.
An example: a password-reset email that also contains a discount offer gives the recipient two unrelated reasons for the send. Keep the reset action clear and move the promotion into its appropriate subscribed stream. This also makes it easier to compare results for account email separately.
Gmail's formatting guidance calls for accurate sender information, understandable links, and non-deceptive subjects. Follow those requirements without treating a wording change as proof that a filtering problem is fixed. If you change a template, record the version and compare new results while keeping the other variables stable.
Retest the fix and keep an evidence packet
After correcting a specific problem, send a small, purposeful test through the real application path to mailboxes you control or recipients who agreed to help. Inspect fresh headers and confirm the folder at the receiving end. Then observe the affected production stream before expanding a broader send.
Keep a compact record for each investigation:
- Send time with timezone, email ID, recipient domain, and template version.
- Send response, delivery timeline, and complete failure codes where present.
- Original received headers and confirmed folder or quarantine verdict.
- Authentication results, DNS checks, and the exact change made.
- New test results and any differences between receiving providers.
Share full addresses and original email source only through an appropriate private support channel. If you still cannot explain the behavior, this packet gives your sending provider or the recipient's mail administrator a concrete case to trace.
For a Samva integration, start with delivery events, domain verification, and the recipient's block reason. The deliverability controls help you inspect and respond to sending problems. The receiving mailbox remains the source of evidence for where an accepted email landed.
