The latest articles on DEV Community by Mosfetti (@mosfetti). https://dev.to/mosfetti https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4202276%2F1668cf99-f5c9-41db-8a12-04a82d42cad9.png https://dev.to/mosfetti en Mosfetti Mon, 09 Nov 2026 20:33:48 +0000 https://dev.to/mosfetti/smtp-accepted-the-message-that-didnt-mean-it-reached-the-inbox-13gh https://dev.to/mosfetti/smtp-accepted-the-message-that-didnt-mean-it-reached-the-inbox-13gh <p>On one of my own systems, an automatic notification reported success. The next mail server accepted the message over an encrypted connection (SMTP over STARTTLS).</p> <p>I checked the recipient side anyway. The message was in Spam.</p> <p>That is a small example of a bigger debugging mistake: treating success at one layer as proof of the user's outcome.</p> <h2> Name the assertion you are actually testing </h2> <p>A website contact or notification flow has several different assertions:</p> <ol> <li>The visitor can find the contact action.</li> <li>The browser sends the request.</li> <li>The application accepts it.</li> <li>The sending server hands off the message.</li> <li>The receiving system accepts or classifies it.</li> <li>The intended person can find it where they expect it.</li> </ol> <p>A green result for step 4 does not establish steps 5 or 6. SMTP acceptance is evidence about the handoff, not an inbox-placement guarantee.</p> <h2> Don't leap from symptom to cause </h2> <p>In my case, the receiving-side check established Spam placement for that message. It did <strong>not</strong> establish the spam cause, and I am not presenting it as a completed deliverability fix.</p> <p>Investigating the cause would mean looking at the actual message, authentication results (SPF/DKIM/DMARC), domain records, reputation, and sending/receiving behavior. Blindly changing DNS because "email is broken" can add a second problem.</p> <p>A useful diagnostic note separates three things: what was observed, what remains unknown, and what the next check would establish. Any correction then needs its own result check.</p> <h2> Honest limits </h2> <ul> <li>This write-up is from my own systems, not a customer case study.</li> <li>Placement ≠ root cause. I found where the message landed; that alone did not fix authentication or reputation.</li> <li>I will not claim a universal spam fix from one observation.</li> </ul> <h2> Why I'm writing this under Mosfetti </h2> <p>I'm Carl. Mosfetti is a service-first tech shop: WordPress and website help, business email/domain troubleshooting, hosting and backups, remote diagnosis, and local computer repair in Michigan's Upper Peninsula. The public site leads with the problem, not a product shelf.</p> <p>If your site reports success but the useful result is missing, start here: <a href="https://mosfetti.com" rel="noopener noreferrer">https://mosfetti.com</a></p> webdev email debugging devops