העברת אחסון דואר לדומיין: בדיקות DNS

אפשר להעביר אחסון דואר לדומיין ולשמור כתובות אחרי יצירת התיבות והכינויים ביעד. שינוי DNS שגוי עלול לפגוע בזרימה. העתקת הודעות והמעבר ב-DNS הן משימות נפרדות; תיאום לקוי יכול ליצור דחייה או קבלה בשתי מערכות.

לתכנון המלא קראו תחילה דואר עסקי. כאן מדובר באחסון דומיין שבבעלותכם ובניהולכם, לא בהעברת רישום הדומיין לרשם אחר או כתובת אישית של ספק. נבדוק MX, SPF, DKIM ו-DMARC בזמן שהמקור עדיין בשימוש.

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

מה פירוש העברת אחסון דואר לדומיין?

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

בדרך כלל מדובר בשלוש משימות:

1. העתקת נתונים לתיבות יעד שכבר נוצרו; ההכנה בסעיף הבא חייבת להתבצע לפני ההעתקה בפועל.
2. יצירה ובדיקה של התיבות, הכינויים וההעברות ביעד.
3. החלפת DNS לקבלה אצל הספק החדש בדומיין המנוהל.

שנו MX רק לאחר הכנת היעד ובדיקת ההעתקה. אחרת דואר עלול להידחות או להגיע למקום הלא נכון. SPF או DKIM חסרים משפיעים על אימות, אך המקבל קובע טיפול ולא כל הודעה נדחית או מגיעה לספאם.

חלקו להכנה, מעבר והתייצבות. TrekMail מתארת ייבוא IMAP מ-Gmail, Outlook, Yahoo, iCloud ומקורות אחרים במסלולי Starter ומעלה. בדקו תמיכה וגישה מותרת כיום. כלי הייבוא הישיר אינו OAuth אינטראקטיבי; סיסמת אפליקציה תלויה באימות ובמדיניות הספק וייתכן שצריך כלי נתמך אחר. IMAP מעתיק דואר נתמך, לא אנשי קשר, יומנים או כללי חשבון. ראו תהליך מפורט ב-imapsync.

שלב 1: הכינו את המעבר 24-48 שעות מראש

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

1. הפחיתו TTL ברשומות הדואר

אפשר לשקול 300 שניות אם הספק מאפשר. טווח 24-48 שעות הוא המחשה; התייחסו ל-TTL הישן ולמטמונים בפועל. שינוי חמש דקות קודם אינו מוחק תשובות שכבר נשמרו.

dig example.com MX

dig example.com TXT

dig example.com TXT _dmarc.example.com

אם ה-TTL הישן היה 3600 או 86400, תשובה יכולה להישאר עד פקיעת תוקפה. התחילו מוקדם ולא ביום שישי ב-4:55 PM. הפקודה האחרונה אינה שאילתת DMARC נפרדת אמינה, ו-TXT בדומיין הראשי אינו בודק את בוררי DKIM. בדקו שמות נכונים בנפרד בשרתי DNS סמכותיים ובפותרי שמות רלוונטיים.

2. העתיקו הודעות לפני שינוי MX

הפעילו IMAP כשהמקור עדיין זמין. הכלי המתואר של TrekMail מעתיק ברקע לתיבה קיימת ביעד. בדקו כניסה, מכסה והעתקת ניסיון לפני הרחבה.

הוסיפו דומיין בלי לשנות קבלה מוקדם, צרו יעד ועקבו אחרי תחילת ייבוא בלוח הבקרה. TrekMail מתוארת כ-IMAP ללא POP3. POP אינו פוגע ברציפות בהכרח, אך הודעות מקומיות אולי אינן בשרת; גבו אותן בנפרד מראש.

3. הכינו את כל זהויות היעד

צרו תיבות, כינויים, העברות ו-catch-all לפני המעבר. בדקו אישור בעלים, מדיניות וניתוב בפועל גם לכתובות נדירות.

לדוגמה: billing@, support@, careers@, noreply@, תיבת catch-all והעברה ישנה לחשבון Gmail של המייסד. חוסר באחד מהם עשוי להתגלות רק כשהודעה מגיעה אליו.

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

4. מזגו שירותי SPF לפני המעבר

מערכות ישנות יכולות להמשיך לשלוח תשובות או אוטומציות לגיטימיות. שמרו הרשאה לשירותים שפועלים בזהות שנבדקת. לפי RFC 7208, תקציב 10 חל על מנגנונים ומשנים שגורמים ל-DNS ונבדקים בפועל, כולל הערכה מקוננת, לא על כל חבילות הרשת או תשובות מטמון.

v=spf1 include:_spf.google.com include:spf.trekmail.net -all

התאימו את הדוגמה לספקים בפועל, בלי להרשות Google כשאינו בשימוש לגיטימי. Free מתואר עם SMTP חיצוני ומסלולים בתשלום עם SMTP מנוהל; בדקו מסלול ותנאים כיום. פרסמו מדיניות SPF אחת לכל שם, לצד TXT אחר שאינו SPF אם נדרש.

5. פרסמו DKIM ובחנו DMARC

בחרו בורר חדש ופרסמו מפתח לפני שהמערכת החדשה חותמת. אל תחליפו בורר ישן כל עוד המקור חותם. מעבר זמני ל-p=none הוא בחירת סיכון באישור בעלים בלבד; אפשר לשמור אכיפה כשאימות ויישור נכונים. מדיניות ניטור אינה מבטיחה קבלה או אפס סיכון.

