Defaults.Exposed › תיקונים › Reverse DNS (PTR)
כיצד לתקן Reverse DNS (PTR)
Reverse DNS הוא תג הזיהוי של השרת ששולח את דואר העסק שלך. כשספק מקבל כמו Gmail או Microsoft 365 מחפש מי מאחורי כתובת השולח ומקבל שם שעומד בבדיקה, הדואר שלך נראה לגיטימי. כשאין תג — או שהשם והמספר אינם מסכימים — החשבוניות וההצעות האמיתיות שלך מטופלות כחשודות ונזרקות לספאם בשקט.
השורה התחתונה לעסק שלכם: החשבוניות, ההצעות ותשובות הלקוחות שלך נוחתות בשקט בספאם או לא מגיעות כלל — כך שעסקאות נתקעות, תשלומים מגיעים מאוחר, ולקוחות חושבים שהתעלמת מהם, ואף אחד מהדברים האלה לא מופיע כשגיאה שתבחין בה.
מה זה יכול לעלות לכם
- אתה שולח הצעת מחיר ללקוח פוטנציאלי חם, היא נופלת לספאם שלו, והוא הולך למתחרה שבאמת 'ענה' — ואתה אף פעם לא ידעת שהמייל לא נחת.
- חשבוניות ללקוחות נעלמות לזבל, תשלומים מגיעים שבועות מאוחר, ותזרים המזומנים שלך לוקח את הפגיעה כי אף אחד מעולם לא ראה את המייל.
- לקוח מתלונן שמעולם לא ענית לו — אבל ענית; ספק הדואר שלו השמיד בשקט את תגובתך כי שרת השליחה שלך לא יכול היה להוכיח מי הוא.
- הדומיין שלך עובר ביקורת אבטחה של לקוח חדש על הכל, ואז מסומן כי לשרת הדואר שלך אין זהות תקינה — דבר קטן שגורם לך להיראות רשלני.
- עברת ל-VPS זול או לאפליקציה חדשה לשליחת ניוזלטרים וחשבוניות, ובן לילה שיעור המסירה שלך צנח — כי לשרת השליחה החדש אין תג Reverse DNS וספקים גדולים כבר לא סומכים עליו.
מדוע זה חשוב. כל ספק דואר גדול בודק את זהות השרת ששולח את הדואר שלך, ובודק על כל הודעה. אם אותו שרת לא יכול להוכיח מי הוא — או אם שמו ומספרו סותרים זה את זה — הדואר העסקי הלגיטימי שלך מטופל כאילו הוא עשוי להיות ספאם. אתה מפסיד תשובות, תשלומים ואמון, וכיוון שלא הגיע שום דבר חזרה, בדרך כלל לא תגלה למה.
הגרסה הקצרה
כשהעסק שלך שולח מייל, הוא יוצא משרת דואר, ולכל שרת באינטרנט יש כתובת מספרית — ה-IP שלו. Reverse DNS (רשומת “PTR”) הוא תג השם של אותו שרת: הוא מאפשר לכל מי שרואה את המספר לחפש את השם התקין מאחוריו, כמו mail.yourcompany.com.
ספקי הקבלה הגדולים — Gmail, Microsoft 365, Yahoo — בודקים את התג הזה על כל הודעה שאתה שולח. שרת שיכול לתת שם לעצמו, ושהשם והמספר מסכימים זה עם זה, נראה כמו שרת דואר לגיטימי. שרת ללא תג, או עם תג שאינו תואם, נראה בדיוק כמו מכונות השימוש-וזריקה האנונימיות שמשתמשים בהן שולחי ספאם. כך החשבוניות וההצעות האמיתיות שלך מתחילות כל שיחה תחת חשד — והרבה מהן מפסידות.
החלק המתסכל הוא שלא מודיעים לך שזה קורה. אין חזרה, אין שגיאה. הדואר שלך פשוט מתפקד בצורה חלשה בשקט.
מה זה יכול לעלות לך
אלה הדרכים היומיומיות שבהן רשומת reverse-DNS חסרה או לא תואמת הופכת לכסף ואמון שיוצאים מהדלת.
- ההצעה שלא נחתה. אתה שולח הצעת מחיר מפורטת ללקוח פוטנציאלי שביקש אותה אותו בוקר. הספק שלו לא יכול לאמת את שרת השליחה שלך, כך שהוא מוריד את ההודעה לספאם. הם לא חופרים בזבל. אחרי הצהריים הם קיבלו את ההצעה של המתחרה — זאת שבאמת “הגיחה”. אתה מחשיב זאת כליד איטי; במציאות המייל שלך מעולם לא נראה.
- החשבונית בחלל. אתה מחייב לקוח טוב. הוא נוחת בתיקיית הזבל שלו. שלושים יום לאחר מכן אתה רודף אחרי תשלום שפגות תאריכו ללא אשמת אחד מהם — ועכשיו יש שיחה מביכה, קשר מתוח, ופגיעה בתזרים מזומנים שהייתה לחלוטין ניתנת למניעה.
- “מעולם לא ענית.” לקוח כועס שהתעלמת מהשאלה שלו. לא עשית — ענית באותו יום. ספק הדואר שלו השמיד בשקט את תגובתך כי שרת השליחה שלך נראה לא אמין. אתה נראה לא מקצועי על משהו שעשית נכון.
- שרת השליחה ה-DIY שרעם הכל בשקט. כדי לחסוך כסף, הדואר שלך (או רק הניוזלטרים והחשבוניות האוטומטיות שלך) התחיל לצאת דרך VPS זול או אפליקציית שליחה חדשה. לשרת הזה מעולם לא הייתה תג Reverse DNS. בן לילה, שיעור המסירה שלך שקע — וכיוון שאין הודעת שגיאה, לקח חודשים אפילו לחשוד בסיבה.
- הסימון בביקורת האבטחה. צוות ה-IT של לקוח גדול מריץ בדיקה שגרתית בדומיין שלך בזמן הקליטה. כל השאר בסדר, אבל לשרת הדואר שלך אין זהות תקינה. זה נקודה טכנית קטנה, אבל היא נקראת כרשלנות — ועכשיו אתה מתקן אותה תחת לחץ מועד, או מסביר אותה, כשהדומיין של מתחרה עבר בלי בעיות.
החוט: העלות נוחתת עליך, היא בלתי נראית בזמן שמתרחשת, והתיקון חינמי.
מה זה בעצם
DNS רגיל הופך שם למספר: אתה מקליד yourcompany.com, ו-DNS נותן בחזרה את כתובת ה-IP להתחבר אליה. Reverse DNS עושה את ההפך — הוא הופך מספר בחזרה לשם. בהינתן ה-IP 203.0.113.10, בדיקת reverse (רשומת “PTR”) עונה mail.yourcompany.com.
למה מקבלים אכפת: כששרת הדואר שלך מתחבר ל-Gmail כדי לספק הודעה, Gmail רואה את ה-IP המתחבר. הדבר הראשון שמסנן דואר רציני עושה הוא לשאול “מי המכונה הזו?” — על ידי ביצוע בדיקת reverse על אותו IP. שרת דואר עסקי אמיתי יש לו תשובה (mail.yourcompany.com). למכונת ספאם חד-פעמית בדרך כלל אין, או שיש לה שם כללי שהספק נותן כמו host-203-0-113-10.someisp.net. כך נוכחות ואיכות התג הם אחד מאותות האמון הראשונים המוחלים על הדואר שלך — לפני SPF, DKIM, או תוכן ההודעה אפילו מקבלים הזדמנות.
הוא בודק את שרת הדואר, לא האתר שלך. זה מבלבל אנשים. כתובת האתר שלך לעתים קרובות מאחורי CDN או proxy (כמו Cloudflare) ולעולם לא יהיה לה תג תואם — וזה בסדר, כי Reverse DNS לדואר הוא על ה-IP של שרת הדואר MX, מכונה שונה לחלוטין.
החצי שרוב ההגדרות מבצעות בטעות: חייב לתאום בשני הכיוונים. קיום שם אינו מספיק לבדו. Gmail וספקים גדולים אחרים עושים משהו מחמיר יותר, שנקרא forward-confirmed reverse DNS (FCrDNS):
- חפש את ה-IP → קבל שם (לדוגמה
mail.yourcompany.com). - עכשיו חפש את השם הזה בחזרה → הוא חייב להצביע לאותו IP ממנו התחלת.
אם שני הכיוונים מסכימים, השרת מאושר ונאמן לחלוטין. אם יש שם אבל הוא מצביע למקום אחר (או לשום מקום), השרת נאמן רק חצי — תג שאינו עומד בבדיקה שנייה נחשב חלש יותר ממה שתקווה. PTR שמצביע לשם שתוקף שולט בו ולא מצביע בחזרה, הוא במובן מסוים גרוע יותר ממיעדר PTR כלל.
כך הבדיקה הזו מניקוד:
- Forward-confirmed (FCrDNS): ה-IP מציין מארח, ואותו מארח מצביע בחזרה לאותו IP. ניקוד מלא — זוהי תצורה נכונה, וזה מה שמקבלים סומכים עליו.
- תג קיים אבל לא מאשר: יש רשומת PTR, אבל השם אינו מצביע בחזרה ל-IP של שרת הדואר. אשראי חלקי בלבד — נראה מוגדר אבל הסינונים הגדולים לא יאמינו בו לחלוטין.
- אין תג בכלל: אין רשומת PTR ב-IP של שרת הדואר. ללא אשראי, ועלות המסירה אמיתית.
כיצד לתקן (חינם, ~10 דקות מזמן מישהו)
מסור חלק זה למי שמחזיק בכתובת ה-IP של שרת הדואר שלך — בדרך כלל ספק הדואר או האירוח שלך — ושים לב שהתיקון חינמי. זוהי הגדרת הדואר האחת שכמעט בוודאות אינך יכול לשנות בעצמך בלוח ה-DNS הרגיל שלך, כי Reverse DNS נשלט ע”י מי שמחזיק ב-IP, לא ע”י מי שמחזיק בדומיין.
שלב 1 — מצא את ה-IP של שרת הדואר השולח. זהה את מארח ה-MX הראשי של הדומיין (שרת הדואר עם מספר ה-priority הנמוך ביותר) ופתור אותו ל-IP שלו:
dig MX yourcompany.com # מצא את מארח ה-MX הראשי (priority נמוכה ביותר)
dig A mail.yourcompany.com # פתור את המארח ל-IP שלו
ה-IP הזה הוא זה שצריך את התג. אל תשתמש ב-IP של האתר — זוהי מכונה שונה ולעתים קרובות מאחורי CDN שלעולם לא יתאים.
שלב 2 — בקש ממחזיק ה-IP להגדיר את רשומת PTR. Reverse DNS נמצא עם מי שמשלט בבלוק ה-IP, כך שהבקשה הולכת ל:
- Google Workspace / Gmail: מנוהל אוטומטית לשרתי Google עצמם.
- Microsoft 365: כמו כן מנוהל אוטומטית לשרתי Microsoft.
- שרת דואר שמתארח בעצמו או VPS: פתח כרטיס אצל ספק האירוח שלך ובקש שיגדיר PTR (Reverse DNS) עבור ה-IP שלך לשם מארח הדואר שלך.
- אפליקציית שליחה של צד שלישי (ניוזלטר / חשבוניות / CRM): אם הוא שולח משרתים משותפים שלו, הספק מטפל ב-Reverse DNS — אין לך מה להגדיר.
אמור להם את הרשומה שאתה רוצה, לדוגמה: 203.0.113.10 → mail.yourcompany.com.
שלב 3 — הפוך לforward-confirmed (זהו השלב שרוב האנשים מפספסים). שם המארח ב-PTR חייב גם להצביע בחזרה לאותו IP דרך רשומת A רגילה שאתה שולט בה ב-DNS שלך:
- ה-PTR אומר
203.0.113.10→mail.yourcompany.com(הספק שלך מגדיר זאת). - רשומת ה-A אומרת
mail.yourcompany.com→203.0.113.10(אתה מגדיר זאת ב-DNS שלך, לדוגמה Cloudflare → DNS → הוסף רשומתA, Namemail, content203.0.113.10).
שני הכיוונים חייבים להצביע זה לזה. רק אז הוא forward-confirmed ונאמן לחלוטין.
שלב 4 — בדוק מחדש את הדומיין שלך. אשר ששרת הדואר עכשיו מציג Reverse DNS מאושר forward ושהבדיקה עוברת. שינויי DNS מופצים בתוך דקות עד כמה שעות.
טעויות נפוצות
- הגדרת התג ב-IP של האתר במקום שרת הדואר. Reverse DNS לדואר הוא על שרת ה-MX. הצבת PTR בכתובת ה-web/CDN שלך לא עושה דבר למסירה — המכונה הלא נכונה מקבלת את התג.
- עצירה ב-”ה-PTR קיים.” שם לבד מרוויח אמון חלקי בלבד. אם הוא לא מצביע בחזרה לאותו IP, הסינונים המחמירים (Gmail, M365, Yahoo) לא יאמינו בו לחלוטין. תמיד השלם את ה-forward-confirmation (שלב 3).
- שכחת רשומת ה-A לאחר שהספק מגדיר את ה-PTR. הספק מגדיר את החצי ה-reverse; אתה חייב להגדיר את החצי ה-forward ב-DNS שלך. אנשים עושים אחד ומניחים שסיימו.
- פנייה לגורם הלא נכון. שליחת הבקשה לרשם הדומיין שלך או למארח ה-DNS במקום למחזיק ה-IP מביאה “לא יכולנו לעשות זאת” — כי הם באמת לא יכולים. היא חייבת ללכת למי שמחזיק ב-IP.
- שמות מארח גנריים של ספקים. PTR כמו
host-203-0-113-10.someisp.netקיים טכנית אבל לא עושה דבר למותג שלך או לאמון. השתמש בשם מארח אמיתי בדומיין שלך שמאשר forward.
היכן זה מתאים
Reverse DNS הוא זהות השרת; SPF, DKIM ו-DMARC הם שכבת האישור ונגד-ההתחזות של הדומיין. הם עונים על שאלות שונות, והספקים הגדולים בודקים את כולם. SPF מפרט אילו שירותים רשאים לשלוח בשמך; DKIM חותם קריפטוגרפית את ההודעות שלך כדי שלא ניתן לשנות אותן; DMARC קושר את השניים יחד ואומר למקבלים מה לעשות עם דואר שנכשל — ומגן על שם ה’מאת’ הגלוי שהלקוחות שלך בעצם רואים. Reverse DNS יושב מתחת לכולם, מעיד שהמכונה שמבצעת השליחה היא שרת דואר אמיתי ומוגדר מלכתחילה. כל התיקונים האלה חינמיים.
שאלות נפוצות
אני לא טכני — האם אני יכול לטפל בזה בעצמי?
בדרך כלל לא, וזה בסדר. בניגוד לרוב הגדרות הדואר, הגדרה זו אינה משתנה ב-DNS שלך — היא נקבעת ע"י מי שמחזיק בכתובת האינטרנט (ה-IP) של שרת הדואר שלך, שהוא ספק הדואר או האירוח שלך. תפקידך הוא פשוט להעביר להם את חלק 'כיצד לתקן'. זהו שינוי מהיר מצדם, וזה חינמי.
אם אני משתמש ב-Google Workspace או ב-Microsoft 365, האם אני כבר מכוסה?
כמעט בוודאות כן — שניהם מנהלים Reverse DNS אוטומטית לשרתי הדואר שלהם, כך שדומיין ששולח דרכם בלבד עובר זאת ללא שתצטרך לעשות דבר. אם הבדיקה שלנו עדיין מסמנת אותו, זה כמעט תמיד אומר שחלק מהדואר שלך יוצא דרך שרת שונה (הקופסה שלך, VPS זול, או אפליקציית שליחה של צד שלישי), ואותו שרת חסר את התג שלו. חלק התיקון מסביר עם מי ליצור קשר.
האם תיקון זה עלול לשבור את הדואר שלי?
לא. זה רק מוסיף או מתקן את רשומת הזהות של שרת השליחה — הוא לא משנה לאן הדואר שלך הולך, מי מורשה לשלוח אותו, או אף אחת מהגדרות תיבת הדואר הנכנסת שלך. הוא פשוט גורם לדואר שאתה כבר שולח להיות יותר סביר שייאמן ויוגש.
מה ההבדל בין זה ל-SPF, DKIM ו-DMARC?
אלו השלושה עונים 'האם הדומיין הזה מורשה לשלוח הודעה זו?' Reverse DNS עונה על שאלה שונה, מוקדמת יותר: 'האם המכונה שמבצעת השליחה היא שרת דואר אמיתי וניתן לזיהוי, או קופסה אנונימית?' ספקים גדולים בודקים את שניהם. אתה רוצה שכולם יהיו נכונים — אבל Reverse DNS הוא זה שתופס שרת שליחה חדש או שמתארח בעצמו לפני ש-SPF ו-DKIM אפילו מגיעים לשחק.
יש לנו רשומת Reverse DNS אבל הבדיקה עדיין לא עוברת לחלוטין — למה?
כי קיום שם אינו מספיק; השם חייב לעמוד בשני הכיוונים. התג אומר ששרת נקרא, נניח, mail.yourcompany.com — אבל Gmail אז מחפש את השם הזה ומצפה שיצביע ישירות בחזרה לאותו IP. אם הוא לא עושה זאת (או מצביע למקום אחר), הספקים מתייחסים אליו כבלתי מאושר. התאמה דו-כיוונית זו נקראת forward-confirmed reverse DNS, וזה החלק שרוב ההגדרות מפספסות.
האם התיקון באמת חינמי, או שזה מכירה בתשלום?
התיקון תמיד חינמי — זהו שינוי קטן בתצורה שהספק שלך מבצע, לא מוצר שאתה קונה. מי שאומר לך שהגדרת Reverse DNS דורשת תוכנית בתשלום טועה. אנחנו גובים תשלום רק לניטור שהוא נשאר נכון לאורך זמן, לעולם לא לביצוע השינוי.