Website-এর contact form পূরণ করে Submit চাপলেন, screen-এ “Message sent” দেখা গেল, কিন্তু business inbox-এ কোনও email এল না। এই অবস্থায় শুধু SMTP password বদলানো বা form plugin reinstall করলে আসল failure লুকিয়ে যেতে পারে। Form submission, database, queue, mail provider, DNS authentication এবং recipient inbox। এগুলো প্রতিটি আলাদা ধাপ। কোথায় message থেমেছে তা evidence দিয়ে ধরলে অপ্রয়োজনীয় change কমে এবং genuine customer enquiry হারানোর সময়ও কমে।

প্রথমে একটি controlled test case তৈরি করুন

Real customer-এর পুরোনো message দিয়ে শুরু করবেন না। নিজের approved test address ব্যবহার করে form-এর exact URL, submit time, recipient address এবং browser লিখে রাখুন। Subject বা message-এ একটি unique reference দিন, যেমন FORM-20260905-1015। একই সঙ্গে দশবার Submit করলে duplicate request ও rate limit diagnosis কঠিন হয়, তাই প্রথমে একবার পাঠান। Screenshot-এ password, token বা personal data রাখবেন না।

Browser response আসলেই কী প্রমাণ করে বুঝুন

Green success banner সাধারণত browser request-এর একটি application response; এটি recipient inbox delivery receipt নয়। DevTools Network panel বা server access log-এ POST request-এর status দেখুন। JavaScript error, blocked request, wrong endpoint, 419/CSRF failure, 422 validation error, 429 rate limit বা 500 server error হলে email layer পর্যন্ত কাজ পৌঁছায়নি। Success message server confirmation-এর আগে দেখানো হচ্ছে কি না code flow review করুন।

Submission database বা application log-এ পৌঁছেছে কি না দেখুন

Form entry database-এ সংরক্ষণ হলে content receipt এবং mail delivery আলাদা করে দেখা যায়। Unique reference, created time, form ID ও intended recipient মিলান। Entry না থাকলে validation, CSRF, routing, database error বা transaction rollback দেখুন। Entry থাকলেও mail job তৈরি না হলে application configuration বা conditional recipient rule পরীক্ষা করুন। Log-এ full message body, email address, IP, token বা credential না রেখে privacy-safe event ID, status এবং error category রাখুন। Contact form যদি database-এ কিছু না রাখে, temporary approved diagnostic logging ব্যবহার করুন; debugging শেষে verbose logging বন্ধ করুন।

Queue ও scheduler-এর মাঝখানে message আটকে আছে কি না ধরুন

অনেক application request-এর সময় সরাসরি email পাঠায় না; queue-তে job রেখে worker পরে পাঠায়। তাই form fast success দেখালেও stopped worker, failed job, wrong queue name বা scheduler বন্ধ থাকলে message বেরোয় না। Pending, processing, failed এবং retry count দেখুন। Manual retry-এর আগে provider log-এ delivery attempt হয়েছে কি না মিলান, নইলে duplicate email যেতে পারে। Worker কেন থেমেছিল তার error record করুন। Queue নেই এমন site-এ এই ধাপ applicable নয়; সেটি report-এ লিখুন।

Send function-এর success-কে inbox delivery ভাববেন না

Application library বা PHP mail() true ফেরালেই destination inbox-এ message পৌঁছেছে বলা যায় না। PHP-এর official manual স্পষ্ট করে যে true মানে message delivery-এর জন্য accepted হয়েছে; intended destination-এ পৌঁছানো নিশ্চিত নয়। SMTP library ব্যবহার করলে connection, authentication, accepted recipient এবং provider message ID আলাদা log করুন। Exception swallow করে generic success পাঠানো হলে সেটি ঠিক করুন। Production credential source code-এ লিখবেন না; environment বা approved secret store ব্যবহার করুন এবং report-এ secret value কখনও রাখবেন না।

From, Reply-To ও recipient rule পরীক্ষা করুন

Visitor-এর address সরাসরি From হিসেবে ব্যবহার করলে আপনার domain-এর authentication-এর সঙ্গে alignment ভাঙতে পারে। সাধারণত verified domain address From-এ এবং validated visitor address Reply-To-তে রাখা বেশি predictable। User input দিয়ে raw header বানাবেন না; newline/header injection ঠেকাতে mail library ও server-side validation ব্যবহার করুন। Recipient spelling, alias, group membership, catch-all, environment-specific override এবং staging address দেখুন। Production form ভুল করে developer inbox-এ যাচ্ছে বা test environment real sales inbox-এ পাঠাচ্ছে কি না configuration compare করুন। CC/BCC business need ছাড়া যোগ করবেন না, কারণ personal enquiry অপ্রয়োজনীয় মানুষের কাছে ছড়িয়ে যেতে পারে।

Mail provider-এর event log থেকে পথ অনুসরণ করুন

Provider dashboard বা SMTP log-এ unique reference, recipient, time এবং message ID খুঁজুন। Status সাধারণত accepted, queued, delivered, deferred, bounced, blocked বা complained-এর মতো হতে পারে; provider অনুযায়ী নাম বদলায়। “Delivered” অনেক সময় receiving mail server গ্রহণ করেছে বোঝায়, user inbox placement নয়। Bounce code এবং response text হুবহু secure incident note-এ রাখুন, তারপর provider-এর official documentation দিয়ে category বুঝুন। Unknown recipient, mailbox full, policy rejection, rate limit এবং authentication failure একই fix নয়। Provider status page-এ incident থাকলে time range মিলিয়ে দেখুন; একবারের failure থেকে outage ঘোষণা করবেন না।

