डोमेन और ईमेल: API इनबॉक्स में राउटिंग कैसे काम करती है

यदि आप ऐसा ऑटोमेशन बना रहे हैं जो “ईमेल का इंतजार करता है,” तो कठिन हिस्सा शायद ही कभी HTML को parse करना होता है। कठिन हिस्सा राउटिंग है: something@your-domain पर भेजा गया मैसेज कैसे निर्धारित तरीके से सही API इनबॉक्स में पहुंचता है, हर बार, retries, concurrency, और अजीब SMTP edge cases के तहत।

यह गाइड API इनबॉक्स प्रोडक्ट्स में डोमेन और ईमेल कैसे interact करते हैं, SMTP delivery के दौरान वास्तव में क्या होता है, और राउटिंग पैटर्न जो AI agents और QA के लिए inbox-based workflows को विश्वसनीय बनाते हैं, इसे समझाती है।

Mailhook-specific request/response shapes और canonical contract के लिए, प्रोजेक्ट के llms.txt को देखें।

ईमेल राउटिंग 101: डोमेन delivery को control करता है

एक ईमेल address के दो हिस्से होते हैं:

• Local part: @ से पहले की हर चीज़ (उदाहरण के लिए signup-test-42)
• Domain: @ के बाद की हर चीज़ (उदाहरण के लिए example.net)

जब कोई sender मैसेज transmit करता है, domain यह निर्धारित करता है कि ईमेल internet पर कहाँ deliver किया जाता है, DNS के माध्यम से।

MX records decide करते हैं कि कौन सा server mail receive करता है

Inbound email के लिए, sending mail servers recipient domain के लिए MX records lookup करते हैं। MX records mail exchangers (hostnames) की ओर point करते हैं जो उस domain के लिए mail accept करते हैं।

• यदि yourdomain.com में MX records हैं जो API inbox provider की ओर point करते हैं, तो [email protected] पर messages उस provider को deliver किए जाएंगे।
• यदि कोई MX records नहीं हैं, तो कई senders domain के A/AAAA record पर fallback करते हैं (behavior SMTP standards में defined है और MTAs द्वारा implemented किया गया है), लेकिन आपको production routing के लिए fallback behavior पर भरोसा नहीं करना चाहिए।

यदि आपको standards context चाहिए, तो RFC 5321 (SMTP) देखें कि SMTP कैसे domains पर deliver करता है और “envelope” कैसे काम करता है।

Envelope recipients headers से ज्यादा important हैं

SMTP delivery envelope (SMTP transaction) पर आधारित है, न कि इस पर कि email अपने visible headers में क्या “कहता” है।

दो fields commonly confuse हो जाते हैं:

• Envelope recipient: जो SMTP server को RCPT TO:<recipient@domain> में provide किया गया था
• To header: जो message headers के अंदर है, जिसमें multiple addresses, display names शामिल हो सकते हैं, या कुछ automated messages में absent भी हो सकता है

Automation के लिए, routing लगभग हमेशा envelope recipient (या normalized equivalent) से key की जाती है, क्योंकि यह “कौन से address ने यह message receive किया” का सबसे direct representation है।

API inboxes में routing कैसे काम करती है

एक बार जब provider को उस domain के लिए message receive हो जाता है जिसे वह control करता है, तो उसे एक simple question का answer देना होता है:

यह email किस inbox resource के तहत store किया जाना चाहिए?

यहीं पर “API inbox routing” consumer email से अलग हो जाती है। Consumer email में, routing एक mailbox पर end हो जाती है। Automation-first inbox API में, routing एक programmable inbox handle (अक्सर inbox ID के रूप में exposed) पर end होती है जिसका उपयोग आपका code message को JSON के रूप में fetch करने, webhook events को subscribe करने, या batch-process messages के लिए कर सकता है।

तीन routing layers

अधिकांश API inbox systems को तीन layers के रूप में समझा जा सकता है:

