דואר catch-all: אופן הפעולה, סיכונים וחלופות

דואר Catch-all הוא הגדרה בשרת הדואר שמנתבת נמענים לא מוכרים בדומיין ליעד ברירת מחדל. ללא המסלול הזה, השרת עשוי לדחות את ghost@yourdomain.com בשגיאת 550. עם Catch-all הוא עשוי להשיב 250 OK, אך אישור הנמען אינו אישור סופי של ההודעה לאחר בדיקות התוכן.

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

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

מהו דואר Catch-all?

דואר Catch-all, המכונה גם accept-all או ניתוב כולל, מספק יעד לנמענים שאין להם תיבה או כינוי נפרדים. במקום שגיאת 550 לכתובת לא מוכרת, ניתן לנתב אותה לתיבת קליטה ייעודית. יתר בדיקות SMTP והתוכן לא חייבות להתבטל.

בלוחות ניהול, accept-all ו-Catch-all מתארים לרוב יעד ברירת מחדל לנמען לא מוכר בשלב RCPT TO. ב-TrekMail בדקו Domains → Routing, או Connection בממשקים ישנים, ואז Catch-all Inbox. בחרו תיבה פעילה ומורשית באותו דומיין ובדקו את ההתנהגות בפועל לאחר השינוי, ללא הנחה של מסירה מיידית.

את השימוש בשיטה בסוף שנות ה-1990 יש להבין בהקשר ההיסטורי שלו. ב-2026, ניסיונות אוטומטיים לגילוי כתובות ומקורות ספאם הם גורמים תפעוליים רלוונטיים. Catch-all מרחיב את בחירת הנמענים, ולא בהכרח מקבל כל תוכן ללא סינון.

מדוע מנהלי דואר בוחרים ב-Catch-all?

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

חשש להחמיץ פנייה

לקוח עשוי לכתוב suport@ במקום support@. Catch-all עשוי לקלוט את ההודעה, אך גם לאפשר דואר לא רצוי לכתובות מומצאות. בחנו בתעבורה שלכם את היחס בין טעויות שימושיות לספאם.

לשגיאות מוכרות אפשר ליצור כינויים מפורשים. למשל, נתבו את support@ ואת suport@ לאותה תיבה. כך מצמצמים נמענים לא מוכרים, אך לא מחליפים מסנן ספאם.

עלויות רישוי למשתמש

דוגמת מחירים היסטורית ב-Google Workspace וב-Microsoft 365 היא $6-30 למשתמש לחודש. אם support@, billing@, jobs@ ו-marketing@ דורשים רישיונות משתמש נפרדים, הדוגמה עשויה להגיע ל-$120 בחודש. חבילות כאלה עשויות לתמוך גם בכינויים ובתיבות משותפות; לא כל כתובת תפקיד מחייבת משתמש נוסף.

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

אופן הפעולה ברמת SMTP

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

דחיית נמען לא מוכר

S: EHLO mail.sender.com
S: MAIL FROM: <sender@sender.com>
S: RCPT TO: <ghost@yourdomain.com>
R: 550 5.1.1 User unknown
(connection closed - zero bytes of message body transferred)

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

שימוש במסלול Catch-all

S: EHLO mail.sender.com
S: MAIL FROM: <sender@sender.com>
S: RCPT TO: <ghost@yourdomain.com>
R: 250 OK
(full message body, headers, attachments transferred)
→ routed to catchall-bucket@yourdomain.com

השרת מאשר את הנמען הלא מוכר, אבל בדיקות במהלך DATA עדיין עשויות לדחות את ההודעה. רק בקבלה הסופית הוא מקבל אחריות לעיבוד ולניתוב הנבחר. Catch-all כשלעצמו אינו סיבה לאחסן תוכן לא רצוי ללא בדיקה.

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

5 סיכונים בסביבת ייצור

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

סיכון 1: תעבורה נוספת מניסיונות גילוי כתובות

התקפות Directory Harvest Attacks ‏(DHA) מנסות לזהות כתובות קיימות באמצעות שמות כמו admin, david, invoice, hr, webmaster ו-noreply. Catch-all עשוי להסתיר את ההבחנה בתשובת הנמען, אך הניסיונות עדיין יוצרים תעבורה.

ללא Catch-all, נמען לא תקף עשוי לקבל שגיאת 550, אך התוקף אינו חייב לעצור. מעבר לדוגמה מ-50 הודעות ביום ל-50,000 ממחיש מדוע נדרשים תכנון קיבולת וסינון. זהו תרחיש עומס, לא תחזית לכל דומיין.

