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

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

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

זהו מצב זומבי: האורות דולקים, אבל איש אינו בבית. הכניסה עובדת כי Webmail פועל דרך HTTPS (יציאה 443), אותו פרוטוקול של כל אתר. שליחה וקבלה דרך Outlook,‏ Apple Mail או ה-CRM משתמשות ב-SMTP וב-IMAP. אלה דלתות שונות לגמרי, וייתכן שהן עדיין נעולות.

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

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

שלב 1: זהו את התסמין לפני שינוי כלשהו

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

תרחיש A: עיר הרפאים (אי אפשר לקבל)

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

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

תרחיש B: חסימת דואר יוצא (אי אפשר לשלוח)

לוחצים על שליחה ב-Outlook או ב-iPhone וסרגל ההתקדמות נתקע. עשויה להופיע ״Connection Timed Out״ או ״Server Unreachable״, כלומר זמן החיבור פג או שהשרת אינו נגיש.

מה לבדוק: בדקו DNS, זמינות שרת, חומת אש, מדיניות ספק האינטרנט לגבי יציאה 25 והגדרות TLS. כשל בחיבור אינו בהכרח חסימה ברשת.

תרחיש C: שולח לא מהימן (ספאם או החזרות)

הדואר נשלח, אך מגיע לתיקיית הספאם של הנמען. או שמתקבלת מיד הודעת החזרה: 550 5.7.1 Message rejected.

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

רשימת התיקון: כיצד להגדיר נכון אימייל בדומיין שלי

עברו על השלבים לפי הסדר. אל תדלגו על שכבות.

1. רשומות MX: נקודות הציון של ה-GPS

כשמישהו שולח דואר אל you@yourdomain.com, השרת שלו מחפש ב-DNS את שרתי הקבלה. רשומות MX שגויות עשויות להפנות לספק קודם או לגרום לעיכוב או לשגיאה. בדקו את התוצאה בפועל בתשובות השרת ובתור השליחה.

שתי טעויות שפוגעות במסירות:

• רשומות שנותרו מהספק הקודם. בדקו אם רשומות GoDaddy או ספק קודם אחר תואמות לנתיב הנוכחי. שער דואר או תצורה היברידית מאושרים יכולים להשתמש בכמה ספקים. בדקו עדיפויות ונתיבי גיבוי, והסירו רק רשומות שהתייתרו לאחר אישור המנהל.
• הפניית MX אל CNAME. רשומת MX חייבת להפנות לשם מארח שנפתר ישירות לכתובת IP באמצעות רשומת A או AAAA. הפניה ל-CNAME מפרה את RFC 2181 ועלולה לגרום לכשלי מסירה שנראים אקראיים.

בדקו עכשיו את רשומות ה-MX:

dig mx yourdomain.com +short

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

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

2. מצב תיבת הדואר והאחסון

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

• האם תיבת הדואר באמת קיימת? בדקו את האיות. האם יצרתם support@ או suport@?
• האם התיבה חרגה מהמכסה? ב-Google Workspace וב-M365 המכסות האישיות והמשותפות והטיפול בחריגה תלויים במוצר ובמהדורה. בדקו את המגבלות בפועל ואת התשובה המלאה, כולל ״Mailbox Full״ אם מופיעה.

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

3. תצורת SMTP: זהירות עם כלל האצבע של 90%

זהו אומדן גס להמחשה, לא נתון שנמדד על שכיחות תקלות. הכניסה ל-Webmail משתמשת בחיבור האינטרנט של הדפדפן, בנפרד מחיבור SMTP של לקוח שולחן העבודה. Webmail עצמו עשוי להשתמש ב-SMTP בצד השרת לשליחה. הגדירו Outlook,‏ Thunderbird או CRM לפי הערכים שהספק דורש בפועל.

ספקי אינטרנט ביתיים ומשרדיים רבים חוסמים את יציאה 25. Comcast,‏ Verizon ו-AT&T עשויות לחסום תעבורה יוצאת ביציאה 25 כדי לעצור בוטים של ספאם. אם ניסיתם להתחבר ביציאה 25, ייתכן שזו הסיבה.

