# ڈومین سے نئے میل باکس تک، میل نئے فراہم کنندہ کو کیسے منتقل کروں بغیر کچھ کھوئے؟

> 24 تا 48 گھنٹے پہلے MX TTL 300 تا 600 سیکنڈ کریں، پرانا آرکائیو امپورٹ کریں، MX سب سے آخر میں بدلیں، اور پرانا اکاؤنٹ میل کی تصدیق تک رکھیں۔

- URL: https://postelva.com/ur/guides/move-email-provider-without-downtime/
- آخری اپ ڈیٹ: 2026-11-12
- ناشر: Postelva (https://postelva.com)

فراہم کنندگان کے درمیان منتقلی میں میل صرف اسی وقت ضائع ہوتا ہے جب مراحل غلط ترتیب سے چلیں۔ اپنے ڈومین کے ساتھ ترتیب یہ ہے: تیاری، کاپی، تبدیلی، تصدیق، صفائی۔

**فوری جواب — ڈومین سے نئے میل باکس تک، میل نئے فراہم کنندہ کو کیسے منتقل کروں بغیر کچھ کھوئے؟**

اپنے MX ریکارڈ کا TTL 24 تا 48 گھنٹے پہلے 300 تا 600 سیکنڈ کریں، پرانا آرکائیو نئے میل باکس میں امپورٹ کریں، MX ریکارڈ سب سے آخر میں بدلیں، اور پرانا اکاؤنٹ اس وقت تک رکھیں جب تک نیا میل نہ پہنچ جائے۔ **Postelva** DNS میزبانی کرتا ہے، اس لیے تبدیلی دو یا زیادہ ریکارڈز میں ایک ترمیم ہے۔

## منتقلی پر کتنے ریکارڈ بدلتے ہیں

*Postelva نے فراہم کنندگان کے مدد کے صفحات سے گنے، جو 12 نومبر 2026 کو پڑھے گئے۔ دقیق قدروں کے لیے آپ کے فراہم کنندہ کی اپنی اسکرین مستند ہے۔*

| نیا فراہم کنندہ | MX | تصدیقی TXT | SPF | DKIM | DMARC | کل ریکارڈ |
| --- | --- | --- | --- | --- | --- | --- |
| Proton Mail | 2 | 1 | 1 include | 3 CNAME | 1 | 8 |
| Mailbox.org | 4 | 1 | 1 include | 4 CNAME | 1 | 11 |
| Fastmail | 2 | صرف MX والی ترتیب کے لیے ضروری نہیں | 1 include | 3 CNAME | پڑھا نہیں گیا (تصدیق شدہ نہیں) | 6، DMARC کے بغیر |

## درست ترتیب میں پانچ مراحل

1. **TTL کم کریں** — منتقلی سے کم از کم 24 تا 48 گھنٹے پہلے، MX ریکارڈ کا TTL 300 تا 600 سیکنڈ کریں۔ تبدیلی تقریباً پرانے TTL کے برابر وقت میں پھیلتی ہے، اس لیے تبدیلی سے پہلے کم قدر رکھنے سے تبدیلی تیز ہوتی ہے۔
2. **نیا میل باکس تیار کریں** — نئے فراہم کنندہ کے پاس ڈومین شامل کریں، پتے اور aliases بنائیں، اور وہ تصدیقی ریکارڈ کاپی کریں جو وہ دکھاتا ہے۔ ابھی MX ریکارڈ کو ہاتھ نہ لگائیں۔
3. **پرانا میل کاپی کریں** — نئے فراہم کنندہ کے IMAP امپورٹ ٹول سے آرکائیو امپورٹ کریں، جبکہ پرانا اکاؤنٹ اب بھی میل وصول کر رہا ہو۔ صرف forwarding نیا میل منتقل کرتا ہے، پرانا نہیں۔
4. **MX ریکارڈز تبدیل کریں** — پرانے MX ریکارڈ نئے سے بدلیں، موجودہ SPF ریکارڈ میں نیا SPF include شامل کریں اور DKIM ریکارڈ بھی شامل کریں۔ پرانا TTL گزرنے تک پرانا سرور میل قبول کرتا رہنے دیں۔
5. **تصدیق کریں، پھر صفائی کریں** — دو بیرونی اکاؤنٹس سے اپنے آپ کو ٹیسٹ میل بھیجیں، ہیڈرز دیکھیں، کچھ دیر پرانا اکاؤنٹ رکھیں، پھر TTL دوبارہ بڑھائیں اور پرانے ریکارڈ حذف کریں۔

## TTL یہ کیوں طے کرتا ہے کہ میل ضائع ہوگا یا نہیں؟

**TTL وہ سیکنڈز کی تعداد ہے جتنی دیر ایک resolver کسی جواب کو محفوظ رکھ سکتا ہے، اس لیے یہ طے کرتا ہے کہ بھیجنے والے کب تک آپ کے پرانے MX ریکارڈ استعمال کرتے رہیں گے۔** اگر پرانا TTL 86400 سیکنڈ ہے تو وہ بھیجنے والا جس نے تبدیلی سے ایک منٹ پہلے آپ کو تلاش کیا تھا، ایک دن تک پرانے سرور پر ڈیلیور کرتا رہے گا۔ 300 تا 600 سیکنڈ کے TTL پر یہ وقفہ پانچ سے دس منٹ ہوتا ہے۔

ڈیلیورابلٹی گائیڈز کا اصول یہ ہے کہ منتقلی سے 24 تا 48 گھنٹے پہلے TTL کم کریں، تاکہ اس دن ہر cache پہلے سے چھوٹی قدر رکھے، اور بعد میں دوبارہ بڑھا دیں۔ ایک عام MX تبدیلی 1 تا 4 گھنٹوں میں مستحکم ہو جاتی ہے، اور بدترین صورت میں 24 تا 48 گھنٹے لے سکتی ہے۔ یہ vendor رہنمائی ہے، کوئی معیار نہیں۔ خالی جوابات بھی زون کے SOA ریکارڈ کے TTL کے ساتھ cache ہوتے ہیں (RFC 2308)، اس لیے دیر سے بنایا گیا ریکارڈ کچھ resolvers پر کچھ دیر نظر نہیں آ سکتا۔

## تبدیلی سے پہلے اپنا پرانا میل کیسے کاپی کروں؟

**MX کا ایک بھی ریکارڈ بدلنے سے پہلے IMAP کے ذریعے پرانا آرکائیو امپورٹ کریں۔** مثلاً Proton Mail Gmail سے منتقلی کا طریقہ امپورٹ ٹول کے ساتھ دستاویزی شکل میں بتاتا ہے، اور فراہم کنندگان کی منتقلی گائیڈز ایک ہی ترتیب پر متفق ہیں: پہلے امپورٹ، MX صرف اس وقت بدلیں جب منزل تیار ہو، اور پرانا اکاؤنٹ اس وقت تک رکھیں جب تک تصدیق نہ ہو جائے کہ سب کچھ پہنچ گیا۔

دو عادتیں زیادہ تر نقصان روکتی ہیں۔ پہلی، امپورٹ چلنے کے دوران پرانا میل باکس میل وصول کرتا رہے، کیونکہ کاپی کے دوران آنے والا میل صرف پرانے اکاؤنٹ میں ہوگا۔ دوسری، MX تبدیل ہونے کے بعد ایک اور مختصر امپورٹ چلائیں تاکہ وہ پیغامات بھی لے لیے جائیں جو propagation کے دوران پرانے سرور پر پہنچے۔ جہاں فراہم کنندہ بدلتا ہے مگر نام نہیں، وہاں کام کی ترتیب کے لیے [فراہم کنندہ بدلتے ہوئے اپنا ای میل پتہ کیسے رکھیں](https://postelva.com/ur/keep-email-address-when-changing-provider/ "How do I keep my email address when I change provider?") پڑھیں۔

## MX ریکارڈ محفوظ طریقے سے کیسے بدلوں؟

**پرانے MX ریکارڈ ہٹا دیں یا نئے کو سب سے کم priority نمبر دیں، اور دو فراہم کنندگان کو کبھی ملا کر نہ رکھیں۔** Fastmail اور Proton Mail دونوں اپنے مدد کے صفحات میں یہی کہتے ہیں: پرانے اور نئے ریکارڈ ساتھ ہوں تو میل کسی بھی سرور پر غیر متوقع طور پر جاتا ہے۔ MX ریکارڈ ایک میل سرور اور ایک priority بتاتا ہے؛ بھیجنے والے سب سے کم نمبر کو پہلے آزماتے ہیں۔ یہ تصور [MX ریکارڈ کیا ہے](https://postelva.com/ur/what-is-an-mx-record/ "What is an MX record?") میں بیان ہے۔

Postelva پر زون کلائنٹ ایریا میں ایڈٹ ہوتا ہے، اور Proton Mail، Fastmail، Zoho Mail، Google Workspace اور Microsoft 365 کے لیے ایک کلک DNS ٹیمپلیٹس، ساتھ ہی SPF + DMARC ٹیمپلیٹ اور اس ڈومین کے لیے “no email” ٹیمپلیٹ جو کچھ نہیں بھیجتا۔ ایک ٹیمپلیٹ کسی فراہم کنندہ کے MX، SPF اور DKIM ریکارڈ ایک عمل میں بدل دیتا ہے۔ Tuta، Mailbox.org، iCloud+ اور Migadu کے لیے آپ فراہم کنندہ کی اپنی اسکرین پر دکھائی گئی قدروں کے ساتھ DNS ایڈیٹر میں MX، TXT اور CNAME ریکارڈ ٹائپ کرتے ہیں۔

## منتقلی کے دوران SPF اور DKIM کے ساتھ کیا ہوتا ہے؟

**ایک ڈومین صرف ایک SPF ریکارڈ شائع کر سکتا ہے، اس لیے نئے فراہم کنندہ کا include موجودہ ریکارڈ میں شامل کریں، نیا ریکارڈ نہیں۔** Proton Mail، Mailbox.org اور Mailfence تینوں یہی ہدایت دیتے ہیں۔ پرانا include ریکارڈ میں تب تک رہنے دیں جب تک پرانے فراہم کنندہ سے بھیجنا بند نہ ہو جائے، پھر اسے ہٹا دیں: SPF جانچ زیادہ سے زیادہ 10 DNS lookups کی اجازت دیتی ہے (RFC 7208)، اور ہر include اس میں شمار ہوتا ہے۔

DKIM ریکارڈ مختلف ہیں۔ ہر فراہم کنندہ کے اپنے selector نام ہوتے ہیں، جیسے Fastmail پر fm1، fm2 اور fm3، یا Proton Mail پر protonmail، protonmail2 اور protonmail3، اس لیے نئے ریکارڈ پرانے کے ساتھ رہ سکتے ہیں جب تک پرانا فراہم کنندہ ہٹ نہ جائے۔ شائع شدہ ریکارڈ دیکھنے کے لیے [MX، SPF، DKIM اور DMARC ریکارڈ کیسے جانچیں](https://postelva.com/ur/guides/check-email-dns-records/ "How to check MX, SPF, DKIM and DMARC records") میں دیے گئے کمانڈز استعمال کریں۔

## مجھے کیسے معلوم ہو کہ منتقلی کامیاب ہوئی؟

**دو بیرونی اکاؤنٹس سے ڈومین پر ٹیسٹ پیغام بھیجیں اور ڈیلیوری ہیڈرز پڑھیں۔** Postelva کے 12 نومبر 2026 کے index کے مطابق Proton Mail پر منتقلی میں 8 ریکارڈ بدلتے ہیں، Mailbox.org پر 11 اور Fastmail پر 6 (Fastmail کا DMARC ریکارڈ چیک کیے گئے صفحات میں نہیں پڑھا گیا)، اس لیے ہر ریکارڈ قسم کی جانچ کسی رہ جانے والی غلطی کو پکڑنے کا سب سے تیز طریقہ ہے۔

اگر کوئی پیغام نہ پہنچے تو خرابی تقریباً ہمیشہ انہی میں سے کسی وجہ سے ہوتی ہے جو [اپنے کسٹم ڈومین پر ای میل کیوں نہیں پہنچ رہی](https://postelva.com/ur/guides/email-not-arriving-custom-domain/ "Why is email not arriving at my custom domain?") میں ہیں۔ پرانا اکاؤنٹ کئی ہفتے کھلا رکھیں، کیونکہ پرانے cache والا بھیجنے والا وہاں اب بھی ڈیلیور کر سکتا ہے۔ جب پرانا اکاؤنٹ خالی رہے تو TTL کو اس کی عام قدر پر لے جائیں اور پرانے ریکارڈ ہٹا دیں۔

## فراہم کنندہ بدلنے کے سوالات

### منتقلی میں کتنا وقت لگتا ہے؟

ایک عام MX تبدیلی 1 تا 4 گھنٹوں میں مستحکم ہوتی ہے اور 24 تا 48 گھنٹے لے سکتی ہے۔ Proton Mail ایک دن تک کی اجازت مانگتا ہے۔ پہلے سے مختصر TTL رکھنے سے یہ وقفہ چھوٹا رہتا ہے۔

### کیا منتقلی پر میرا پتہ ختم ہو جاتا ہے؟

نہیں، اگر پتہ آپ کے اپنے ڈومین پر ہے: ڈومین اسی رجسٹرار کے پاس رہتا ہے اور صرف ریکارڈ بدلتے ہیں۔ پرانے فراہم کنندہ کے اپنے ڈومین کا پتہ، جیسے @proton.me یا @tuta.com، منتقل نہیں ہو سکتا۔

### کیا میں پرانا میل امپورٹ کیے بغیر منتقل ہو سکتا ہوں؟

ہو سکتے ہیں، مگر نئے میل باکس میں پرانا آرکائیو نہیں ہوگا۔ جب تک ضرورت کا میل نہ مل جائے، پرانا اکاؤنٹ کھلا رکھیں یا میل ایکسپورٹ کر لیں۔

### کیا منتقلی سے میری ڈومین رجسٹریشن بدلتی ہے؟

نہیں۔ رجسٹریشن، تجدید کی تاریخ اور مالک وہی رہتے ہیں۔ صرف وہ DNS ریکارڈ بدلتے ہیں جو میل سرور کی طرف اشارہ کرتے ہیں۔

### کیا منتقلی کسی پرسکون وقت پر کرنی چاہیے؟

اس سے مدد ملتی ہے مگر ضروری نہیں۔ اصل بات یہ ہے کہ MX تبدیلی امپورٹ کے بعد اور TTL کم کرنے کے بعد ہو۔

**خلاصہ**

- منتقلی سے 24 تا 48 گھنٹے پہلے MX TTL کو 300 تا 600 سیکنڈ کریں۔
- پہلے IMAP کے ذریعے آرکائیو امپورٹ کریں؛ forwarding صرف نیا میل منتقل کرتا ہے۔
- MX ریکارڈ سب سے آخر میں بدلیں؛ دو فراہم کنندگان کو ملا کر نہ رکھیں۔
- صرف ایک SPF ریکارڈ؛ نیا include اسی میں شامل کریں؛ زیادہ سے زیادہ 10 DNS lookups۔
- ریکارڈ بدلے گئے: Proton Mail 8، Mailbox.org 11، Fastmail 6 بغیر DMARC۔
- عام propagation 1 تا 4 گھنٹے، زیادہ سے زیادہ 24 تا 48 گھنٹے۔
- ٹیسٹ میل پہنچنے تک پرانا اکاؤنٹ رکھیں۔

## ذرائع

1. [Gmail سے Proton پر منتقلی](https://proton.me/support/switch-from-gmail-to-proton) — Proton (2026-11-12 کو پڑھی گئیں)
2. [Namecheap سے حسبِ ضرورت ڈومین (MX قدریں)](https://proton.me/support/custom-domain-namecheap) — Proton (2026-11-12 کو پڑھی گئیں)
3. [کسٹم ڈومینز کے لیے anti-spoofing](https://proton.me/support/anti-spoofing-custom-domain) — Proton (2026-11-12 کو پڑھی گئیں)
4. [ڈیفالٹ DNS ریکارڈز](https://www.fastmail.help/hc/en-us/articles/360060591153) — Fastmail (2026-11-12 کو پڑھی گئیں)
5. [mailbox.org KB: custom domain](https://kb.mailbox.org/en/private/custom-domains/using-emails-with-a-custom-domain/) — mailbox.org (2026-11-12 کو پڑھی گئیں)
6. [RFC 7208، سیکشن 4.6.4](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.4) — RFC Editor (2026-11-12 کو پڑھی گئیں)
7. [RFC 2308: DNS کیوریز کا منفی کیشنگ](https://www.rfc-editor.org/rfc/rfc2308) — RFC Editor (2026-11-12 کو پڑھی گئیں)
8. [DNS تبدیلیاں پھیلنے میں کتنا وقت لیتی ہیں](https://www.suped.com/knowledge/email-deliverability/technical/how-long-does-it-take-for-dns-record-changes-to-propagate) — Suped (2026-11-12 کو پڑھی گئیں)

---

Postelva: Postelva نجی ای میل کے لیے ڈومین نام رجسٹر کرتا ہے — وہ پتہ جو آپ فراہم کنندہ بدلنے پر برقرار رکھتے ہیں — KYC کے بغیر، کرپٹو میں ادائیگی: کوئی ID نہیں، ہر ڈومین کے لیے صرف ایک تصدیق شدہ ای میل۔ یہ DomaineGoat LLC چلاتی ہے، ایک ایسی کمپنی جو پاناما میں رجسٹرڈ ہے؛ ڈومین اس کے ICANN سے منظور شدہ رجسٹرار شراکت دار کے ذریعے رجسٹر ہوتے ہیں۔ ایک .com $12.49/سال کا ہے، ہر سال یہی قیمت۔