סיכון 2: הודעות שגיאה לא רצויות ומוניטין שליחה

Backscatter עשוי להיווצר בדפוס הטיפול הלא בטוח הבא:

1. ספאמר שולח הודעה אל random-gibberish@yourdomain.com בדומיין עם Catch-all.
2. הוא מזייף את MAIL FROM, זהות שולח המעטפה שעשויה להופיע בכותרת המסירה Return-Path, ל-victim@gmail.com.
3. השרת מקבל את ההודעה סופית באמצעות מסלול Catch-all.
4. סריקה מאוחרת מוצאת תוכן לא רצוי והמסירה הרגילה נכשלת.
5. הודעת אי-מסירה נשלחת לשולח המעטפה, המוצג כ-Return-Path: victim@gmail.com.
6. אדם שלא שלח את ההודעה מקבל התראה לא רצויה.

הודעות שגיאה לא רצויות רבות עלולות לפגוע במוניטין או לתרום לרישום ב-ips.backscatterer.org. זו אינה תוצאה אוטומטית של Catch-all. השתמשו בדחייה מתאימה בזמן SMTP או בהסגר מבוקר ללא תגובות לשולחים מזויפים. קראו גם על הגורמים לבעיות במוניטין דומיין והטיפול בהן.

סיכון 3: אחריות לא ברורה

אם partnerships@company.com מגיע לתיבת קליטה כללית, צריך להיות ברור מי מטפל בו. ללא בעל אחריות ושגרת בדיקה, דואר חשוב עלול להישאר ללא מענה. נדרש תהליך עבודה, לא רק ניתוב טכני.

כינוי מפורש מגדיר את היעד והאחראי. עבור partnerships@ אין צורך לנחש בדיעבד מי אמור לפעול. אפשר גם למנות אחראי ברור לתיבת Catch-all.

סיכון 4: עומס תמיכה לספקי שירות

בניהול 50+ דומיינים של לקוחות, מסלולי Catch-all עשויים לעורר שאלות כגון:

• "התיבה שלי מלאה ואיטית." בדקו מכסות ונפח לא רצוי.
• "אני מקבל יותר מדי ספאם." בחנו סינון וטווח נמענים.
• "אני לא מוצא את הודעת הלקוח." בתיבה עמוסה היא עשויה להיות בעמוד 400.
• "הדואר היוצא שלי מגיע לספאם." בחנו מוניטין, אימות ו-backscatter אפשרי.

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

סיכון 5: מידע אישי וציות

סעיף 5(1)(c) ב-GDPR דורש צמצום מידע בהתאם למטרות העיבוד בפועל. Catch-all אינו הפרה אוטומטית, אך קליטה רחבה עשויה לאסוף מידע נוסף. בחנו צורך, הרשאות, תקופות שמירה וטיפול בבקשות במסגרת העיבוד שלכם.

תיבה עם 500,000 הודעות ספאם עלולה להקשות על איתור מידע אישי. אם דואר אל doctor@yourclinic.com מגיע למנהלי מערכות, בחנו תפקידים, הרשאות, זרימות מידע, הסכמים ואמצעי הגנה. גישה של אנשי IT לבדה אינה מוכיחה תחולת HIPAA או הפרה; נדרשת הערכה מוסמכת.

SPF, DKIM ו-DMARC עם Catch-all

Catch-all אינו משנה ישירות את פרוטוקולי האימות. בהעברה, זהות המעטפה, החלקים החתומים וההתאמה ל-From קובעים את התוצאה. Backscatter ותעבורה מועברת לא רצויה מחייבים גם בדיקת מוניטין ומדיניות נפרדת.

העברה מוסיפה ממסר שהשרת המקבל מעריך. דוחות DMARC קשורים לדומיין From הגלוי ואינם מייחסים כל כשל למעביר. Google Postmaster Tools עשוי להציג לדומיינים זכאים נתונים מצטברים על Gmail אישי, לא תיעוד מלא של כל הדואר. תלונות ספאם הן דיווחי משתמשים, לא כל שגיאת אימות.

האתגר בהעברת דואר

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

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

הנמען רואה הודעה מכתובת ה-IP של הממסר שלכם, בעוד From: עשוי עדיין לציין את השולח המקורי, כגון bank@chase.com. SPF בודק את MAIL FROM בפועל, לא את הכתובת הגלויה; DKIM ו-DMARC בודקים תנאים אחרים.

