העברת תיבת דואר לספק חדש: מדריך מעבר DNS
כשמעבירים נתוני תיבה בין ספקי דוא״ל, אסטרטגיית ה-DNS היא שעשויה להבדיל בין מעבר נקי לבין השבתה של 48 שעות. TTL שגוי אחד או include שנשכח ב-SPF עלולים לגרום להחזרות קבועות ולאובדן עסקי.
זה אינו תרגיל יצירתי אלא רצף פעולות טכניות מדויקות. המדריך מסביר כיצד להעביר תוכן תיבה בבטחה באמצעות ניהול זמני הפצה, שילוב זהויות SPF, DKIM ו-DMARC וניתוב לספק החדש תוך צמצום הסיכון לאובדן הודעות.
להעברת הנתונים עצמם, כלומר העברת ההודעות, ראו את המדריך המלא לסנכרון IMAP.
מדוע הפצת DNS אינה מיידית בעת העברת תיבה
DNS הוא מערך מטמון מבוזר. לאחר שינוי רשומה תלויים בכל פותר רקורסיבי, משרתי ה-DNS של ספק האינטרנט ו-8.8.8.8 של Google ועד נתבים מקומיים, ובאופן שבו הוא מכבד את ערך Time-To-Live (TTL).
אם ה-TTL נשאר בערך הרגיל של 86,400 שניות (24 שעות), הניתוב עלול להתפצל למשך יום. חלק מהדואר יגיע לתיבה החדשה וחלק לישנה.
הזנב הארוך ומטמון שלילי
שני גורמים נסתרים משבשים מעברים באופן קבוע:
- הזנב הארוך: גם עם TTL נמוך, כ-1-5% מהפותרים בעולם מתעלמים מערכים שמתחת ל-60 דקות. יש לצפות לתעבורה שאריתית לספק הישן במשך כשעה לאחר המעבר.
- מטמון שלילי (SOA): אם בודקים רשומה לפני שהיא קיימת, למשל בורר DKIM חדש, תשובת NXDOMAIN נשמרת לפי ערך ה-TTL המזערי ברשומת SOA, לרוב 1 שעה. לכן הרשומה התקינה עלולה להישאר מוסתרת זמן מה גם לאחר פרסומה.
שלב 1: הספירה לאחור של 48 שעות
אל תשנו עדיין את רשומות MX. תחילה הכינו את הסביבה לקבלת השינוי.
צעד 1: הורדת TTL, 48 שעות לפני המעבר
אתרו את רשומות MX, SPF (TXT) ו-DMARC. הורידו את ה-TTL שלהן ל-300 שניות (5 דקות).
הפעולה מקצרת את חלון ההפצה הצפוי שעשוי להגיע ל-24 שעות, אך אינה מבטיחה שכל הפותרים יתעדכנו בתוך 5 דקות.
dig yourdomain.com MX
# Look for 300 in the TTL column
צעד 2: שילוב SPF, 24 שעות לפני המעבר
SPF (RFC 7208) מאשר לכתובות IP לשלוח בשם הדומיין. בזמן המעבר יש לאשר את שני הספקים במקביל.
המלכודת: SPF מוגבל ל-10 שאילתות DNS. שילוב שני ספקים, לדוגמה Google Workspace ו-TrekMail, עלול לחרוג מהמגבלה.
הפתרון: החליפו הצהרות include: מקוננות במנגנוני ip4: ישירים רק באמצעות פתרון נתמך ששומר את הכתובות מעודכנות. אחרת כתובות IP עלולות להתיישן.
דוגמה לרשומת מעבר:
v=spf1 include:_spf.google.com include:spf.trekmail.net -all
אם אתם משתמשים ב-BYO SMTP של TrekMail דרך Amazon SES או SendGrid, כללו את רשומות SPF שלהם במקום זאת.
צעד 3: פרסום מוקדם של DKIM
DKIM משתמש בבוררים, לדוגמה google._domainkey. צרו אצל הספק החדש מפתחות עם בורר ייחודי, לדוגמה tm1._domainkey. אין לעשות שימוש חוזר בשם בורר. אפשר לפרסם בורר חדש ימים מראש בלי להתנגש בספק הישן.
צעד 4: הקלה זמנית ב-DMARC
אם מדיניות DMARC היא p=reject או p=quarantine, שנו אותה ל-p=none לפחות 24 שעות לפני המעבר. בשעות הראשונות עלולים להתרחש כשלי אימות. p=none מתעד אותם בדוחות RUA ואינו דוחה אותם מכוח DMARC, אך אינו מבטיח מעבר של מסנני מסירה אחרים. מדריך הגדרת DMARC של Google מסביר את ההגדרה.
שלב 2: ביצוע המעבר
ה-TTL נמוך וזהויות האימות שולבו. כעת אפשר להעביר את ניתוב התיבה למארח החדש.
צעד 1: השוואת שרת סמכותי לפותר רקורסיבי
בדקו שהרשומות החדשות מופיעות בשרת השמות הסמכותי לפני שבודקים אותן בעולם:
# Check authoritative nameserver
dig @ns1.provider.com yourdomain.com MX
# Check public recursive resolver
dig @8.8.8.8 yourdomain.com MX
צעד 2: עדכון רשומות MX
אם אפשר, הוסיפו ואמתו את רשומות MX החדשות לפני הסרת הישנות, או החליפו אותן בשינוי אחד. משתמשי TrekMail צריכים:
10 mx1.trekmail.net
20 mx2.trekmail.net
השאירו את ה-TTL על 300 שניות. אל תעלו אותו עדיין.
צעד 3: ניקוי ואימות
נקו את מטמון ה-DNS המקומי באמצעות ipconfig /flushdns ב-Windows או sudo dscacheutil -flushcache ב-macOS. הפעילו שוב dig. הפעולה מנקה רק את המטמון המקומי ואינה מזרזת עדכון של פותרים חיצוניים.
שלב 3: התייצבות לאחר המעבר
מעקב אחר שגיאות שיוך דייר (550 5.7.64)
זהו כשל נפוץ בהעברה ל-Microsoft 365 ולחבילות דומות. אם הדומיין טרם הוגדר במלואו בספרייה הפנימית של היעד, הוא עלול לדחות דואר עם Relay Access Denied. ודאו לפני החלפת MX שמצב הדומיין אצל הספק החדש הוא Verified או Healthy.
מעקב אחר דוחות DMARC במשך 72 שעות
עקבו אחר דוחות RUA במשך שלושה ימים:
- הצלחה: תעבורה מכתובות ה-IP של הספק החדש עוברת SPF ו-DKIM.
- כשל: תעבורה תקינה ממערכות חיוב או שיווק נכשלת באימות. עדכנו מיד SPF או DKIM.
ניקוי, 72 שעות לאחר המעבר
לאחר שהתעבורה מתייצבת:
- הסירו את
include:של הספק הישן מ-SPF רק לאחר שווידאתם שהוא אינו שולח עוד. - הסירו רשומות DKIM ישנות מסוג CNAME/TXT לאחר חלון בטוח לאימות הודעות שנחתמו קודם.
- העלו את TTL בחזרה ל-3,600s (1 שעה) או 86,400s (24 שעות).
- אכפו מחדש DMARC באמצעות
p=quarantineאוp=reject.
רשימת העברת התיבה במבט מהיר
| תזמון | פעולה | סוג רשומה |
|---|---|---|
| T-48h | הורדת TTL ל-300s | MX, SPF, DMARC |
| T-24h | שילוב SPF ואישור שני הספקים | TXT |
| T-24h | פרסום מוקדם של בורר DKIM חדש | CNAME/TXT |
| T-24h | הקלה ב-DMARC ל-p=none | TXT |
| T-0 | העברת ניתוב התיבה באמצעות MX | MX |
| T-0 | שמירת שני הספקים ב-SPF עד שהישן מפסיק לשלוח | TXT |
| T+72h | ניקוי DNS ישן בבטחה ואכיפת DMARC | הכול |
TrekMail מפשט את תהליך העברת התיבה
ניהול DNS ידני מועד לשגיאות. שגיאת תחביר אחת ברשומת TXT עלולה לפסול את מדיניות SPF כולה.
לעסקים קטנים
TrekMail מספק בדיקת תקינות DNS בזמן אמת. לוח הבקרה פונה לשרתי השמות הסמכותיים ומאמת MX, SPF ורשומות DKIM מול דרישות הבסיס. הוא יכול לסמן שגיאות תחביר לפני שהן גורמות להחזרות, אך אינו מבטיח שההפצה הסתיימה אצל כל פותר חיצוני.
קראו עוד על הגדרת דוא״ל בדומיין שלכם.
לסוכנויות
ניהול של 50+ דומיינים דורש אחידות. TrekMail מאפשר להחיל תבנית DNS עקבית על סביבות הלקוחות. בחבילות Starter ו-Agency, Managed SMTP מטפל במוניטין IP ובכותרות מסירה, ולכן במסלול זה אין צורך בשיטוח SPF מורכב או בלוח חימום IP עצמאי.
ראו כיצד אחסון דוא״ל למספר דומיינים עובד לסוכנויות.
| חבילה | מחיר | בדיקת תקינות DNS | Managed SMTP |
|---|---|---|---|
| Free | $0 (no card) | כן | שירות עצמאי בלבד |
| Starter | $3.50/mo | כן | כלול |
| Pro | $10/mo | כן | כלול |
| Agency | $23.25/mo | כן | כלול + ניהול מוניטין IP |
כל החבילות בתשלום כוללות ניסיון חינם ל-14 יום ודורשות כרטיס. חבילת Nano אינה דורשת כרטיס.
סיכום
כשמעבירים נתוני תיבה לספק חדש, התקלות נוטות להתרחש במעבר ה-DNS. הנמיכו TTL מראש, שלבו את רשומות האימות, החליפו MX בחלון תחזוקה ועקבו אחר דוחות DMARC במשך 72 שעות. זהו מתווה העבודה.
אם תעדיפו לוותר על ניהול DNS ידני, נסו את TrekMail בחינם ותנו ללוח הבקרה לבדוק את ההגדרות.
