כינויי דוא״ל בדומיין: חמש בעיות הגדרה ואבחון

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

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

אם מופיעים 550 5.7.520 או 554 5.4.14, או שהדואר נעלם למרות תשובת 250 OK מהשרת, כדאי להפסיק לנחש. המדריך מציג חמש תקלות תצורה נפוצות, קודי שגיאה רלוונטיים ודרכי טיפול. קבלת הודעה בשרת אינה הוכחה למסירה סופית.

אם קודם צריך להבין את המבנה הבסיסי - במה כינוי שונה מתיבת דואר - קראו את ההשוואה בין כינוי דואר בדומיין לתיבת דואר.

האם כינוי הדואר באמת לא עובד? מתחילים כאן

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

מדוע כינויי דואר נכשלים: שתי כתובות שולח

לצורך הבדיקה חשוב להבחין בין שתי זהויות. שולח המעטפת (RFC 5321 MAIL FROM) משמש את השרתים לניתוב הודעות החזרה - זה הדומיין ש-SPF בודק. השולח בכותרת (RFC 5322 From:) הוא הכתובת שהנמען רואה ב-Gmail או ב-Outlook - DMARC בודק התאמה בין הדומיין הזה לזהות שאומתה בהצלחה באמצעות SPF או DKIM.

ניתוב פנימי - מ-sales@ אל bob@ באותו שרת - בדרך כלל אינו יוצר בדיקת SPF חיצונית חדשה, אבל גם אינו מבטיח אימות תקין. בהעברה החוצה, השרת המקבל רואה את כתובת ה-IP של שרת ההעברה. אם שולח המעטפת המקורי נשמר והדומיין שלו אינו מתיר את ה-IP הזה, SPF עלול להיכשל. כשהמדיניות היא p=reject וגם DMARC נכשל, הנמען עשוי לדחות את ההודעה. עם זאת, חתימת DKIM מקורית, תקפה ותואמת שנשמרה יכולה לאפשר ל-DMARC לעבור. דחייה, בידוד והודעות החזרה תלויים במדיניות ובשלב הטיפול.

שגיאת תצורה 1: העברה חיצונית ללא SRS

העברת דואר מכינוי ל-Gmail, ל-Yahoo או לכתובת Outlook.com אישית עלולה להכשיל SPF כאשר שולח המעטפת המקורי נשמר. הדבר חשוב במיוחד במדיניות DMARC מחמירה. זהו סיכון שנדון כאן בהקשר של 2025-2026, לא טענה שכל הודעה מועברת נכשלת. גם עם p=reject, שימור DKIM ומדיניות הנמען משפיעים על התוצאה.

לדוגמה: לקוחה בשם alice@bank.com שולחת אל contact@yourdomain.com. השרת שלכם מעביר את ההודעה אל you@gmail.com. Gmail בודק SPF עבור bank.com. אם ה-IP של שרת ההעברה אינו מורשה אצל bank.com, SPF נכשל. לבנק יש מדיניות p=reject. ללא DKIM תקף ותואם, גם DMARC עלול להיכשל וההודעה עשויה להידחות או לקבל טיפול אחר בהתאם למדיניות. תשובת 250 OK הקודמת מהשרת שלכם מאשרת רק קבלה באותו שלב; היא אינה מבטיחה שתתקבל בהמשך הודעת החזרה.

פתרון ל-SPF של המעטפת: Sender Rewriting Scheme ‏(SRS). SRS משכתב את שולח המעטפת לדומיין שלכם לפני ההעברה:

המעטפת המקורית: alice@bank.com
לאחר שכתוב SRS: SRS0=hash=TT=bank.com=alice@yourdomain.com

כעת Gmail בודק SPF מול yourdomain.com. אם השרת מורשה עבור הדומיין הזה, הבדיקה יכולה להצליח. SRS מופעל ברמת השרת בידי ספק האחסון או מנהל הדואר. קיימים פתרונות שילוב עבור Postfix ו-Exim; בדקו מה נתמך בסביבה שלכם.

סייג חשוב: SRS יכול לאפשר ל-SPF לעבור עבור שולח המעטפת החדש, אך אינו משחזר התאמה לדומיין From המקורי. חתימת DKIM תקפה ותואמת שנשמרה עשויה להספיק להתאמת DMARC בדואר מועבר. ARC ‏(Authenticated Received Chain) מעביר תוצאות קודמות; המקבל חייב לאמת את השרשרת ולתת אמון בשירות החותם לפני שימוש בהן לפי שיקול דעתו. ARC אינו יוצר התאמה ואינו מבטיח מסירה. גם חתימה מחדש בדומיין שלכם, אם הוא שונה מדומיין From המקורי, אינה משחזרת אותה.

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

שגיאת תצורה 2: Microsoft 365 חוסם העברה חיצונית

