מאגר ידע

שליחת אימייל דרך שרת ה-SMTP שלכם

חברו את שרת ה-SMTP שלכם: באיזו יציאה להשתמש ומדוע לא ב-25, רשומות ה-SPF, ה-DKIM, ה-DMARC וה-reverse-DNS שעליכם לפרסם בעצמכם, ומדוע אנו מסרבים לחזור לחיבור לא מוצפן.

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

⚠️ אם הספק שלכם הוא Mailgun, SendGrid, Postmark, Amazon SES או Resend, השתמשו במדריך הייעודי שלו במקום זאת. חיבורים אלה מספקים הודעות שגיאה טובות יותר כאשר משהו משתבש, מכיוון שאנו יכולים לקרוא את מה שהספק השיב בפועל במקום קוד סטטוס של SMTP בלבד.

מה נדרש מכם

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

  • מארח (Host) — לדוגמה, smtp.yourprovider.com
  • יציאה (Port) — 587, 465 או 2525
  • שם משתמש וסיסמה

באיזו יציאה לבחור

587 מיועדת להגשה (submission) עם STARTTLS וזו היציאה שבה עליכם להשתמש. החיבור מתחיל ללא הצפנה ומשודרג ל-TLS לפני שדבר כלשהו נשלח.

465 מיועדת ל-TLS מרומז (implicit TLS) — מוצפן החל מהבייט הראשון. אפשרות טובה באותה מידה; יש ספקים המעדיפים אותה.

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

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

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

הגדירו תחילה את ה-DNS שלכם

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

SPF — רשומת TXT המאשרת את כתובת השרת שלכם: v=spf1 ip4:203.0.113.10 -all, או v=spf1 a:smtp.yourprovider.com -all. אם כבר יש לכם רשומת SPF, ערכו אותה; שתי רשומות SPF בדומיין אחד מכשילות את SPF לחלוטין.

DKIM — שרת הדואר שלכם חותם על הודעות יוצאות ואתם מפרסמים את המפתח הציבורי התואם בכתובת <selector>._domainkey.yourdomain.com. ב-Postfix מדובר בדרך כלל ב-OpenDKIM; הספק שלכם ימסור לכם את ה-selector.

DMARC — רשומת TXT בכתובת _dmarc.yourdomain.com, המתחילה ב-v=DMARC1; p=none; בזמן שאתם בודקים שגם SPF וגם DKIM עוברים בהצלחה.

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

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

חברו את זה ב-Zinn®

פתחו את Email sending בלוח הבקרה שלכם:

  • Provider — שרת SMTP
  • Send from this domain — mail.yourdomain.com (דומיין, לא כתובת)
  • SMTP host, Port, Username, Password
  • Use STARTTLS — מופעל, אלא אם אתם ביציאה 465

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

שלחו את הודעת הבדיקה והזינו את הקוד

לחצו על Send test message לתיבת דואר נכנס בדומיין אחר, קראו מתוכה את הקוד והזינו אותו.

כאשר זה לא עובד

"The mail server rejected the username or password" — אימות ה-SMTP (SMTP AUTH) נכשל. אם לספק שלכם יש אימות דו-שלבי בחשבון, כמעט בוודאות תצטרכו סיסמת אפליקציה (app password) במקום סיסמת ההתחברות.

"Could not reach host:port" — היציאה חסומה, שם המארח שגוי, או שהשרת אינו מאזין להגשה (submission) ביציאה זו. הפקודה telnet smtp.yourprovider.com 587 ממחשב אחר תציין בפניכם מהי הסיבה.

שגיאת TLS — תעודת האבטחה של השרת שלכם פגה, היא בעלת חתימה עצמית (self-signed), או שאינה תואמת לשם המארח שהזנתם. אנו מאמתים תעודות ולא נדלג על בדיקה זו; תקנו את התעודה.

"The mail server refused the recipient" — השרת שלכם אינו מוגדר לבצע ממסור (relay) עבור שולח זה, מה שבדרך כלל אומר שלמשתמש שעבר אימות אין הרשאה לשלוח כדומיין השליחה שלכם.

ההודעות נשלחות אך הכל מגיע לספאם — זוהי בעיית DNS, לא SMTP. עברו ביסודיות על SPF, DKIM, DMARC ו-reverse DNS שלמעלה, ולאחר מכן הריצו מחדש את הבדיקה ב-mail-tester.

החדשות האחרונות מהבלוג

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

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

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

קרא את הפוסט ←

הפיכת WordPress למהיר ומאובטח: צ'ק-ליסט לביצועים ותוספים

צ'ק-ליסט מעשי עבור WordPress מהיר ומאובטח: שמירה במטמון ברמת השרת, מטמון אובייקטים לכל אתר, קומץ התוספים ששווה להפעיל, שמירה על עדכניות התשתית ודפי WooCommerce שלעולם אסור לשמור במטמון.

קרא את הפוסט ←

כיצד לבחור אחסון אתרים מנוהל בשנת 2026: מדריך לרוכש

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

קרא את הפוסט ←

קראו את הבלוג ←

עדיין נתקלתם בבעיה?

התמיכה כלולה בכל תוכנית, שולחן העבודה פתוח 24 שעות ביממה, ותוכלו לכתוב לנו בכל אחת מ-58 השפות שלנו — אנו נענה לכם בשפה שלכם.

יצירת קשר עם התמיכה → כל המאמרים →