רוב החברות מחזיקות יותר דומיינים מכפי שהן משתמשות בהם. יש מותג שנרכש ולא הועבר, שגיאת כתיב נפוצה שנרכשה להגנה, דומיין קמפיין מלפני שנתיים וגרסת מדינה שמישהו רשם כי הייתה זולה.
אף אחד מהם אינו זקוק לתיבות, אך כולם מקבלים דואר: לקוח שהקליד את שם המותג הישן, ספק שמשתמש בכתובת מלפני הרכישה או מערכת אוטומטית שלא עודכנה. כיום הדואר הזה כנראה מוחזר ואיש אינו יודע מה היקפו.
catch-all חיצוני מטפל בכך בלי להקצות דבר: הוא מפנה את כל הדומיין לכתובת שאתם כבר קוראים. אין תיבה, אחסון, עלות למשתמש או סיסמה. יש פשרות אמיתיות שכדאי להכיר לפני ההפעלה.
שלוש דרכים לטפל בכתובת
| מנגנון | מה קיים | אחסון | אפשר לשלוח בשמו |
|---|---|---|---|
| תיבת דואר | אחסון אמיתי וכניסה משלה | כן, מכסה משלה | כן |
| כינוי | כתובת נוספת בתיבה קיימת | לא, חולק את אחסון היעד | כן, אם שליחה מופעלת |
| ניתוב catch-all | דבר אינו קיים, רק כלל ברמת הדומיין | אין | לא |
רק ב-catch-all אף כתובת אינה מוגדרת. כל חלק מקומי בדומיין, sales@, john@, qwerty@, מתקבל ונמסר ליעד. זהו היתרון והחיסרון באותו משפט.
מה עושה catch-all חיצוני
היעד יכול להיות תיבה באותו דומיין או כתובת במקום אחר: כתובת העבודה, תיבת צוות משותפת בדומיין הראשי או תור תמיכה. המקרה השני הוא catch-all חיצוני.
כך הוא שימושי לדומיינים שבבעלותכם אך אינם מאוישים. אין צורך להקצות דבר בדומיין החונה. הוסיפו אותו, הפנו MX אלינו והגדירו יעד. דואר שהיה מוחזר מגיע למי שקורא אותו.
יש שתי מגבלות, ולשתיהן סיבות טובות.
יעד באותו דומיין חייב להיות תיבה פעילה. הפניה לכתובת שאינה תיבה אמיתית מחזירה את ניסיון המסירה לאותו כלל, מעגל שמייצר דואר עד שכשל מתרחש. לכן הכלל נדחה.
catch-all חיצוני דורש Pro או Agency. ניתוב החוצה פירושו קבלת דואר בשמכם ושליחתו מחדש לצד שלישי. זו פעולת שליחה בעלת השלכות מוניטין, ולכן מוגבלת למסלולים הכוללים שליחה.
מתי catch-all חיצוני מתאים בדיוק
דומיינים חונים והגנתיים. acme-inc.com כשאתם מפעילים את acme.com. אין סיבה שמישהו יחזיק שם תיבה, ויש סיבה לא להחזיר דואר שמגיע.
מותג שנרכש. דואר ממשיך להגיע לכתובות החברה הישנה במשך שנים. הכלל מפנה את כולו למי שמנהל כעת את הקשר, ללא העברת תיבות או ניחוש אילו כתובות שימשו.
דומיינים ששולחים בלבד. דומיין קמפיינים או עסקאות שולח ללא נמענים אנושיים, אך צריך לקבל תשובות והחזרות. השלכה שקטה מסתירה הודעות מחוץ למשרד, תלונות ולקוח שלחץ על השב.
בירור מה דומיין ישן מקבל. נתבו אותו לתיקייה למשך חודש וקראו את היומן. לעיתים התשובה היא "שתי הודעות אמיתיות והרבה רעש", וכך אפשר להחליט אם לבנות פתרון או להשאיר את הכלל.
מה עולה catch-all חיצוני
הוא מקבל הכול, ולכך השלכות שמופיעות באיחור.
מתקפות איסוף כתובות מפסיקות להיכשל. כלי ספאם בודקים רשימות כמו info@, admin@, a@, ab@. בלי catch-all, כתובות פסולות נדחות בזול בשיחת SMTP. איתו כל אחת מתקבלת, ולכן בדיקה שהייתה אמורה לעלות אפס עולה הודעה מלאה.
הנפח אינו מוגבל ואינו צפוי. כשידוע שהדומיין מקבל הכול, רשימת הכתובות מסתובבת. המגמה אינה הדרגתית; ייתכנו חודשים שקטים ואז עומס רב.
הדומיין אינו ניתן לאימות. כל בודק מקבל "כן" לכל כתובת. שירותי אימות רואים accept-all ומכניסים גם כתובות אמיתיות לקבוצת סיכון. ראו מה בדיקות אימות באמת מוכיחות.
שגיאות כתיב נמסרות בשקט. בלי catch-all, דואר אל jhon@ חוזר והשולח מתקן. איתו הוא מגיע למאגר והשולח מניח שהגיע ל-John. לפעמים איש אינו מבחין במשך שבועות.
הדיון הכללי נמצא באופן הפעולה של דואר catch-all. בקצרה: הוא מתאים לדומיין שאיש אינו עובד בו ופחות מתאים לדומיין מאויש.
בעיית האימות של catch-all חיצוני
catch-all חיצוני הוא העברה, והעברה שוברת אימות SPF. ההודעה שומרת את השולח המקורי אך מגיעה מהשרתים שלנו, שלא אושרו ברשומת SPF שלו.
Sender Rewriting Scheme מתקן אוטומטית את צד SPF באמצעות שינוי envelope sender לדומיין שמאשר אותנו. הוא מופעל ללא הגדרה. הוא אינו יכול לתקן חתימת DKIM שנשברה בדרך ואינו עוזר כשהדומיין המקורי מפרסם p=reject והמקבל מחמיר.
מעשית, חלק מהדואר שמנותב ל-Gmail עלול להגיע לספאם, במיוחד הודעות מדומיינים עם המדיניות המחמירה ביותר, שלעיתים הן לגיטימיות. בדקו את תיקיית הספאם ביעד בשבועיים הראשונים. ראו SRS ודואר מועבר.
מתי כינויים עדיפים
בדומיין שאנשים עובדים בו, כינויים עדיפים על catch-all חיצוני בכל היבט.
רוב הארגונים משתמשים בפחות מעשר כתובות אמיתיות: info@, sales@, support@, billing@ וכמה שמות. הגדרתן במפורש דוחה את היתר בשיחת SMTP ללא עלות, חוסמת איסוף ומחזירה טעות כדי שהשולח יתקן.
כינויים גם מאפשרים לשלוח מתוך כינוי, כך שתשובה ל-billing@ מגיעה מ-billing@ ולא מהכתובת האישית. אפשר לנתב כינויים שונים לתיבות שונות. הכינוי מוסר לתיבה אמיתית, ולכן אפשר לחפש, לסנן ולגבות.
ההחלטה היא שאלה אחת: האם מישהו עובד בדומיין? אם כן, כינויים. אם לא, catch-all חיצוני. ראו כינויים לעומת תיבות.
הגדרת catch-all חיצוני
- הוסיפו את הדומיין והשלימו DNS כך ש-MX יפנה אלינו. בלי MX, הדואר עדיין מגיע ליעד הקודם.
- פתחו את הכרטיסייה ניתוב של הדומיין.
- הפעילו catch-all והזינו את כתובת היעד.
- שמרו. השינוי חל מיד ללא עיכוב הפצה בצד שלנו.
לאחר מכן עשו את השלב שמדלגים עליו: שלחו הודעת בדיקה לכתובת חסרת משמעות בדומיין ואשרו שהגיעה. זו הדרך היחידה לדעת שהכלל פעיל ולא רק נשמר, והיא אורכת שלושים שניות.
אם אתם מנתבים לתיבה שנקראת בפועל, הוסיפו מסנן שמעביר דואר catch-all לתיקייה משלו. אחרת הנפח מציף את התיבה והגדרה הגיונית נכבית בתסכול כעבור שלושה שבועות. מסננים בצד השרת עושים זאת בעת המסירה לפני שהדבר מגיע לטלפון.
שאלות נפוצות
האם דרושה תיבה בדומיין לשימוש ב-catch-all חיצוני?
לא כשהיעד חיצוני. זו המטרה בדומיין חונה: דבר אינו מוקצה. אם היעד באותו דומיין, הוא חייב להיות תיבה פעילה כדי למנוע מעגל.
האם דואר catch-all משתמש באחסון שלי?
ניתוב לכתובת חיצונית אינו משתמש בו. ניתוב לתיבה שלכם מאחסן בה את הדואר על חשבון המכסה שלה.
האם אפשר להשיב מכתובת catch-all?
לא. catch-all אינו מגדיר כתובות, ולכן אין כתובת לשלוח בשמה. התשובות מגיעות מהתיבה שקיבלה. צרו כינוי אם נדרשת שליחה מכתובת מסוימת.
מדוע catch-all חיצוני מוגבל ל-Pro ול-Agency?
ניתוב החוצה מחייב שליחה מחדש בשמכם, פעולה בעלת השלכות מוניטין. הוא זמין במסלולים הכוללים שליחה.
האם דואר catch-all חיצוני יגיע לספאם?
חלקו עשוי להגיע. העברה שוברת את אישור SPF המקורי; SRS מתקן זאת אוטומטית, אך איש אינו יכול לתקן DKIM שנשבר בדרך. בדקו ספאם בשבועיים הראשונים.
איך עוצרים את ההצפה כשהיא מתחילה?
כבו catch-all והגדירו כינויים מפורשים לכתובות שהתבררו כאמיתיות. בינתיים סננו את המאגר לתיקייה משלו.
האם אפשר להגדיר catch-all חיצוני דרך API?
כן, ההגדרה זמינה דרך REST API ולסוכנים דרך MCP, דרך סבירה לטפל בה בתיק דומיינים של לקוחות.