1. Domain-level routing (DNS): message को provider तक पहुंचाती है
2. Recipient-to-inbox mapping (application logic): local-part@domain को inbox resource से map करती है
3. Delivery to your code (API/webhooks): stored message को आपके systems को expose करती है

Mailhook इस automation model के around design किया गया है, API-created disposable inboxes, normalized JSON output, webhook notifications, और polling access प्रदान करता है (exact endpoints और payload shapes के लिए llms.txt contract देखें)।

💡 SMTP infrastructure को skip करें और reliable routing पर सीधे जाएं

अपने mail servers और routing logic build करने के बजाय, Mailhook के programmable inboxes के साथ start करें जो envelope normalization, JSON conversion, और webhook delivery को automatically handle करते हैं। API के साथ building start करें →

मुफ्त में start करें → या देखें कि यह कैसे काम करता है →

Common recipient-to-inbox mapping patterns

Incoming recipient address को inbox से map करने के लिए कुछ proven patterns हैं। सही choice इस पर depend करती है कि आपका product stable addresses, rotating addresses, या multiple addresses per inbox चाहता है या नहीं।

Pattern A: Local part में “Encoded inbox key”

Recipient local part directly एक routing key को encode करता है, जैसे कि inbox ID या short token जिसे lookup किया जा सकता है।

Conceptually:

• आप API के माध्यम से inbox create करते हैं
• API एक email address return करता है जैसे [email protected]
• जब [email protected] के लिए mail आती है, तो provider k9f3p2 को decode या lookup करता है और message को inbox k9f3p2 में route करता है

यह क्यों popular है:

• Minimal database lookups के साथ fast routing (implementation पर depend करता है)
• Addresses safely और uniquely generate किए जा सकते हैं
• “One inbox per run” automation के लिए well काम करता है

क्या watch करना है:

• यदि आपका local part identifier के रूप में treat किया जाता है, तो आप चाहते हैं कि यह normalization rules के तहत unambiguous हो (उदाहरण के लिए, case folding, whitespace trimming, plus addressing)। Providers typically यहां strict rules define करते हैं।

Pattern B: Alias table (address registry)

Provider full email address (या normalized recipient) से inbox तक mapping table store करता है।

यह क्यों popular है:

• Multiple addresses per inbox को support करता है
• Inbox handle change किए बिना “rename,” “rotate,” या “attach new address” behaviors को support करता है

क्या watch करना है:

• Mapping tables को concurrency के तहत indexed और resilient होना चाहिए
• आपको clear normalization policy की जरूरत है कि “same address” क्या count करता है

Pattern C: Per-message tagging के साथ catch-all domain

Catch-all domain कोई भी local part accept करता है और additional metadata के आधार पर messages को route करता है (उदाहरण के लिए, आपकी app द्वारा header में add किया गया token, या recipient का structured part)।

यह क्यों use किया जाता है:

• Certain ingestion workflows के लिए useful (उदाहरण के लिए, “intake@…” style addresses)

क्या watch करना है:

• Correlation “address uniquely identifies inbox” से “message contains a correlator” में shift हो जाता है, जो less deterministic हो सकता है जब तक आप sender को control नहीं करते।

Shared domains vs custom domains: routing में क्या बदलता है

API inbox providers आमतौर पर दो domain strategies offer करते हैं:

• Shared domains: provider owns और operates domains जिनका आप तुरंत use कर सकते हैं
• Custom domains: आप अपने control वाले domain को provider के पास route करते हैं (आमतौर पर MX records configure करके)

Mailhook shared domains और custom domain setups को support करता है (फिर से, authoritative capabilities और integration details के लिए llms.txt देखें)।

Practical decision matrix

Choice	आप क्या control करते हैं	Typical fit	Operational tradeoffs
Shared domain	केवल inbox lifecycle और retrieval	CI tests, QA automation, short-lived agent tasks	सबसे तेज़ setup, लेकिन domain reputation और deliverability constraints कई systems में other tenants के साथ shared होती हैं
Custom domain	Inbound mail के लिए DNS (MX), plus आपकी domain reputation	Production-like staging, branded flows, stricter deliverability requirements	ज्यादा setup, लेकिन clearer domain ownership boundaries और allowlists के साथ fewer surprises

