ईमेल-निर्भर टेस्ट फ्लोज़ वह जगह हैं जहाँ “यह मेरी मशीन पर काम करता है” वाली बात दम तोड़ देती है। ईमेल देर से आता है, गलत इनबॉक्स में पहुँचता है, दोबारा भेजा जाता है, या किसी ऐसे vendor से आता है जो केवल allowlisted domains पर deliver करता है। यदि आप QA automation या LLM-driven agents बना रहे हैं जिन्हें signups, password resets, या magic-link logins complete करने हैं, तो कस्टम डोमेन के साथ ईमेल पता अक्सर इन फ्लोज़ को deterministic और enterprise-compatible बनाने का सबसे सरल तरीका है।
यह गाइड एक practical setup के बारे में बताता है: एक safe domain layout चुनें, DNS कॉन्फ़िगर करें, ऐसी addressing scheme चुनें जो CI में scale करे, फिर inbound messages को इस तरह consume करें जो automation के लिए reliable और agents के लिए safe हो।
Mailhook-specific integration details (endpoints, payloads, webhook signatures) के लिए, llms.txt पर canonical reference का उपयोग करें।
Testing के लिए “कस्टम डोमेन के साथ ईमेल पता” का मतलब
Test automation में, मुख्य requirement “mailbox UI” नहीं है। यह एक routable address है जिसे आप control करते हैं, जो एक API द्वारा backed हो जिसे आपका code query कर सके।
एक typical model इस तरह दिखता है:
- आप एक domain (या subdomain) के मालिक हैं जैसे
qa-mail.example.com। - आप उस domain के MX records को एक inbound email provider पर point करते हैं।
- प्रत्येक test run उस domain के तहत unique recipients बनाता है (isolation के लिए)।
- आपका test runner या agent inbound emails को structured data (ideally JSON) के रूप में receive करता है, और एक minimal artifact (OTP या verification URL) extract करता है।
यदि आप पहले domain strategies की तुलना कर रहे हैं, तो देखें Email Domains for Testing: Shared vs Custom।
कब कस्टम डोमेन effort के लायक है
Shared domain quick starts के लिए बेहतरीन है, लेकिन कस्टम डोमेन तब important हो जाता है जब आपको ऐसा control चाहिए जिसे external vendors recognize करें।
कस्टम डोमेन setup आमतौर पर तब justified होता है जब:
- कोई SaaS vendor, customer, या IdP domain allowlisting की require करता है।
- आपको environments (
dev,staging,prod-like) और parallel CI shards में strong isolation चाहिए। - आप दूसरे tenants के traffic के कारण कम deliverability surprises चाहते हैं।
- आपको predictable routing rules (catch-all, alias tables, या encoded local-parts) चाहिए बिना collisions के।
Setup, एक नज़र में
आप इस काम को तीन layers में सोच सकते हैं: DNS routing, recipient mapping, और message consumption।
| Layer | आप क्या configure करते हैं | Tests के लिए यह क्यों मायने रखता है |
|---|---|---|
| DNS (domain routing) | आपके domain या subdomain के लिए MX records | यह ensure करता है कि inbound email आपके system में deliverable है |
| Addressing (recipient mapping) | प्रत्येक run/attempt के लिए unique recipients कैसे generate करें | Collisions को रोकता है और correlation को deterministic बनाता है |
| Retrieval (automation interface) | Webhooks और/या polling जो structured JSON return करती है | Brittle HTML scraping को eliminate करता है और flakiness कम करता है |
Step 1: ऐसा domain layout चुनें जो बाद में परेशान न करे
ज़्यादातर teams को test inbox routing के लिए apex domain (जैसे example.com) का इस्तेमाल avoid करना चाहिए। इसके बजाय, एक dedicated subdomain बनाएं जो intent communicate करे और separation support करे।
Practical patterns:
-
qa-mail.example.comshared QA inbox domain के लिए -
staging-mail.example.comstaging-only flows के लिए -
mail.dev.example.comयदि आप environment nesting चाहते हैं
इससे आपको मिलता है:
- Safer blast radius (आप real corporate email को प्रभावित किए बिना records को delete या change कर सकते हैं)।
- Third parties के लिए clear allowlisting guidance (“allow
qa-mail.example.com”)। - अगर आप बाद में providers migrate करते हैं तो easier cleanup और rotation।
Step 2: MX records को आपके inbound provider पर point करें
Inbound SMTP delivery MX records द्वारा control होती है। जब कोई sender [email protected] पर mail deliver करने की कोशिश करता है, तो उनका mail server qa-mail.example.com के लिए MX records lookup करता है और listed provider से connect होता है।
क्या करना है:
- अपने DNS provider में, वे MX records create करें जो आपका inbound provider specify करता है।
- Iterating के दौरान short TTL set करें (उदाहरण के लिए 60 से 300 seconds), फिर stable होने के बाद इसे बढ़ाएं।
- यदि आपका provider custom domains support करता है (Mailhook करता है), तो उनके custom-domain onboarding steps और validation requirements को follow करें।
क्योंकि MX values provider-specific होते हैं, इन्हें guess न करें। Mailhook के current contract और instructions के लिए, llms.txt से शुरू करें।
Propagation और routing verify करें
DNS changes “saved” लग सकते हैं लेकिन हर जगह live नहीं हो सकते। Externally verify करें:
# अपने subdomain से replace करें
DIG_DOMAIN="qa-mail.example.com"
dig MX "$DIG_DOMAIN" +short
यदि आपको कोई MX records दिखाई नहीं देते, या वे आपके provider की expected values से match नहीं करते, तो delivery fail हो जाएगी।
Debugging के लिए एक subtle लेकिन important detail भी याद रखें: SMTP routing envelope recipient (SMTP delivery के दौरान उपयोग होने वाला address) पर based होती है, जो email body में दिखाए गए To: header से अलग हो सकता है। यदि आप conceptual model चाहते हैं, तो Mailhook की routing deep dive यहाँ है: Domains and Emails: How Routing Works in API Inboxes।
Step 3: ऐसी addressing scheme चुनें जो CI में scale करे
एक बार domain correctly route हो जाने पर, आपके tests को accidental overlap के बिना बहुत सारे unique addresses generate करने का तरीका चाहिए।
यहाँ common recipient mapping options हैं, और parallelism के तहत ये कैसे behave करते हैं:
| Mapping strategy | Example recipient | अच्छा है | Common pitfall |
|---|---|---|---|
| Encoded local-part | [email protected] |
High parallel CI, easy correlation | Normalization rules और length limits से सावधान रहें |
| Alias table | [email protected] |
Human-readable, stable fixtures | Alias state को manage करना पड़ता है |
| Catch-all with tags | [email protected] |
Fast experimentation | यदि आप per run isolate नहीं करते तो collisions create करना आसान |
Testing flows के लिए, “encoded local-part” pattern सबसे robust होता है क्योंकि यह uniqueness को explicit बनाता है।
एक practical convention:
- प्रत्येक test attempt के लिए
run_id(याattempt_id) generate करें। - इसे recipient local-part में उपयोग करें।
- इसे अपने test artifacts के साथ store करें ताकि failures debuggable हों।
Important: यह assume न करें कि हर system case, dots, या plus addressing semantics को providers में consistently preserve करता है। यदि आप अपनी app में user-entered email addresses accept करते हैं, तो अपनी product policy को अपने test harness के उपयोग से अलग रखें। Edge cases पर deep dive के लिए, देखें Email Addresses in Automation: Validation and Edge Cases।
Step 4: Inbound email को deterministically consume करें (webhook first, polling as fallback)
ज़्यादातर flaky email tests दो कारणों में से एक के लिए fail करते हैं:
- वे गलत जगह देखते हैं (shared inbox, wrong run)।
- वे गलत तरीके से wait करते हैं (event-driven waits के बजाय fixed sleeps)।
एक reliable pattern यह है:
- प्रत्येक run या प्रत्येक attempt के लिए एक inbox create करें।
- Arrival के लिए webhook signal को prefer करें।
- Polling को fallback के रूप में रखें (CI environments के लिए जहाँ inbound webhooks hard हैं)।
Mailhook real-time webhook notifications और polling API दोनों support करता है, और emails को structured JSON के रूप में deliver करता है, जो HTML scraping से बहुत safer है।
Minimal “inbox per attempt” flow (provider-agnostic pseudocode)
attempt_id = new_uuid()
inbox = create_inbox({
domain: "qa-mail.example.com",
metadata: { attempt_id }
})
# जब आपकी app address के लिए पूछे तो inbox.email का उपयोग करें
submit_signup_form(email=inbox.email)
# Deterministic wait (webhook-first, polling fallback)
msg = wait_for_message({
inbox_id: inbox.inbox_id,
match: { purpose: "signup_verification" },
timeout_seconds: 60
})
artifact = extract_verification_artifact(msg) # OTP या URL
complete_verification(artifact)
Real systems में मायने रखने वाले दो implementation details:
- Idempotency: retries होती हैं। आपकी “wait” और “consume” logic को duplicate deliveries tolerate करनी चाहिए।
- Narrow matching: stable signals पर match करें जिन्हें आप control करते हैं (correlation header, body में run token), fragile HTML layout पर नहीं।
यदि आप specifically signups के लिए full reliability recipe चाहते हैं, तो देखें Generate Temp Email for Signup Tests Without Flakes।
Webhook security test reliability का हिस्सा है
यदि आपका provider webhook payloads sign करता है (Mailhook signed payloads support करता है), तो signature verify करें और invalid requests को reject करें। यह spoofed “email arrived” events को आपकी test pipeline को contaminate करने से रोकता है।
इसे किसी भी दूसरी event ingestion की तरह treat करें:
- Signature verify करें।
- Replay risk कम करने के लिए timestamp tolerance enforce करें।
- Handlers को idempotent बनाएं।
Step 5: LLM agents के लिए email को handle करना safe बनाएं
Email untrusted input है, और agent tooling risk को amplify करती है क्योंकि LLM content में embedded links को follow कर सकता है या instructions execute कर सकता है। जब आप inbox को agent से connect करते हैं, तो constrained interface design करें।
Recommended guardrails:
- Agent को minimized, structured view provide करें (subject, sender, received time, और extracted OTP या single verification URL)।
- Clickable links के लिए domains को allowlist करें, और किसी भी navigation से पहले explicit confirmation require करें।
- Agent loop में HTML render न करें।
text/plainया sanitized extraction pipeline को prefer करें। - Identifiers (inbox_id, message_id, attempt_id) log करें, full bodies नहीं, जब तक आपकी strong retention policy न हो।
Mailhook का emails को JSON के रूप में receive करने का model इसके लिए good fit है, क्योंकि आप messages को data records की तरह treat कर सकते हैं और केवल वही pass कर सकते हैं जिसकी agent को ज़रूरत है।
Step 6: कस्टम डोमेन के साथ “email not received” को troubleshoot करना
जब कस्टम डोमेन setup fail हो जाता है, तो आपको एक checklist चाहिए जो DNS problems को application problems से distinguish करे।
इन high-signal checks से शुरू करें:
-
digका उपयोग करके confirm करें कि MX records present और correct हैं। - Confirm करें कि आप exactly उसी domain पर send कर रहे हैं जिसे आपने configure किया है (typos और wrong environment subdomains आम हैं)।
- Confirm करें कि system SMTP envelope layer पर right recipient का उपयोग कर रहा है (सिर्फ़
To:header का नहीं)। - यदि आप webhooks का उपयोग कर रहे हैं, तो confirm करें कि आपका endpoint public internet से reachable है और signature verification valid events को reject तो नहीं कर रहा।
- यदि आप polling कर रहे हैं, तो confirm करें कि आपका polling loop explicit timeouts का उपयोग कर रहा है और newest matching message को ignore तो नहीं कर रहा।
यदि आपको deeper debug करना है, तो अपने provider के JSON output से stable identifiers का full set capture करें और उन्हें अपने CI logs में correlate करें (attempt_id, inbox_id, message_id)। यह “it flaked” को actionable trace में बदल देता है।
Mailhook के साथ सब कुछ together put करना
Mailhook बिल्कुल इसी style के workflow के लिए designed है: API के via disposable inboxes create करें, shared या custom domains के लिए email route करें, और webhook notifications या polling के via messages को structured JSON के रूप में consume करें।
Stale examples से बचने के लिए, Mailhook के canonical integration contract को llms.txt पर use करें। यदि आप कस्टम डोमेन को जल्दी running करना चाहते हैं और फिर अपने approach को harden करना चाहते हैं, तो ये दो posts इस guide को complement करती हैं:
एक बार आपका कस्टम डोमेन place में आ जाने पर, सबसे बड़ा win organizational है: आपकी team email को testable event stream की तरह treat कर सकती है, flaky side channel की तरह नहीं।
