כינוי דוא״ל: הגדרה, תצורה ושיטות עבודה מומלצות

עסק זקוק בדרך כלל ליותר כתובות דוא"ל ממספר העובדים שלו: sales@ ללידים, support@ לפניות ו-billing@ לחשבוניות. בדרך הישנה משלמים על תיבה נפרדת לכל כתובת. אלה שלושה רישיונות, שלושה חיובים חודשיים ושלוש כניסות לניהול.

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

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

מהו כינוי דוא"ל?

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

לא נכנסים לכינוי, אלא לתיבה שאליה הוא מנתב. הכינוי הוא הוראה ברמת השרת: דואר לכתובת הזאת יימסר שם.

שלושה דברים שכינוי איננו:

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

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

טכנית, כינוי מיושם כרשומה במפת הכינויים של שרת הדואר: virtual_alias_maps ב-Postfix, רשומת נתב ב-Exim או כלל ניתוב בשירות מתארח. דמון SMTP בודק את המפה בשלב RCPT TO. אם הכתובת נמצאת בה, הוא משכתב פנימית את נתיב המסירה בלי לחשוף זאת לשולח.

כינוי לעומת העברה ולעומת תיבה

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

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

להחלטה מפורטת ראו כינוי דומיין לעומת תיבה: כיצד לבחור.

שימושים חשובים באמת

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

1. ניתוב לפי תפקיד (חזית מקצועית)

מייסד יחיד יכול להציג ממשק מסודר. צרו info@, press@, accounts@ ו-sales@ ככינויים לתיבה הראשית. כשמצטרף איש מכירות, אפשר להסיר את sales@ ככינוי וליצור עבורו תיבה, בלי שינוי נרחב.

2. מעקב אחר ספקים

במקום למסור לכל ספק את הכתובת הראשית, צרו כינוי לכל ספק: hubspot@yourdomain.com, linkedin@yourdomain.com, surveygizmo@yourdomain.com. ספאם שמגיע אל linkedin@ מצביע על מקור אפשרי לדליפה או לפריצה. אפשר למחוק את הכינוי בלי לשנות את שאר המערכת.

זהו מעין canary token לדוא"ל. ההגדרה פשוטה והיא עשויה לחסוך זמן אבחון אם מאגר של ספק נחשף.

3. שגיאות כתיב וכתובות ישנות

אם שמכם Michael, אנשים עלולים לכתוב micheal@yourdomain.com. אם החברה החליפה מותג, ייתכן שדואר עדיין מגיע לדומיין הישן. מפו שגיאות נפוצות וכתובות קודמות לתיבה הנוכחית כדי להפחית דואר אבוד ולא לבדוק שתי מערכות.

4. כתובות פלוס (כינוי ללא הגדרה)

מערכות מודרניות רבות, ובהן TrekMail, Gmail ו-Microsoft 365, תומכות בכתובות פלוס לפי RFC 5233. עבור bob@company.com אפשר להשתמש ב-bob+newsletter@company.com או bob+support-ticket@company.com בלי הגדרת מנהל. הדואר מגיע לבוב והתג מאפשר סינון.

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

5. סוכנויות וריבוי דומיינים

בסוכנות שמנהלת כמה דומיינים, כל כתובת תפקיד כגון support@clientdomain.com או billing@clientdomain.com עלולה לדרוש רישיון נוסף במודל לפי משתמש. לפי מודל המחיר הקבוע המתואר של TrekMail, אפשר ליצור כינויים בדומייני לקוחות בלי חיוב נפרד לכל כינוי, בכפוף לתנאי התוכנית העדכניים. ראו אירוח דוא"ל למספר דומיינים בקנה מידה.

6. ניתוב מחלקות כשהצוות גדל

כתובות hr@, legal@ ו-finance@ יכולות להפנות כעת לעובד האחראי ובהמשך אל תיבה משותפת. שינוי יעד הכינוי לרוב אינו דורש שינוי DNS או קליטה מחדש.