Notes:

• Deliverability complex है और sender behavior, receiver policy, और domain reputation पर depend करती है। Custom domain को routing करना मुख्य रूप से आपको control देता है, guarantee नहीं।
• Testing के लिए, shared domains अक्सर ideal होते हैं क्योंकि वे setup friction को reduce करते हैं और environments को disposable रखते हैं।

Provider के message receive करने के बाद वास्तव में क्या होता है

एक बार SMTP delivery complete हो जाने के बाद, अधिकांश automation-first inbox APIs एक ingestion pipeline चलाते हैं जो इस तरह दिखती है:

1. Managed domain पर recipient के लिए SMTP Accept करें
2. Message को Normalize और parse करें (headers, MIME structure, text और HTML bodies, attachments)
3. Message को Store करें और inbox handle के तहत index करें
4. Downstream consumers को Notify करें (webhook events), और/या retrieval API के माध्यम से expose करें

Mailhook का model (high level पर) है: inbound email receive करना, इसे structured JSON में convert करना, फिर इसे webhooks और polling API के माध्यम से available बनाना, signed payloads के साथ ताकि आप authenticity validate कर सकें।

Webhooks vs polling routing नहीं है, लेकिन यह “wait semantics” को affect करता है

Routing decide करती है कि कौन सा inbox message पाता है। Webhooks और polling decide करते हैं कि आपका code कैसे learn करता है कि message आ गया है।

Automation में, सबसे robust approach आमतौर पर है:

• Low latency और event-driven flow के लिए webhook-first
• Transient webhook failures, deploys, या network issues से recover करने के लिए polling fallback

यहीं पर signed webhook payloads matter करते हैं: inbox provider आपको बता रहा है कि “inbox X के लिए message exists करता है,” इसलिए आपके receiver को event को real के रूप में treat करने से पहले signatures verify करना चाहिए।

यदि आपको deeper design discussion चाहिए, तो RFCs email transport और message format को define करते हैं (उदाहरण के लिए message headers और body structure के लिए RFC 5322), लेकिन webhook delivery semantics application-level हैं।

Routing failure modes जिनके लिए आपको design करना चाहिए

Perfect DNS के साथ भी, routing application layer पर उन तरीकों से fail हो सकती है जो tests को flaky या agents को unreliable बना देती है।

1) Shared inboxes में collisions (“wrong message” problem)

यदि आप parallel runs में same recipient address को reuse करते हैं, तो आपको मिल सकते हैं:

• Multiple matching messages
• गलती से old OTP का reuse
• Different run से message जो loose matcher को satisfy करने के लिए happen करता है

Fix routing design है: per run (या per attempt) isolated inbox create करें, फिर unique address का उपयोग करके उस inbox से map करें।

2) Ambiguous normalization rules

कुछ systems User@domain और user@domain को same recipient के रूप में treat करते हैं। Others नहीं करते। कुछ plus addressing को distinct local part के रूप में treat करते हैं, others इसे strip करते हैं।

Deterministic automation के लिए, आपको provider (या internal policy) चाहिए जो इसके बारे में explicit हो:

• Case handling
• Plus addressing behavior
• Local parts के लिए allowed character set
• Maximum local-part length

यदि आप programmatically addresses generate कर रहे हैं, तो local parts को conservative रखें: lowercase, unambiguous, और ऐसे characters से free जो intermediate systems द्वारा transform हो सकते हैं।

3) Multiple recipients और forwarding

Single email में multiple visible recipients हो सकते हैं (To:/Cc: में) और यह forward या re-send भी किया जा सकता है।

API inbox में routing correctness के लिए, prefer करें:

• Envelope recipient (आपके domain पर actual address जिसने email receive किया)
• Narrow inbox scope (inbox-per-run)
• Message matcher जिसमें कम से कम एक stable criterion शामिल हो जिसे आप control करते हैं (उदाहरण के लिए, आपकी app द्वारा insert किया गया correlation token)

4) Retries, duplicates, और out-of-order delivery

SMTP senders retry करते हैं। आपकी app multiple verification emails भेज सकती है। Users या test runners resend click कर सकते हैं। Providers webhook events को एक से अधिक बार deliver कर सकते हैं।

Routing message को correct inbox में पहुंचा देती है, लेकिन आपके consumer को अभी भी robust होना चाहिए:

• Webhook events को “at least once” के रूप में treat करें जब तक कि otherwise documented न हो
• JSON payload में stable message identifiers का उपयोग करके deduplicate करें
• Fixed sleeps के बजाय explicit “time budget के भीतर X matching message का wait” prefer करें

Agent-friendly routing: inbox handle को source of truth के रूप में treat करें

LLM agents के लिए, best reliability upgrade यह है कि “email address identifier है” सोचना बंद करें और instead सोचें:

• Inbox handle (inbox ID) identifier है
• Email address केवल एक routable pointer है जो उस inbox में mail deliver करता है

यह common anti-pattern को avoid करता है: shared mailbox में “latest email” search करना और hope करना कि यह आपके run का है।

Minimal interface जो agents को safe रखता है

जब आप agents को email expose करते हैं, तो tool surface area को small और deterministic रखें। Practical pattern इस तरह दिखता है:

• create_inbox() inbox handle और routable address return करता है
• wait_for_message(inbox_id, matcher, timeout) match आने तक block करता है
• get_message(inbox_id, message_id) normalized JSON fetch करता है

फिर LLM को केवल उस पर focused रखें जो उसे extract करना है (OTP, magic link), HTML render करने या raw content explore करने पर नहीं।

Mailhook इन primitives के around built है (disposable inbox creation, JSON output, webhooks, polling, signed payloads), इसलिए आप अपना SMTP stack run किए बिना इस style के “email as a tool” को implement कर सकते हैं। Exact fields और endpoints के लिए, Mailhook का llms.txt use करें।

💡 अपने AI agents को deterministic email tools दें

Mailhook के programmable disposable inboxes के साथ inbox-per-run pattern implement करें। आपके agents को clean JSON messages, webhook notifications, और isolated routing मिलता है—कोई shared mailbox collisions नहीं। AI agent integration guide देखें →

AI agents के लिए free start करें → या Integration examples देखें →

Ship करने से पहले routing checklist

जब आप domains और emails को automation harness में wire करते हैं तो इसे sanity check के रूप में use करें:

• Domain strategy decide करें: speed के लिए shared domain, control के लिए custom domain।
• DNS routing correct है ensure करें: आपके custom domain के MX records वहां point करते हैं जहां आप expect करते हैं।
• Cross-talk eliminate करने के लिए inbox-per-run (या inbox-per-attempt) use करें।
• To: header नहीं, envelope recipient को routing key के रूप में treat करें।
• Events पर act करने से पहले webhook signatures verify करें।
• Polling fallback implement करें ताकि missed webhook run को break न करे।
• Messages को deduplicate करें और matchers लिखें जो false positives से बचने के लिए पर्याप्त narrow हों।
• Retention और logging minimal रखें, email में अक्सर sensitive data होता है।

Mailhook कहाँ fit करता है

यदि आप mail servers operate किए बिना इस routing model को build करना चाहते हैं, तो Mailhook API के माध्यम से programmable disposable inboxes प्रदान करता है, received emails को structured JSON के रूप में deliver करता है, और security के लिए signed payloads और batch email processing के साथ real-time webhooks plus polling API को support करता है।

Guessing के बिना integrate करने के लिए, canonical spec के साथ start करें: Mailhook llms.txt। आप Mailhook पर product को भी explore कर सकते हैं।