רשימת בדיקות מלאה להעברת דוא״ל (2026)

רשימת בדיקות להעברת דוא״ל: מה לבדוק לפני המעבר ואחריו

אם מתייחסים להעברת דוא״ל כאל פעולת העתקה והדבקה, עלולים להיתקל באובדן נתונים שקט, בשרשורי תשובות שנקטעו ובתור תמיכה מלא בהחזרות של משתמש לא ידוע. רשימת בדיקות מקצועית למפעילי המערכת מצמצמת את ההפתעות האלה.

הרשימה מיועדת למי שאינו יכול להרשות לעצמו השבתה. היא מדלגת על התאוריה ומתמקדת בדרישות המבניות למעבר ללא אובדן נתונים. למתודולוגיה המלאה ראו את המדריך להגדרת דוא״ל.

לפני ההמראה: מיפוי יסודי

אי אפשר להעביר את מה שלא רואים. מקור הכשל הנפוץ ביותר הוא מערכות צל, כלומר אובייקטים שקיימים בספרייה אך אינם מופיעים ברשימת המשתמשים. כל רשימת בדיקות להעברה חייבת להתחיל בטיפול בנקודה העיוורת הזאת.

1. מפת תשתית וזהויות

מיפוי כל סוגי האובייקטים: אל תספרו רק משתמשים. יש למפות גם רשימות תפוצה, תיבות משותפות ותיקיות ציבוריות.
תיעוד כתובות proxy: ודאו שכל proxyAddress במקור ממופה ליעד.
חיוני בהעברת Exchange: מפו את LegacyExchangeDN (X.500) למערכת החדשה ככתובת proxy מסוג x500:. אם מדלגים על כך, תשובות פנימיות עלולות לחזור עם דוחות אי מסירה מסוג IMCEAEX.

בדיקת העברות נסתרות

כללי העברה בצד השרת אינם עוברים דרך IMAP. חשפו אותם לפני שמתחילים:

Get-Mailbox -ResultSize Unlimited |
Where-Object {($_.ForwardingAddress -ne $null) -or ($_.ForwardingSmtpAddress -ne $null)} |
Select Identity, ForwardingAddress, ForwardingSmtpAddress

2. איתור התיבות הכבדות

סמנו תיבות גדולות מ-20 GB. רוב הספקים מגבילים קליטת IMAP. קשה להעביר תיבה של 50 GB בסוף שבוע יחיד, ולכן יש להתחיל בהכנת משתמשים כאלה שבועות מראש. תיעוד ההעברה של Google Workspace מפרט את המגבלות.
בדיקת עומק תיקיות: Exchange Online מגביל את עומק התיקיות ל-300 רמות. יש לשטח מבנים עמוקים יותר מראש כדי שלא ייחתכו בלי התראה.

3. הכנת DNS וכלל 300 השניות

הנמיכו את ערכי TTL של רשומות MX, SPF ו-DMARC ל-300 שניות, 48 שעות לפני המעבר.
הגדירו DMARC כ-p=none. אכיפת p=reject בזמן ההעברה מגדילה את הסיכון לחסימת דואר תקין אם הגדרות ההתאמה עדיין אינן שלמות.

להליך DNS מלא ראו כיצד להגדיר דוא״ל בדומיין.

שלב הסנכרון: העברת נתונים בלי לחרוג מהמגבלות

המטרה היא להעביר 90% מהנתונים בזמן שהמשתמשים ממשיכים לעבוד, בלי להפעיל את מגבלות הקצב של הספק. זהו השלב שבו מפעילים נוטים להמעיט במורכבות.

אסטרטגיית הכנה מוקדמת

סנכרון דואר ישן תחילה: הגדירו את כלי ההעברה, או את imapsync, להעביר תחילה פריטים שגילם עולה על 30 יום.
זכרו את מגבלות IMAP: לפי RFC 3501 (IMAP), הפרוטוקול מעביר דוא״ל בלבד. יומנים, אנשי קשר, משימות וכללים נשארים מאחור. ייצאו יומנים ל-.ics ואנשי קשר ל-.csv לצורך ארכיון מקומי.

טבלת מגבלות קצב

ספק	מגבלת IMAP יומית	גורם לחסימה
Google Workspace	~2,500 MB/account	חסימה ל-24 שעות (Error 429)
Microsoft 365	~20 GB/account	הגבלה זמנית
Generic cPanel	תלוי ברוחב הפס	משתנה לפי המארח

טיפול בשגיאות

HTTP 429/503: אלה אותות להאטה. הכלי צריך ליישם השהיה מעריכית, 5s ולאחר מכן 10s ואז 20s.
פריטים פגומים: הגדירו סף סובלנות, למשל 50 פריטים. עצירת העברה של 10 GB בגלל כותרת פגומה אחת בגודל 2 KB היא כשל תפעולי.

המעבר: ניתוב וסנכרון ההפרשים האחרון

בצעו את הפעולה בחלון תחזוקה מתוכנן. המהירות חשובה כאן וזהו החלק הרגיש ביותר לזמן ברשימה.

הקפאת השינויים