כיצד כינוי מנתב דואר: מנגנון SMTP

כינוי פועל בשלב RCPT TO של SMTP, לפני העברת גוף ההודעה. כשהשרת השולח מפיק RCPT TO: <sales@yourdomain.com>, השרת בודק את הטבלה, מוצא את sales, משכתב את נתיב המסירה ומקבל בדרך כלל ב-250 OK. כותרת To: המקורית נשמרת.

שלב אחר שלב:

1. שרת חיצוני מתחבר לשרת MX ופותח SMTP.
2. השרת שולח: RCPT TO: <sales@yourdomain.com>
3. אין תיבה sales, אך כלל מפנה אל bob@yourdomain.com.
4. השרת מקבל (250 OK) ומוסר לבוב.
5. הלקוח מציג To: sales@yourdomain.com, כי הכותרת לא השתנתה.
6. שרת השולח אינו צריך לדעת על הכינוי, ואין סשן SMTP נוסף לניתוב הפנימי.

ב-Postfix הדבר נעשה באמצעות virtual_alias_maps. Exim משתמש בנתבים ו-Haraka בניתוב מבוסס תוספים, אך העיקרון זהה: שכתוב בצד השרת לפני אחסון.

הפתרון מתבסס על כתובת המעטפה בפקודת RCPT TO, לא בהכרח על To:. רשימת תפוצה עשויה להציג To: list@example.com אך לשלוח אל RCPT TO: member@yourdomain.com. הכינוי מופעל לפי RCPT TO.

בעיית "שליחה בשם": מענה מהכינוי

קבלה דרך כינוי פשוטה; מענה מהכינוי מכשיל הגדרות רבות. בוב מקבל הודעה ל-sales@yourdomain.com, אך כתובת From ברירת המחדל עלולה להיות bob@yourdomain.com, וכך נחשפת הכתובת האישית.

הפלטפורמות מטפלות ב"שליחה בשם" באופן שונה:

Google Workspace

ב-Gmail עברו אל הגדרות → חשבונות → "שליחת דואר בשם" → הוספת כתובת. הזינו את הכינוי ובדקו את האפשרות "התייחס ככינוי" בהתאם להתנהגות הרצויה ולמדיניות הנוכחית. האפשרות עשויה להשפיע על From, ולכן מומלץ לבדוק בפועל.

Microsoft 365

בעבר מנהל נדרש להריץ Set-OrganizationConfig -SendFromAliasEnabled $true. אחרת ייתכן "בוב בשם מכירות". Microsoft הוסיפה מתג מרכז ניהול ב-2024, אך יש לבדוק את המיקום והמצב הנוכחיים בכל דייר.

TrekMail

TrekMail מאפשרת זהויות שולח מרובות בהתאם לחשבון וללקוח. לאחר הגדרה נכונה אפשר לבחור From ב-Outlook, Thunderbird, Apple Mail או webmail. בדקו את ההנחיות העדכניות ב-הגדרות IMAP/SMTP.

הגדרות שגויות ששוברות דוא"ל

כינויים פשוטים ברעיון אך רגישים להגדרה. שלוש טעויות נפוצות הן:

1. מלכודת Catch-all

כינוי catch-all‏ (*@yourdomain.com) מקבל כל הודעה לדומיין, גם לכתובות שאינן קיימות. זו עלולה להיות מלכודת ולא רשת ביטחון.

תוקפים משתמשים ב-Directory Harvest Attacks (DHA) ושולחים לאלפי שמות אקראיים. בלי catch-all השרת דוחה כתובת לא ידועה ב-SMTP עם 550 5.1.1 User unknown. עם catch-all הוא מקבל הכול, נפח הספאם עלול לגדול והודעות תקינות עלולות להיקבר.

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

2. לולאת ניתוב

support@ מנתב אל bob@yourdomain.com, ובוב מגדיר בחופשה העברה אוטומטית אל support@. כך נוצרת לולאה:

כעת יש לולאה:

support@ אל bob@ → bob@ אל support@ → אל bob@ → אל support@ → …

שרתים מזהים זאת לבסוף. Postfix סופר hops, ואחרי החריגה עשוי להחזיר 5.4.14 Hop count exceeded. ההודעה לא תגיע ליעד המיועד. מפו כינויים והעברות לפני כללי חופשה ולעולם אל תחזירו תיבה לכינוי שמנתב אליה.

3. חשיפת זהות ב"השב לכולם"

רשימה שולחת אל marketing@yourdomain.com, שמנתב אל bob@yourdomain.com. מענה לכולם בלי החלפת From חושף את bob@yourdomain.com במקום marketing@. במשפטים, רפואה ופיננסים זו חשיפת פרטיות ממשית.

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

שילוב כינוי והעברה: SPF, DMARC ו-SRS

שילוב כינוי והעברה חיצונית, למשל contact@yourdomain.com אל Gmail אישי, עלול ליצור התנגשויות אימות שפוגעות בדואר תקין.

מה עלול להיכשל:

כשל SPF: שרת ההעברה שולח מ-IP שלו. הדומיין המקורי bank.com אינו מאשר IP זה, ולכן Gmail עשוי לראות כשל SPF אף שהמקור היה מורשה והשרת אינו ברשימת SPF של bank.com.

דחיית DMARC: אם bank.com מפרסם p=reject, הודעה עלולה להידחות אם גם SPF מיושר וגם DKIM מיושר נכשלים. שינוי תחתית, קידוד או גוף עשוי לשבור DKIM, ואז מדיניות p=reject עשויה לגרום לדחייה. אם DKIM המיושר נשאר תקין, DMARC עדיין יכול לעבור.

שני מנגנונים מסייעים ודורשים תמיכת ספק:

• SRS (Sender Rewriting Scheme): משכתב את שולח המעטפה (MAIL FROM) לדומיין מורשה ומקודד כתובות החזרה.
• ARC (Authenticated Received Chain): מוסיף שרשרת חתומה של תוצאות אימות לפני ההעברה. שרתים תומכים יכולים להתחשב בה עבור מתווך מוכר. ראו RFC 8617.

מארחים ישנים ורשמי דומיין זולים רבים אינם תומכים ב-ARC או ב-SRS. לכן הודעות משולחים עם DMARC מחמיר עלולות להיפגע ולעיתים ללא החזרה ברורה. בדקו את התמיכה העדכנית של TrekMail ושל היעד.

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

הגדרת כינויים ב-TrekMail

כינויי TrekMail מנוהלים ברמת הדומיין ומנתבים לתיבות זמינות בהתאם למערכת ולתוכנית.

שלב 1: הוספת הדומיין והגדרת DNS

אם הדומיין אינו ב-TrekMail, עברו אל Domains → Add Domain. העתיקו אל ספק DNS את רשומות MX, SPF, DKIM ו-DMARC המוצגות. ערכים עדכניים נמצאים ב-רשומות DNS נדרשות. ההפצה עשויה להימשך לפי TTL והספק, והמערכת מציגה סטטוס לאחר זיהוי.

שלב 2: יצירת תיבת היעד

עברו אל Mailboxes → Add Mailbox והגדירו כתובת וסיסמה. לשם יגיע דואר הכינוי. עלויות ואחסון תלויים בתנאי התוכנית העדכניים.

שלב 3: יצירת הכינוי

עברו אל Aliases → Add Alias, הזינו את החלק המקומי כגון sales, בחרו תיבת יעד ושמרו. לרוב אין צורך בשינוי DNS, אך זמן ההפעלה תלוי בשירות.

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

שלב 4: הגדרת "שליחה בשם" בלקוח

כדי לענות מהכינוי, הוסיפו אותו כזהות שולח:

• Thunderbird: Account Settings → Manage Identities → Add, והזינו את הכינוי עם שרת ופרטי SMTP המתאימים.
• Outlook (desktop): הכינוי עשוי להופיע ב-From לאחר הגדרת שרת. אם לא, בדקו את גרסת הלקוח, מדיניות החשבון ואפשרויות כותרת From.
• Apple Mail: Mail → Preferences → Accounts → Account Information, והוסיפו את הכינוי לשדה "Email Address" אם הגרסה תומכת בזהויות מרובות.
• Webmail: ממשק TrekMail עשוי להציג את הכינוי ברשימת From לאחר הגדרה נכונה. בדקו את הממשק הנוכחי.

הערכים המתוארים הם IMAP ביציאה 993 ‏(SSL/TLS) ו-SMTP ביציאה 587 ‏(STARTTLS). אמתו אותם ב-תיעוד IMAP/SMTP.

שלב 5: בדיקה מקצה לקצה

שלחו מבחוץ לכינוי ואמתו הגעה לתיבת היעד. השיבו עם הכינוי ב-From ובדקו שהנמען רואה אותו ולא את התיבה הראשית. אם לא, בדקו את הגדרת "שליחה בשם".

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

הדרך הישנה לעומת TrekMail

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

הדרך הישנה (Google Workspace / Microsoft 365)

השירותים מחייבים בדרך כלל למשתמש. הדוגמה מציינת $6/user/month ל-Google Workspace Business Starter ומחיר דומה ל-Microsoft 365 Business Basic, אך יש לבדוק מחיר אזורי נוכחי. הכינוי עשוי להיות חינם, אך תיבת היעד דורשת רישיון.

צוותים קטנים מרכזים לעיתים info@, sales@, billing@ ו-support@ אצל המייסד. כך נחסכים רישיונות אך נוצרים עומס וחוסר בעלות ברור.

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

הדרך של TrekMail

TrekMail מתארת אירוח במחיר קבוע. הדוגמה מציינת Starter ב-$3.50/month עבור up to 50 domains ואחסון משותף. יש לאמת מחיר ומגבלות נוכחיים; במסגרת המודל כינוי או תיבה אינם בהכרח שורת חיוב נפרדת.

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

הדוגמה מציינת Agency ב-($23.25/month), כיסוי 1,000+ domains, ייבוא קבוצתי ו-API. מחירים, מגבלות ותכונות משתנים, לכן אמתו אותם לפני חישוב עלות לדומיין.

פרטים ב-trekmail.net/pricing.

מדריך מהיר

טבלת החלטה מהירה:

שלושה כללים:

1. ניתוב פנימי = כינוי. חיצוני = העברה. אל תוסיפו סיכון SPF/DMARC כשכינוי מספיק.
2. הגדירו "שליחה בשם" לפני שימוש חיצוני. מענה שחושף כתובת ראשית פוגע בחזית המקצועית.
3. אל תנתבו catch-all לתיבה אמיתית. השתמשו בהסגר או ותרו עליו.

סיכום

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

בקצרה:

• השתמשו בכינוי לכתובות תפקיד, מעקב ספקים ושגיאות כתיב.
• השתמשו בתיבה לכניסה, אחסון או ביקורת נפרדים.
• הימנעו מ-catch-all בלי הסגר מבוקר.
• בהעברה חיצונית בדקו SRS ו-ARC, שאינם נתמכים אצל כל מארח ישן.
• הגדירו "שליחה בשם" לפני תקשורת חיצונית.

אם משלמים למשתמש רק עבור כתובות תפקיד, כדאי להשוות מודלים. הדוגמה מציינת TrekMail Starter ב-$3.50/month לעד 50 domains, ואת Nano ללא כרטיס אשראי או תקופת ניסיון, עם 10 domains ו-5GB משותפים. אמתו מחירים, מגבלות ותנאים נוכחיים.

לפי הדוגמה, תוכניות בתשלום עם SMTP מנוהל, אחסון משותף וניהול רב-דומייני כוללות 14-day free trial ודורשות כרטיס אשראי. בדקו את ההצעה ב-trekmail.net והשוו ב-trekmail.net/pricing.