גם תשובה שבורר חסר יכולה להישמר במטמון שלילי לפי כללי SOA של RFC 2308. פרסמו מוקדם ובדקו תשובות. הפחתת TTL של רשומה אחרת אינה מוחקת את המטמון הזה.

שלב 2: מעבר הקבלה לספק החדש

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

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

1. ודאו מוכנות של הספק

בדקו מצב דומיין ואימות שאפשר לפרסם לפני MX. Active וסימונים ירוקים אינם בדיקת דואר מלאה ולא תמיד אפשר להשלים את כולם לפני המעבר. ראו הוספת דומיין ל-TrekMail. התיאור ממרץ 2026 כולל דוגמה זו; אמתו ערכי חשבון ומדיניות עדכניים:

MX   @              mail.trekmail.net.   priority 10
TXT  @              v=spf1 include:spf.trekmail.net -all
TXT  dkim._domainkey  [unique value from dashboard]
TXT  _dmarc         v=DMARC1; p=quarantine;

החליפו MX ישן של Google Workspace, Microsoft 365, Zoho, cPanel או הרשם במעבר המתוכנן. MX מעורב פועל בעדיפות ובגיבוי, לא בחלוקה שווה קבועה; אם שני השרתים מקבלים, הודעות יכולות להגיע למערכות שונות.

2. החליפו MX ושמרו TTL נמוך זמנית

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

dig @8.8.8.8 example.com MX

dig @1.1.1.1 example.com MX

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

3. בדקו תוכנות IMAP

אמתו הגדרות עדכניות: IMAP imap.trekmail.net ביציאה 993 עם TLS, ו-SMTP smtp.trekmail.net ב-465 עם TLS מרגע יצירת החיבור או 587 עם STARTTLS. בדקו שרשרת תעודות, שם שרת, כתובת תיבה מלאה וסיסמת תיבה ולא לוח בקרה. ראו הגדרות IMAP ו-SMTP לתוכנות.

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

שלב 3: מעקב ב-72 השעות הראשונות

72 השעות הראשונות הן דוגמת תצפית ולא מועד סיום. עקבו אחרי קבלה, אימות ונתיבים ישנים; סנכרנו שוב הודעות מאוחרות עם תאריך ישן, העברות בין תיקיות ודגלים נתמכים. שמרו קבלת SMTP בשרת הישן, סנכרון ניהולי וחזרה עד סיום שנבדק.

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

1. חפשו שימוש בספק הישן

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

2. בדקו אימות ויישור

קבלת שרת אינה הוכחת אימות או מיקום בתיבת דואר נכנס. בדקו תוצאות קבלה מהימנות. SPF יכול להיכשל בהעברה, אך DMARC יכול לעבור עם חתימת DKIM תקינה ומיושרת ל-From הגלוי או עם SPF שעובר ומיושר.

להעברה חיצונית שנותרה ראו העברת דואר דומיין ל-Gmail ובדקו את השפעות המסלול.

3. הסירו חפיפה רק לאחר בדיקה

הסירו SPF ישן רק כשהשירות אינו שולח לגיטימי עוד. שמרו רשומות DKIM ישנות כל עוד הודעות בתור, בדרך או שהועברו אוטומטית עשויות להזדקק למפתחות הציבוריים לאימות. אחרי התייצבות אפשר לשקול TTL של 3600. אם נבחר p=none זמני, בחנו אכיפה מחדש עם מיפוי, בדיקות וחזרה.

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

שיטה מסורתית לעומת שיטה מבוקרת

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

TrekMail מתארת דומיינים בבעלותכם, IMAP, catch-all, SMTP חיצוני ב-Nano או כלול במסלולים בתשלום, העברה, כלי ייבוא ו-API. מחיר Starter המתואר מתחיל ב-$3.50 לחודש, לצד Free, Starter, Pro, Agency ו-Enterprise. בדקו תכונות, מגבלות ותנאים כיום ב-מחירי TrekMail; מודל מסלולים אינו מבטיח הרחבה ללא מגבלות.

רשימת בדיקות סופית להעברת דואר הדומיין

צרו יעד, הפחיתו TTL, העתיקו נתונים, מזגו SPF ופרסמו DKIM. בחנו DMARC, שנו MX כשצריך ובדקו דואר בפועל. נקו אחרי אימות וסנכרון שינויים שנותרו.

1. תכננו 24-48 שעות כדוגמה, עם תוקף המטמון הישן.
2. העתיקו IMAP לתיבות שכבר נוצרו ונבדקו.
3. הכינו ובדקו תיבות, כינויים, העברות ו-catch-all לפני המעבר.
4. מזגו שירותים פעילים למדיניות SPF אחת לכל שם.
5. פרסמו בורר DKIM חדש ובדקו חתימה.
6. בחרו p=none זמני רק באישור ובהתאם לסיכון; אין חובה להקל אוטומטית.
7. בדקו מצב דומיין וקבלה ושליחה אמיתיות.
8. החליפו MX פעיל בדומיין המנוהל במעבר המתוכנן.
9. שלחו ניסיונות פנימה והחוצה וחזרו על סנכרון שינויים.
10. אחרי 72 שעות בחנו התקדמות, אך הסירו אימות או החמירו מדיניות רק אם הבדיקות תומכות בכך.

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