השביתו את גישת המשתמשים למערכת הישנה או אכפו הפסקת עבודה מוחלטת. לאחר מכן הפעילו את סנכרון ההפרשים האחרון כדי לאסוף דואר שהתקבל בזמן ההכנה.

אזהרת UIDVALIDITY: אם שרת המקור יצר מחדש את אינדקס התיקיות, הכלי עלול לנסות להוריד כפילויות. הפעילו תמיד הרצת ניסיון תחילה.

החלפת DNS

עדכנו את רשומות MX לספק החדש. גם עם TTL של 300s, זמן ההפצה בפועל תלוי במטמון ובסביבת DNS.
עדכנו SPF: הוסיפו את ה-include של הספק החדש, לדוגמה include:spf.trekmail.net. שימו לב למגבלת 10 שאילתות DNS לפי RFC 7208, ושטחו רשומות במידת הצורך.
פרסמו DKIM: מפתחות הבורר החדשים יתחילו לפעול לאחר הפרסום והפצתם ב-DNS.

אימות לאחר המעבר: רשימת הבדיקות להעברת דוא״ל

נראה תקין אינה שיטת אימות. אלה הדברים שצריך לבדוק בפועל.

מדד הזהב: מספר הפריטים

התעלמו מהגודל הכולל, כי הדחיסה משתנה בין ספקים. תיבת Gmail בגודל 10 GB עשויה להופיע כ-8 GB ביעד. במקום זאת השוו את מספר הפריטים בכל תיקייה.

פער	משמעות	פעולה
<1%	רגיל, כותרות פגומות	קביל, תעדו והמשיכו
1-5%	בעיה אפשרית במסנן	בדקו את מיפוי התיקיות
>5%	כשל מערכתי	בדקו עומק תיקיות והגדרות סינון

תיקון תוכנות הלקוח

פרופילים חדשים: אל תתקנו פרופילי Outlook ישנים. צרו פרופילים חדשים לקבלת קובץ .ost נקי.
חסמו חיבורים ישנים: חסמו את היציאות 993/443 בשרת הישן, אך חסמו את היציאה השנייה רק לאחר שווידאתם ששירותים אחרים אינם תלויים בה. אחרת מכשירים ניידים עלולים להתחבר שוב לשרת הישן וליצור סביבה מפוצלת.

טבלת עזר מהירה לפתרון תקלות

שגיאה	סיבה סבירה	תיקון
Google 11001/11002	אין גישה ל-IMAP במקור	בדקו חומת אש ו-DNS ואמתו סיסמת יישום
HTTP 429/503	הגבלת קצב	הפחיתו תהליכונים מ-10 ל-2 והמתינו 60 דקות
550 5.7.64	שיוך דייר או ממסר נדחה	ודאו שאישור TLS תואם ל-FQDN של המחבר
IMCEAEX bounce	Legacy Exchange DN חסר	הוסיפו כתובת X.500 כ-proxy למשתמש החדש

TrekMail מטפל בחלקים הקשים של רשימת ההעברה

הרשימה הידנית שלמעלה דורשת סקריפטים של PowerShell, מעקב אחר הפצת DNS וניהול מגבלות קצב. TrekMail מתייחס להעברה כתשתית ולא כפרויקט ייעוץ.

לעסקים קטנים

TrekMail כולל מנגנון מובנה להעברת IMAP. הזינו את פרטי הגישה הישנים ל-Gmail, cPanel או Exchange, והמערכת תטפל אוטומטית בסנכרון דואר ותיקיות נתמכים, במיפוי ובניסיונות חוזרים. עדיין נדרשת השוואה סופית למקור. אין צורך בסקריפטים או בשורת פקודה.

קראו על אחסון דוא״ל לעסקים שנבנה לצוותים שאינם רוצים לנהל תשתית.

לסוכנויות

במקום לנהל 50 מכסות אחסון, TrekMail מציע מאגר אחסון משותף לכל הדומיינים של הלקוחות. SMTP מנוהל מטפל במוניטין המסירה, כך שאפשר לדלג על חימום כתובת IP.

חבילה	מחיר	מנגנון העברה	SMTP מנוהל
Free	$0 (no card)	כלול	שירות עצמאי בלבד
Starter	$3.50/mo	כלול	כלול
Pro	$10/mo	כלול	כלול
Agency	$23.25/mo	כלול + כלים לפעולות מרובות	כלול + ניהול מוניטין

כל החבילות בתשלום כוללות תקופת ניסיון של 14 יום ודורשות כרטיס. לחבילת Nano אין צורך בכרטיס.

סיכום

רשימת בדיקות להעברת דוא״ל אינה נועדה להיות יסודית לשם היסודיות. כל סעיף קשור לכשל ממשי שמפעילי מערכת כבר חוו. מפו אובייקטים נסתרים, הכינו מראש תיבות כבדות, הנמיכו TTL, הפעילו סנכרון הפרשים ואמתו לפי מספר פריטים ולא לפי תחושת בטן.

מוכנים לסמן את כל הסעיפים? פתחו חשבון TrekMail בחינם ותנו למנגנון ההעברה המובנה לטפל בתשתית.

רשימת בדיקות להעברת דוא״ל מהכנה ועד אימות (2026)