השתמשו ב-STARTTLS ביציאה 587 וב-TLS מתחילת החיבור ביציאה 465. הכיתוב SSL בלקוח עשוי להיות שם הגדרה ישן, לא המלצה לפרוטוקול SSL שהוצא משימוש. TLS מובלע על 587 או STARTTLS על 465 עלולים להיכשל. בדקו גם התאמה בין שם השרת לאישור תקף.

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

4. שם מארח: השתמשו בערך המדויק, לא בניחוש

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

• mail.google.com (ספק שגוי)
• smtp.yourdomain.com (נדרשים רשומת כתובת מתאימה או כינוי נתמך ואישור תואם; CNAME אינו הדרך היחידה)

השתמשו בשם המארח מהודעת הפתיחה או מלוח הבקרה של הספק, למשל smtp.trekmail.net. הערכים המדויקים מופיעים במדריך להגדרות IMAP & SMTP.

5. SPF,‏ DKIM ו-DMARC: דרישות בסיסיות ב-2025

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

SPF היא מדיניות TXT שמאשרת כתובות IP לשליחה עבור דומיין שולח מעטפת SMTP, ולא מאמתת ישירות את דומיין From המוצג. התאימו את הדוגמה לדרישות הספק בפועל:

v=spf1 include:sendingprovider.net ~all

טעות קריטית: מותרת רק רשומת SPF אחת. אם יש שתי שורות שמתחילות ב-v=spf1, הערכת SPF מחזירה שגיאה קבועה. מזגו אותן לרשומה אחת.

DKIM מאפשר אימות קריפטוגרפי של חלקי ההודעה שנחתמו. בדקו את מפתח ה-DNS ואת החתימה ותוצאת האימות של הודעה בפועל. אל תניחו שכל הודעה מקבלת אוטומטית חתימה תקפה.

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

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

עברו אל p=quarantine או p=reject רק אחרי שבדקתם את הדוחות ואישרתם שהדואר הלגיטימי עובר. ההליך המלא נמצא במדריך לרשומות DNS נדרשות.

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

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

DNS מפוצל

תסמין אופייני: הדואר עובד בחיבור הסלולרי של הטלפון, אך נכשל ב-Wi-Fi או ב-VPN של המשרד.

בדקו אזורי DNS פנימיים ומדיניות העברת שאילתות ב-Active Directory,‏ Pi-hole או בפותר הארגוני. השוו תשובות פנימיות וחיצוניות עבור mail.yourdomain.com ותקנו לפי הנתיב המאושר. mail.yourdomain.com עשוי להפנות לשרת ציבורי או פנימי לפי התצורה. כתובת פרטית כמו 192.168.x.x יכולה להיות תקפה בסביבה היברידית; אין להחליפה בכתובת ציבורית בלי לבדוק.

אי התאמה ב-MTU

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

בנתיב VPN (WireGuard,‏ IPsec) או DSL/PPPoE, ה-MTU הזמין עשוי להיות קטן מהערך הרגיל של 1500 בתים. באישור המנהל, תעדו את הערך המקורי, נסו MTU של 1300 בהיקף מוגבל והחזירו את ההגדרה הקודמת. שינוי בתסמין מצדיק בדיקת MTU הנתיב, אך אינו מוכיח לבדו השמטת מנות מפוצלות.

בדיקת SSL של האנטי-וירוס

תסמין: לקוח הדואר מציג שגיאת אישור אף שאתם יודעים שאישור השרת תקף.

״Mail Shield״ או ״SSL Scanning״ ב-Avast וב-Bitdefender עשויים להציג אישור משלהם בעת בדיקת החיבור. בדקו את שרשרת האישורים והגדרות האמון עם מנהל האבטחה. בצעו רק בדיקה זמנית ומאושרת בהיקף מוגבל והחזירו את ההגדרות. אל תבטלו אימות אישורים, אל תשביתו בדיקה באופן גורף ואל תוסיפו חריגה קבועה שאינה בטוחה.

סיסמאות יישום כאשר 2FA מופעלת

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

לקוחות IMAP/SMTP ישנים מסוימים אינם תומכים בכניסה אינטראקטיבית עם 2FA, אך לקוחות וספקים תואמים יכולים להשתמש ב-OAuth. הצורך בסיסמת יישום תלוי במדיניות החשבון ובתמיכת הספק בפועל. אם היא נתמכת, הקצו אותה למכשיר, שמרו עליה ובטלו אותה כשאין בה צורך. אל תבטלו את ה-2FA הרגיל.