1. SPF: אם זהות המעטפה המקורית של Chase נשמרת, כתובת ה-IP של הממסר עשויה לא להיות מורשית ב-SPF שלה.
2. DKIM: שינוי תוכן חתום, כגון תוספת בתחתית ההודעה או כותרת מכוסה, עלול לשבש אימות; לא כל עריכה משפיעה.
3. DMARC: אם אף אחת מבדיקות SPF ו-DKIM אינה עוברת עם התאמה נדרשת ל-From, הנמען מפעיל מדיניות כגון דחייה או הסגר.

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

העברה באמצעות SRS ו-ARC

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

SRS (Sender Rewriting Scheme)

SRS משכתב את שולח המעטפה לדומיין של הממסר, שעשוי להיות הדומיין שלכם. רשומת SPF של הדומיין המשוכתב בפועל חייבת להתיר את כתובת ה-IP של הממסר.

לפני SRS
Envelope From: alice@example.com

אחרי SRS
Envelope From: SRS0=HASH=TT=example.com=alice@your-forwarder.com

הנמען בודק SPF עבור your-forwarder.com. רק אם ההגדרות הנכונות מתירות את כתובת ה-IP שבשימוש, SPF עשוי לעבור לזהות הזאת.

SRS אינו מבטיח התאמה ב-DMARC. From: הגלוי עשוי להישאר alice@example.com, בעוד המעטפה משתמשת ב-your-forwarder.com. הזהויות אינן מתואמות אוטומטית. חתימת DKIM מקורית, תקפה ומתואמת ל-From, עשויה להספיק להצלחת DMARC. שינויים בחלקים חתומים עלולים לפגוע בה. קראו על העברת דואר עם SRS.

ARC (Authenticated Received Chain)

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

נמענים כגון Gmail ו-Microsoft עשויים להתחשב בשרשרת ARC מאומתת אם הם נותנים אמון בשירות החותם שזהותו אומתה. RFC 8617 מתאר את הפרוטוקול. ARC אינו כופה הצלחת DMARC, קבלה או הגעה לתיבת הדואר הנכנס.

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

הגדרת Catch-all עם בקרות מתאימות

מעבר מערכת, שילוב ישן או טיפול בשגיאות כתיב יכולים להצדיק Catch-all. בחרו מטרה מוגבלת ומנוהלת ואחראי ברור. לשלוש הגישות הבאות השלכות שונות; אף אחת אינה מספקת בידוד מלא או אבטחה מובטחת.

גישה A: תיבת קליטה עם גישה מוגבלת

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

1. צרו תיבה נפרדת: catchall-quarantine@yourdomain.com. העניקו רק הרשאות קבלה וגישה נחוצות, ללא הרשאות "Send As" לא רצויות.
2. נתבו אליה נמענים לא מוכרים מהדומיין המורשה, עם סינון וללא העברה או תגובות אוטומטיות.
3. ב-Microsoft 365, הגדרת SCL 9 מבקשת סיווג כספאם בוודאות גבוהה. הסיווג בפועל והמדיניות הפעילה קובעים תיקיית ספאם או הסגר והתראות; אל תחילו את הציון באופן עיוור על כל הדואר.
4. תכננו למשל בדיקה שבועית ותהליך לטיפול בשגיאות כתיב מדווחות, עם טיפול בזמן לפי צורכי העסק.

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

גישה B: Microsoft 365, DBEB ו-Internal Relay

בדומיינים במצב Authoritative עם ספריית נמענים מלאה, DBEB (Directory-Based Edge Blocking) יכול לדחות נמענים לא מוכרים לפני תוכן ההודעה. בדקו את מצב הדומיין וכל הנמענים התקפים; הבחירה חייבת להתאים לטופולוגיה בפועל.

Internal Relay Mode משבית DBEB לדומיין, אך אינו יוצר Catch-all בעצמו. צריך להגדיר מחברים, נמענים במערכות ההמשך, ניתוב ומניעת לולאות. בקשו ממנהל מורשה לבדוק את הטופולוגיה לפני השינוי, ואחריו בדקו עומס ומסירה.

גישה C: תבניות כתובות מוגבלות ב-Postfix

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

# /etc/postfix/virtual
sales-*@yourdomain.com    sales-bucket@yourdomain.com

עבור sales-q1@, sales-webinar@ ו-sales-2026@ נדרשת מפת regexp או PCRE עם עיגון נכון ותחימת דומיין. אסור ש-admin@, hr@ וכתובות אחרות ייכללו בטעות באותו מסלול. בדקו בחירת נמענים, יעדים ולולאות דואר לאחר שינוי ניסיוני.