אם הכינוי מעביר החוצה והשולחים מקבלים 550 5.7.520 Access denied, בדקו את מדיניות Microsoft. האפשרות "Automatic - System-controlled" במדיניות סינון דואר זבל יוצא ב-Exchange Online חוסמת, לפי התנהגות ברירת המחדל המתוארת, העברה חיצונית אוטומטית. מטרתה לצמצם זליגת נתונים. בדקו את המדיניות העדכנית בארגון לפני שתשנו אותה.

שינוי בפורטל הניהול:

1. פתחו את פורטל Microsoft 365 Defender
2. עברו אל: Email & collaboration → Policies & rules → Threat policies → Anti-spam
3. ערכו את Anti-spam outbound policy (Default)
4. הגדירו "Automatic forwarding rules" כ-On - Forwarding is enabled, אם מדיניות האבטחה מתירה זאת

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

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

Connect-ExchangeOnline
Set-HostedOutboundSpamFilterPolicy -Identity Default -AutoForwardingMode On

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

לולאת ניתוב עשויה להפיק 554 5.4.14 Hop Count Exceeded. ההודעה עוברת בין כתובות עד שהיא מגיעה למגבלת המעברים שהוגדרה בשרת - למשל 15-20 מעברים בסביבה מסוימת, לא מגבלה כללית. לאחר מכן השרת עשוי לשלוח הודעת החזרה לשולח המקורי, וההודעה אינה מגיעה לתיבה שלכם.

לעיתים קרובות מקור הלולאה הוא כלל שנשכח בתיבת היעד:

כינוי בשרת: info@ → admin@
כלל בתיבת admin@: להעביר הכול אל info@ לצורך ארכוב
תוצאה: לולאה עד חריגה ממגבלת המעברים

בדקו, למשל, כלל היעדרות מלפני שנתיים או כלל שנשכח ומעביר את כל הדואר לארכוב ב-info@. השנתיים הן דוגמה לגיל הכלל, לא סיבה קבועה לכל לולאה. עברו גם על כינויי השרת וגם על כללי תיבות הדואר. ב-Exchange בדקו את כללי התעבורה במרכז הניהול. ב-Google Workspace בדקו "Filters and Blocked Addresses" בכל חשבון מושפע.

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

שגיאת תצורה 4: חשיפת זהות ב-"Send As"

אם רוצים להשיב באמצעות הכינוי, הגדרת קבלה בלבד אינה מספיקה. כשמשיבים להודעה שנשלחה אל sales@yourcompany.com והנמען רואה bob.smith@yourcompany.com בשדה From, זהות השליחה אינה פועלת כמתוכנן. כך הכתובת הראשית עלולה להיחשף בלי שתבחינו בכך בצד שלכם.

מה לבדוק ב-Google Workspace:

1. פתחו User Settings → Accounts → "Send mail as"
2. הוסיפו את כתובת הכינוי
3. החליטו לפי זהות השליחה הרצויה אם לבטל את הסימון של "Treat as an alias". ביטול הסימון אינו פתרון פרטיות מובטח. בדקו את From, את Reply-To ואת שאר הכותרות בהודעת ניסיון.

מה לבדוק ב-Microsoft 365:

ב-M365, התצוגה "Bob on behalf of Sales" עשויה לנבוע מהרשאות שליחה מואצלת; היא אינה התנהגות ברירת מחדל של כל כינוי. לשליחה מכינויי תיבת דואר יש הגדרה ארגונית נפרדת:

Connect-ExchangeOnline
Set-OrganizationConfig -SendFromAliasEnabled $true

ההגדרה חלה על Exchange Online בלבד - לא על Exchange מקומי. SendFromAlias נפרד מהרשאות Send As ו-Send on Behalf, ויש לבדוק גם את תמיכת תוכנת הדואר. לכן הפקודה אינה פתרון כולל לכל תצוגת "on behalf of".

שגיאת תצורה 5: התנגשות עם catch-all

כלל catch-all, כגון *@domain.com, קולט כתובות שלא נמצאה עבורן התאמה מפורשת. אם מנגנון הניתוב נותן עדיפות לכלל רחב לפני כינוי מסוים, הדואר עלול להגיע לתיבה הלא נכונה ללא שגיאה ברורה.

במפות מאונדקסות של Postfix, ‏virtual_alias_maps מחפש תחילה כתובת מדויקת ואחריה catch-all של הדומיין. סדר השורות בקובץ המקור אינו קובע את קדימות החיפוש הזאת. בדוגמה הכינויים המפורשים מופיעים ראשונים לשם קריאות:

# /etc/postfix/virtual
billing@yourdomain.com    finance@yourdomain.com
support@yourdomain.com   helpdesk@yourdomain.com
@yourdomain.com          catchall@yourdomain.com

postmap /etc/postfix/virtual && postfix reload

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