הגדרת אימייל בדומיין שלי: מה להכין לפני שפונים לתמיכה

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

קוד השגיאה המדויק. לכל אחד משמעות שונה:

• 550 User Unknown: השרת מדווח שהנמען אינו מוכר; בדקו כתובת והגדרת נמענים
• 421 Connection Refused: סירוב SMTP זמני, להבדיל משגיאת סירוב לחיבור TCP של מערכת ההפעלה; בדקו את תשובת השרת המלאה
• 535 Authentication Failed: כשל אימות; בדקו פרטי הזדהות, שיטה ומדיניות חשבון
• 5.7.1 Relay Access Denied: סירוב להרשאת ממסר; בדקו אימות, נתיב ומדיניות שרת

יומן החיבור. הפעילו יומני פתרון בעיות ב-Outlook או ב-Thunderbird. התקשורת שנרשמה יכולה לסייע בזיהוי שלב החיבור שנכשל, אך לא כל יומן כולל את כל האירועים הרלוונטיים:

CLIENT: EHLO mycomputer
SERVER: 250-Hello
CLIENT: AUTH LOGIN
SERVER: 334 VXNlcm5hbWU6

התשובה אחרי AUTH LOGIN בדוגמה מבקשת שם משתמש ואינה מוכיחה סיסמה שגויה. עצירה לפני EHLO מצדיקה בדיקת DNS, חיבור TCP,‏ TLS ומצב השרת. הסתירו פרטי הזדהות ומידע אישי לפני שיתוף יומנים.

אימות בשורת הפקודה. הריצו את הפקודות האלה עוד לפני פתיחת פנייה:

# Check MX records
dig mx yourdomain.com +short

# Check SPF record
dig txt yourdomain.com +short

# Test if port 587 is reachable
telnet smtp.trekmail.net 587

אם telnet מציג הודעת פתיחה 220, נוצר חיבור TCP לשרת SMTP; אין זו הוכחה ל-TLS, לאימות או למסירה. אם ״Connecting...״ אינו מתקדם, בדקו DNS, מצב שרת ונתיב רשת יחד. אל תזינו סיסמה בחיבור שאינו מוצפן.

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

למה זה ממשיך לקרות: הבעיה האמיתית באחסון אימייל מסורתי

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

Google Workspace ו-Microsoft 365 הן חבילות שיתוף פעולה עצומות. הן לא נבנו רק עבור מי שזקוק לאימייל מקצועי. הן מספקות פורטל חיוב, מאמר עזרה ותור לתמיכה. כשמשהו מתקלקל, לעיתים תצטרכו לחקור בעצמכם.

תמחור לפי משתמש עשוי להוסיף עלויות. הטווח בין $6 ל-$20 בחודש הוא דוגמה היסטורית; בדקו מחיר וחוזה עדכניים. עובד שבודק דואר פעמיים בשבוע עשוי להזדקק לרישיון משתמש, אך כינויים ותיבות משותפות יכולים להיות כפופים לכללים אחרים. 30GB היא דוגמת מכסה; מכסות אישיות ומשותפות ואפשרויות הרחבה תלויות במהדורה.

המודל של TrekMail משתמש בתמחור לפי חשבון ובאחסון משותף. בדוגמת Pro ההיסטורית של 50GB, אותם 50GB משותפים לארגון; בדקו מגבלות עדכניות של התוכנית והתיבות. שליחה מנוהלת בתוכניות בתשלום תלויה בהרשאות ובהגדרת לקוח נתמך; מודל Nano המתואר כאן דורש SMTP חיצוני משלכם לכל שליחה ותשובה. גם כשהספק מנהל תשתית שליחה, אופן השימוש שלכם משפיע על המוניטין. השוו זאת לצורך בפועל ב-SharePoint,‏ Teams או ״Viva״.

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

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

הגרסה הקצרה

כשהכניסה עובדת אך הדואר לא, התחילו בחמישה תחומים: נתיב MX, מדיניות ספק האינטרנט לגבי יציאה 25, שם המארח בלקוח, SPF/DKIM/DMARC ותוצאות אימות בפועל, והרשת המקומית. זו נקודת התחלה ולא רשימה של כל הסיבות האפשריות.

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

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