רשומות MX: כיצד דואר אלקטרוני מוצא את השרת שלך

כל משלוח דואר אלקטרוני מתחיל בשאלה: מי מקבל דואר עבור הדומיין הזה?

כאשר אתה שולח מייל אל someone@example.com, שרת הדואר שלך לא יודע מאליו לאן example.com מקבל את הדואר שלו. הוא שואל. ליתר דיוק, הוא שולח שאילתה ל-DNS לקבלת רשומות MX (Mail Exchanger) — רשומות ה-DNS שעונות על השאלה "מי מדבר בשם הדומיין הזה בכל הנוגע לדואר אלקטרוני?"

התשובה מגיעה בצורת שם מארח: "שלח דואר עבור example.com אל mail.example.com." לאחר מכן, השרת שלך מחפש את כתובת ה-IP של שם המארח הזה ומעביר את ההודעה.

מדוע שמות מארח ולא כתובות IP

שים לב לתהליך הדו-שלבי: רשומת MX מצביעה על שם מארח, ושם המארח מצביע על כתובת IP. זה נראה כמנגנון עקיף מיותר — עד שאתה צריך לשנות שרתי דואר.

אם רשומות MX היו מצביעות ישירות על כתובות IP, מעבר לשרת דואר חדש היה מחייב עדכון רשומות MX לכל דומיין שאתה מארח — ולאחר מכן המתנה לפקיעת המטמונים של DNS ברחבי העולם. במקום זאת, אתה מעדכן רשומת A אחת בלבד עבור שם המארח של שרת הדואר שלך, וכל דומיין המשתמש בשם המארח הזה מצביע מיידית על ה-IP החדש.

מנגנון עקיף זה נדרש על פי RFC 5321, מפרט SMTP. רשומות MX חייבות להצביע על שמות מארח, לעולם לא ישירות על כתובות IP. שרתי דואר רבים ידחו דואר מדומיינים המפרים כלל זה.

עדיפות: מעבר אוטומטי לגיבוי

רשומות MX כוללות ערך עדיפות — מספר הקובע איזה שרת לנסות ראשון:

example.com.  IN  MX  10  mail.example.com.
example.com.  IN  MX  20  backup.example.com.

מספרים נמוכים יותר פירושם עדיפות גבוהה יותר. כאשר מגיע דואר עבור example.com, שרת השולח מנסה את mail.example.com (עדיפות 10) ראשון. רק אם השרת הזה אינו נגיש, הוא עובר ל-backup.example.com (עדיפות 20).

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

פיזור עומס

מה קורה כאשר שתי רשומות MX חולקות את אותה עדיפות?

example.com.  IN  MX  10  mail1.example.com.
example.com.  IN  MX  10  mail2.example.com.

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

שלב דפוסים אלה לקונפיגורציות מתוחכמות:

example.com.  IN  MX  10  mail1.example.com.
example.com.  IN  MX  10  mail2.example.com.
example.com.  IN  MX  20  backup.example.com.

איזון עומסים בין mail1 ל-mail2 בפעילות רגילה, ומעבר לגיבוי אם שניהם אינם זמינים.

תצורות דואר ענן

Google Workspace ו-Microsoft 365 חושפים שתי פילוסופיות של יתירות.

Google Workspace:

example.com.  IN  MX  1   aspmx.l.google.com.
example.com.  IN  MX  5   alt1.aspmx.l.google.com.
example.com.  IN  MX  5   alt2.aspmx.l.google.com.
example.com.  IN  MX  10  alt3.aspmx.l.google.com.
example.com.  IN  MX  10  alt4.aspmx.l.google.com.

ראשי אחד (עדיפות 1), שני חלופות לפיזור עומס (עדיפות 5), ועוד שניים למעבר אוטומטי עמוק יותר (עדיפות 10). חמש שכבות של יתירות, גלויות ב-DNS.

Microsoft 365:

example.com.  IN  MX  10  example-com.mail.protection.outlook.com.

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

אבחון בעיות MX

כאשר דואר אלקטרוני אינו מגיע, רשומות MX הן הדבר הראשון לבדוק:

dig example.com MX

בעיות נפוצות:

• אין רשומות MX כלל. לדואר אין לאן ללכת.
• עדיפויות הפוכות. לשרת הגיבוי יש מספר נמוך יותר מהראשי, ולכן הוא מקבל את כל התעבורה.
• MX מצביע על CNAME. RFC 5321 אוסר על כך. שרתים מסוימים מתירים זאת; אחרים ידחו את הדואר שלך.
• MX מצביע ישירות על IP. מפר את מפרט SMTP. שרתים רבים ידחו את הדואר שלך.

בעיית התיאום

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

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

רשומות ה-MX של הדומיין שלך הן הצהרה פומבית כיצד להגיע אליך. כל שרת דואר בעולם יכול למצוא אותן, לסמוך עליהן ולפעול לפיהן.

שאלות נפוצות על רשומות MX

האם ניתן לקבל דואר אלקטרוני ללא רשומות MX?

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

כמה זמן לוקח להפצת שינויים ברשומות MX?

זה תלוי ב-TTL (time-to-live) של הרשומות הקיימות שלך. אם לרשומות ה-MX שלך יש TTL של 3600 שניות (שעה אחת), שרתים שמטמנו את הרשומות הישנות ישתמשו בהן עד שעה. לפני מעבר, הורד את ה-TTL שלך מבעוד מועד.

אילו ערכי עדיפות כדאי להשתמש?

המספרים עצמם אינם חשובים — רק הערכים היחסיים שלהם. עדיפות 10/20 פועלת אותו הדבר כמו 1/2 או 100/200. נהוג להשתמש בכפולות של 10 (10, 20, 30) כדי להשאיר מקום להוספת עדיפויות ביניים בהמשך.

מדוע רשומות MX מצביעות על שמות מארח ולא על כתובות IP?

גמישות ועמידה בפרוטוקול. שמות מארח יכולים להתפרש לכתובות IPv4 ו-IPv6 כאחד, ניתן לעדכן אותם מבלי לשנות רשומות MX, והם מאפשרים למטמון DNS לפעול ביעילות. RFC 5321 דורש שמות מארח, ושרתי דואר רבים אוכפים זאת.

מקורות