אבחון מתקדם: קריאת הכותרות המקוריות

כשדואר נראה אבוד ללא הודעת החזרה, חפשו עותק בדואר זבל או בהסגר ובדקו את הכותרות המקוריות שלו. הכותרת Authentication-Results מציגה את בדיקות האימות שביצע השרת המקבל. שלבו את הממצאים עם יומנים ומעקב הודעות; כותרת אחת אינה מסבירה כל כשל מסירה.

ב-Gmail: פתחו את ההודעה → תפריט שלוש הנקודות → "Show original". חפשו את מקטע האימות:

בדיקות שנכשלו - ייתכן ש-SRS חסר:

Authentication-Results: mx.google.com;
  spf=softfail (domain of transition does not designate
    192.0.2.1 as permitted sender) smtp.mailfrom=alice@bank.com;
  dmarc=fail action=quarantine header.from=bank.com;

smtp.mailfrom עדיין מציג alice@bank.com. אם ה-IP שמופיע הוא שרת ההעברה שלכם, הדוגמה מראה ששולח המעטפת לא שוכתב באמצעות SRS.

בדיקות שהצליחו - מעטפת משוכתבת:

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=SRS0=HHH=TT=bank.com=alice@yourdomain.com;
  dmarc=pass header.from=bank.com;

כתובת המעטפת שוכתבה ו-SPF הצליח עבור yourdomain.com. הצלחת DMARC המוצגת כאן אינה נובעת מ-SRS; חתימת DKIM תקפה שנשמרה ותואמת ל-bank.com עשויה להסביר אותה. תוצאת DKIM אינה מוצגת בדוגמה המקוצרת, ולכן יש לבדוק אותה ואת התאמת הדומיין בהודעה האמיתית ולא להסיק זאת מהמקטע בלבד.

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

swaks --to sales@yourdomain.com --from test@external.com --server mx.yourdomain.com

250 OK מאשר קבלה של שלב ה-SMTP המסוים, לא את קיומה של תיבת דואר נפרדת ולא מסירה סופית. 550 User Unknown מצביע על דחיית נמען; בדקו את מפת הכינויים, תיבת היעד ומדיניות הנמענים.

מניעה: פישוט הניתוב וצמצום מעברים

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

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

כלל 2: צמצמו שרשראות כינויים למעבר אחד כשאפשר.

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

לכתובות זמניות או לקמפיינים אפשר לשקול כתובות עם סימן פלוס - bob+newsletter@domain.com - במקום ליצור כינוי בכל פעם. התמיכה וההגדרות הנדרשות תלויות בספק ובסביבה; בדקו אותן ב-TrekMail, ב-Gmail וב-Exchange. גם טפסים מסוימים דוחים את התו +, ולכן השיטה אינה עובדת בכל מקום.

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

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

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

TrekMail משתמש בתוכניות ברמת החשבון, לא בתעריף קבוע גורף לכל דומיין. בדוגמת Starter ההיסטורית במחיר ($3.50/חודש), ‏sales@, ‏support@ ו-billing@ מייצגים תיבות IMAP נפרדות עם פרטי כניסה וכתובות שליחה משלהן, שיכולות לפשט את הניתוב. בדקו מחירים, הרשאות, מגבלות תיבות ואחסון משותף עדכניים. כניסה נפרדת אינה מבטיחה מכסת אחסון נפרדת. רק במודל Nano המתואר נדרש SMTP חיצוני משלכם לכל הודעה יוצאת, לרבות תשובות; שליחה מנוהלת בתוכניות בתשלום תלויה בהרשאות ובהגדרות הלקוח בפועל.

הדוגמה ההיסטורית לסוכנויות מציינת Pro במחיר ($10/חודש) עם 100 דומיינים. בדקו מחירים, מגבלות והרשאות עדכניים לפני הוספת לקוחות. מעבר ב-IMAP מ-Gmail או מ-cPanel דורש גישה מאושרת למקור, בדיקת תאימות, אימות תיקיות וכמויות הודעות וסנכרון סופי. אנשי קשר ויומנים דורשים בדיקה נפרדת. תכננו את מעבר DNS ובדקו את ההעתקה; אין כאן הבטחה שהסביבה הפעילה לא תושפע או תחליף לגיבוי.

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

סיכום

בכינויי דואר כדאי לבדוק חמש תבניות: בעיות אימות בהעברה החוצה, חסימת מדיניות ב-Microsoft 365, לולאות מכללים שנשכחו, זהות שליחה שגויה והתנגשויות catch-all. קודי שגיאה וכותרות עוזרים לצמצם את האפשרויות, אבל אין לכל תקלה קוד ייחודי או פתרון אוניברסלי. SRS מסייע ל-SPF של מעטפת ההעברה, לא לשחזור התאמת DMARC המקורית.

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

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