EQVPS

הרצת שרת דואר על VPS: מה באמת שומר אתכם מחוץ לספאם

1 ביולי 2026 · 4 דק' קריאה · EQVPS Team

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

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

שלושה דברים נושאים את רוב המשקל: reverse DNS, אימות שולח, והאם המארח שלכם בכלל נותן לכם לדבר על פורט 25. אף אחד מהם לא קשה. הם פשוט קלים לשכוח, וכל אחד הוא וטו שקט.

זה שכולם שוכחים: reverse DNS

Forward DNS הוא החלק שאתם מכירים — שם מצביע על IP. reverse DNS הוא המראה: IP מצביע בחזרה על שם. הרשומה הזו נקראת PTR, והיא חיה עם מי ששולט ב-IP, לא ב-zone של הדומיין שלכם.

הנה למה זה חשוב. כשהשרת שלכם פותח חיבור ל-SMTP של Gmail, אחד הדברים הראשונים שהצד המקבל עושה הוא lookup הפוך על ה-IP שלכם — מי זה? הריצו אותו בעצמכם:

dig -x 203.0.113.19 +short

אם זה חוזר עם משהו כמו static.203-0-113-19.rev.example-isp.net, או חוזר ריק, כבר הפסדתם נקודות. השם הגנרי הזה אומר "איזה VPS אקראי," וגרוע יותר, הוא לא תואם את ה-hostname שהשרת שלכם מציג את עצמו בו בברכת ה-HELO. שרתים מקבלים מסמנים את חוסר-ההתאמה הזה בחוזקה. חלקם דוחים על הסף.

מה שהם רוצים לראות זה PTR שתואם את ה-hostname של הדואר שלכם. אם השרת שלכם אומר HELO mail.example.com, ה-lookup ההפוך על ה-IP שלו צריך להחזיר mail.example.com. forward ו-reverse מסכימים, הסיפור עקבי, ואתם נראים כמו שרת דואר אמיתי במקום ארגז חטוף.

הגדרת PTR נהגה מסורתית לפתיחת תיקט תמיכה עם מי שמחזיק בבלוק ה-IP והמתנה. בתוכניות עם IP ייעודי של EQVPS זה שדה בלוח הבקרה שלכם — הקלידו את ה-hostname, זה כותב ישר ל-registry דרך ה-API של הספק, וזה חי תוך שניות. זו כל הנקודה בעשיית זה בשירות-עצמי: reverse DNS הוא הצעד שאנשים מדלגים עליו כי הוא נהג להיות מעצבן.

אימות: SPF, DKIM, DMARC

שלוש הרשומות DNS האלה אומרות לשרתים מקבלים שדואר שטוען שהוא מהדומיין שלכם באמת כן. דלגו עליהן ואתם זר לא-מאומת.

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

פורט 25, ולמה הוא סגור

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

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

ויש הסתייגות כנה כאן ששווה לומר בבירור: עם פורט 25 פתוח מגיעה אחריות. סקריפט אחד שנפרץ או relay מוגדר-לא-נכון שמזרים ספאם, והמוניטין של ה-IP שלכם נעלם — לפעמים לשבועות. ב-subnet משותף הבלגן הזה ניתז על השכנים שלכם, וזו בדיוק הסיבה שמארחים זהירים לגביו. אם אתם מבקשים מאיתנו לפתוח 25, שמרו את השרת שלכם נקי, כי המוניטין שאתם מגנים עליו הוא חלקית גם שלנו.

למה ה-IP הייעודי אינו אופציונלי

כל זה חוזר לדרישה אחת: ה-IP חייב להיות שלכם. בהגדרת NAT או כתובת משותפת אתם לא יכולים להגדיר PTR משלכם, כי הכתובת אינה בלעדית שלכם להצביע עליה. אתם גם יורשים כל מוניטין שה-IP המשותף כבר נושא — ואין לכם מושג מה הדייר האחרון עשה איתו.

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

השורה התחתונה הכנה

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

אבל אם אתם רוצים שליטה אמיתית — הנתונים שלכם, הדומיין שלכם, אף אחד אחר לא קורא את הכותרות — זה מאוד ישים על VPS קטן. צנרת האמון למעלה היא בערך 90% מהקרב, ואף אחת מהן לא אקזוטית. השיגו IP ייעודי, הגדירו את ה-PTR שיתאים ל-hostname שלכם, פרסמו SPF/DKIM/DMARC, בקשו מאיתנו לפתוח פורט 25, ואז שלחו בדיקה דרך כלי כמו mail-tester.com ותקנו מה שהוא מסמן. עשו את זה ואתם כבר לא צועקים לתוך תיקיית ספאם — אתם שרת דואר שתיבות הדואר של אנשים באמת בוטחות בו.

שאלות נפוצות

האם אני צריך IP ייעודי כדי להריץ שרת דואר?

למעשה כן. deliverability תלוי ברשומת reverse DNS (PTR) שתואמת את ה-hostname של הדואר שלכם, ואתם יכולים להגדיר PTR רק על IP שהוא בלעדית שלכם. על כתובת משותפת או NAT אתם לא שולטים ב-PTR, אז שרתים מקבלים רואים hostname גנרי או לא-תואם ומתייחסים אליכם כחשודים. IP ייעודי הוא הבסיס לדואר יוצא.

מה זו רשומת PTR ולמה דואר צריך אותה?

רשומת PTR היא reverse DNS — היא ממפה את ה-IP שלכם בחזרה ל-hostname, ההפך מרשומת A רגילה. כשהשרת שלכם מתחבר ל-Gmail או Outlook, הצד המקבל בודק מי הבעלים של ה-IP שלכם. אם ה-PTR חסר או גנרי (כמו static.203-0-113-19.rev.example-isp.net), זו נקודה שלילית מיידית נגדכם. שרתי דואר מצפים שה-PTR יתאים לשם שהשרת שלכם מכריז ב-HELO.

למה פורט 25 יוצא חסום כברירת מחדל ברוב מארחי ה-VPS?

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

האם אני יכול להריץ שרת דואר על IP של NAT או משותף?

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

האם אחסון-עצמי של דואר באמת שווה את זה ב-2026?

זה תלוי למה. אם אתם רוצים שליטה על הנתונים והדומיין שלכם ללא צד שלישי בלולאה, זה מאוד ישים על VPS קטן. אבל deliverability הוא עבודה מתמשכת — אתם צופים ברשימות שחורות, מסובבים מפתחות DKIM, ושומרים את ה-IP נקי. לפרויקט צדדי בסיכון-נמוך, העברה דרך ספק קיים פחות כאב. אחסנו-בעצמי כששליטה חשובה יותר מנוחות.

← חזרה לבלוגראו תוכניות ומחירים →

תגובות

אין עדיין תגובות. היו הראשונים.

השאירו תגובה

התגובות עוברות מודרציה לפני שהן מופיעות.