כינויים וניתוב מפורש

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

כינוי, תיבה או Catch-all: בחירת מסלול

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

אילו כתובות אפשר ליצור?

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

• hello@ או info@: פניות כלליות לתיבת עבודה מורשית
• support@: שירות לקוחות למערכת תמיכה או לתיבה משותפת
• billing@: חשבוניות ותשלומים לצוות הכספים
• jobs@ או careers@: מועמדויות למשאבי אנוש או לשילוב ATS מבוקר
• noreply@: שולח להודעות תפעוליות; הגדירו טיפול בטוח בתגובות לגיטימיות

חמישה כינויים יכולים לכסות מבנה פשוט, אך לא כל צורך ב-Catch-all. ל-helo@ לא מוכר במקום hello@, השרת עשוי להשיב בשגיאת 550; השירות השולח קובע את ההתראה. הדבר עשוי לעזור לזהות את הטעות במקום להשאיר הודעה לא בדוקה שלושה שבועות. לשגיאות שנצפו אפשר ליצור כינויים ממוקדים בלי לקבל כל כתובת לא מוכרת.

בחינת TrekMail לצורכי Catch-all

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

דוגמת רישיונות המשתמש ההיסטורית

ב-$6-30 לחודש לכל רישיון נפרד, support@, billing@ ו-jobs@ עשויים להוסיף בדוגמה עד $90 לחודש. בדקו אם כינויים או תיבות משותפות חוסכים את הרישיונות. חיסכון אינו סיבה לדלג על בקרות ניתוב ואבטחה נחוצות.

מודל TrekMail

אחסון משותף והרשאות תיבות במסגרת מנוי עשויים לשנות את הבחירה. בדקו היקף עדכני, מכסות ועלויות לכתובת אם ישנן. דוגמאות היסטוריות מציינות Starter ב-$3.50 לחודש עם 50 דומיינים, ו-Pro ב-$10 לחודש עם 100 דומיינים. אלה אינן הבטחות למגבלות נוכחיות או לתיבות ללא הגבלה. במודל Nano המתואר נדרש SMTP חיצוני משלכם לכל הודעה יוצאת ולכל תשובה.

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

בדקו גם תמיכה במספר יעדים ובעותק מקומי. יעד Catch-all חיצוני ב-Pro או Agency עשוי להתאים בתנאים העדכניים לדומיין מנוהל ללא תיבה מקומית. נדרשים הרשאת בעל החשבון, בדיקת יעד, מניעת לולאות, אימות וניהול מידע. ראו ניתוב דומיין ליעד קליטה חיצוני.

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

שאלות נפוצות

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

מהו דואר Catch-all?

זהו מסלול בשרת הדואר לנמענים לא מוכרים בדומיין. במקום שגיאת 550, ניתן להגדיר לנמען יעד קליטה. גם תחת שמות כמו accept-all או ניתוב כולל, הבדיקות והיעדים תלויים במימוש.

האם אפשר להשתמש ב-Catch-all בבטחה?

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

האם Catch-all משפיע על מסירת דואר יוצא?

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

מה ההבדל מכינוי דואר?

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

האם יש Catch-all ב-Google Workspace או Microsoft 365?

Google Workspace מציע כללי ניתוב לנמענים לא מוכרים. ב-Microsoft 365 יש לבחון יחד דומיינים מתקבלים, מחברים, ספריית נמענים וכללים. Internal Relay משבית DBEB אך אינו הגדרת Catch-all בפני עצמו. בקשו ממנהל מורשה לבדוק טופולוגיה ומניעת לולאות. לרישיונות, כינויים ותיבות משותפות תנאים נפרדים.

כיצד משביתים Catch-all?

בדקו תחילה את כל הכתובות והמסלולים התקפים. ב-cPanel פתחו Home → Email → Default Address ובחרו "Discard with error to sender" לדחייה במהלך SMTP; בניגוד לכך, "Discard" המתקדם מוחק בשקט. ב-Google Workspace בדקו Apps → Google Workspace → Gmail → Routing, או Default routing לכלל ישן קיים. ב-Microsoft 365, מצב Authoritative מתאים כשספריית הנמענים מלאה והמחברים נבדקו. ב-TrekMail בדקו Domains → [domain] → Routing, או Connection בממשק ישן, ואז Catch-all Inbox → "No catch-all". אפשר לתכנן 24-48 שעות לבדיקת זרימת הדואר כדוגמה, לא כמועד אוניברסלי להתייצבות.

במה משתמשים במקום Catch-all?

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