SPF, DKIM ও DMARC alignment যাচাই করুন

Google-এর current sender guidelines অনুযায়ী Gmail-এ পাঠানো সব sender-এর জন্য SPF বা DKIM authentication দরকার; বেশি volume-এর sender-এর জন্য SPF, DKIM ও DMARC-সহ অতিরিক্ত requirement আছে। Google-এর SPF guidance-এ website contact form-এর মতো automatic sender-কেও authorized sender inventory-তে রাখার কথা বলা হয়েছে। DNS-এ random record paste করবেন না। কোন provider envelope sender ও DKIM domain ব্যবহার করছে জেনে তাদের official record বসান। একই domain-এ একাধিক SPF TXT record তৈরি না করে existing record safely merge করুন। DMARC enforcement হঠাৎ কঠোর করার আগে report monitor এবং সব legitimate sender align করুন।

Received header দিয়ে authentication result পড়ুন

একটি test message অন্য mailbox-এ পৌঁছালে “Show original” বা full headers খুলে SPF, DKIM, DMARC result, From domain এবং Return-Path দেখুন। Header public ticket-এ paste করবেন না; এতে private identifier থাকতে পারে। SPF pass হলেও DKIM fail কেন, অথবা DKIM pass হলেও From alignment মেলেনি কেন, provider documentation দিয়ে বুঝুন। Microsoft-এর official email authentication overview SPF, DKIM ও DMARC-কে spoofing ঠেকানোর পরস্পর-সম্পর্কিত building block হিসেবে ব্যাখ্যা করে। Authentication pass delivery guarantee নয়।

Inbox rule, spam ও quarantine আলাদা করে দেখুন

Provider accepted বললেও recipient-side filter message সরাতে পারে। Spam/Junk, quarantine, focused/other inbox, category tab, blocked sender, forwarding এবং automatic delete rule দেখুন। একই domain-এর দুটি mailbox এবং একটি external test mailbox-এ controlled test করলে domain-wide ও mailbox-specific আচরণ আলাদা করা যায়। “Not spam” click সাময়িকভাবে message দেখাতে পারে, কিন্তু sender authentication বা content সমস্যা ঠিক করে না। Subject-এ misleading urgency, all caps, URL shortener বা attachment থাকলে একটি plain-text minimal test পাঠিয়ে compare করুন। Real customer content বাদ দিয়ে test করুন; mail filter bypass করার জন্য deceptive wording ব্যবহার করবেন না।

Delivery failure হলে customer enquiry যেন না হারায়

Email notification একমাত্র record হলে silent failure-এ lead হারিয়ে যায়। Validated submission database বা access-controlled admin inbox-এ রাখুন এবং staff-এর জন্য unread count বা daily reconciliation দিন। Customer-কে reference ID ও realistic response window দেখান, কিন্তু email সত্যিই queued না হলে “আমরা email পেয়েছি” বলবেন না। Temporary incident চললে alternate phone বা approved support channel দিন। Sensitive message ordinary spreadsheet বা shared chat-এ copy করবেন না। Recovery-এর পরে failed time window-এর entries count করে resend notification বা manual follow-up করুন এবং duplicate response এড়াতে owner mark করুন।

একটি বাস্তব diagnosis example

ধরুন একটি service business-এর form entry database-এ আছে, provider log-এ message accepted, কিন্তু Gmail inbox-এ নেই। অন্য recipient-এর full header-এ DKIM pass, SPF fail এবং From alignment সমস্যা দেখা গেল। প্রথম কাজ form plugin বদলানো নয়; authorized sender, verified From এবং provider DNS instructions review করা। পরিবর্তনের পরে একই unique-reference test চালিয়ে provider status, header result এবং inbox placement লিখুন। একটি success দেখেই স্থায়ী fix ঘোষণা করবেন না।

Contact form email delivery checklist

  • Test: একবারের controlled submission-এ unique reference ও exact time আছে।
  • Request: POST status, validation, CSRF ও server error পরীক্ষা হয়েছে।
  • Storage: entry বা privacy-safe application event পাওয়া গেছে।
  • Queue: pending, failed, retry এবং worker status দেখা হয়েছে।
  • Sender: verified From, safe Reply-To ও correct recipient আছে।
  • Provider: message ID, event status ও bounce response record হয়েছে।
  • DNS: SPF, DKIM ও DMARC alignment official setup অনুযায়ী checked।
  • Inbox: spam, quarantine, forwarding ও filter rule review হয়েছে।
  • Recovery: missed enquiries reconcile করার owner ও time window আছে।

Fix করার পরে একই পথ আবার প্রমাণ করুন

একটি DNS record, credential বা queue change করার পরে একসঙ্গে আরও পাঁচটি setting বদলাবেন না। Change time, owner এবং expected result লিখে নতুন unique reference দিয়ে end-to-end retest করুন। Browser success, database entry, queue completion, provider message ID, authentication result এবং destination mailbox। সব ধাপের evidence মিললে fix-এর confidence বাড়ে। DNS propagation বা provider retry চললে “fixed” না লিখে monitoring status দিন। শেষে temporary debug log, test alias ও elevated access সরান। Weekly sample submission এবং failed-job alert রাখলে customer অভিযোগ আসার আগে সমস্যা ধরা যায়। Reliable contact form মানে শুধু Submit button কাজ করা নয়; enquiry নিরাপদে record হওয়া, notification trace করা এবং failure হলেও follow-up হারিয়ে না যাওয়া।