מצב ה-DNS שלי לעולם אינו הופך לירוק

אימות DNS בודק את הרשומות הדרושות להגדרה שבחרתם. דומיין שמקבל דואר דרך TrekMail זקוק בדרך כלל ל-MX, SPF, DKIM ו-DMARC. רשומות מומלצות כגון MTA-STS ו-TLS-RPT עשויות להופיע בנפרד. מדריך זה עוזר להשוות בין לוח הבקרה לספק ה-DNS בלי לנחש.

התחילו בטבלת הרשומות בלוח הבקרה

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

לפני שינוי רשומה, בדקו אם שירות אחר עדיין זקוק לערך הקיים. בפרט, שמרו רשומת SPF אחת וכל include תקין שבו משתמש שירות שליחה אחר.

כמה זמן אמורה לקחת ההפצה?

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

פעלו בסדר זה:

1. שמרו את הרשומה אצל הספק שמארח את אזור ה-DNS המוסמך.
2. השוו לטבלת לוח הבקרה, כולל עדיפות MX וערך DKIM מלא.
3. השתמשו פעם אחת באימות DNS כדי לבקש בדיקה חדשה של TrekMail.
4. אם המצב נשאר בהמתנה, בדקו את פרטי ההתנגשות וחיפוש עצמאי של הערך הציבורי הנוכחי.

רשומות נדרשות

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

רשומות מומלצות משפרות את אבטחת המסירה, אך אינן מחליפות את רשומות הליבה:

רשומות CNAME אופציונליות להגדרת לקוח (autoconfig, autodiscover) מזרזות הגדרת יישומי דואר, אך אינן משפיעות על המסירה.

בדיקה 1: מיזוג רשומות SPF כפולות

רק רשומת TXT אחת בשורש צריכה להתחיל ב-v=spf1. אם יש שתיים, שרתי קבלה אינם יכולים לזהות את המדיניות ו-TrekMail אינו יכול לאמת כראוי.

תסמין: שתי הרשומות מופיעות ב-DNS, אך TrekMail עדיין מסמן ש-SPF לא הוגדר.

פתרון: מזגו את כללי השולח לרשומה אחת. אם יש לכם:

v=spf1 include:_spf.google.com ~all
v=spf1 include:spf.trekmail.net -all

החליפו ב:

v=spf1 include:_spf.google.com include:spf.trekmail.net -all

איזו סיומת להשתמש: -all או ~all

השתמשו רק באחת. שתיהן עוברות אם include:spf.trekmail.net מופיע לפניהן. הבחירה משפיעה על דואר שנשלח בשירותים אחרים.

הערת ייעוץ על הסיומת אינה כשל באימות. אפשר לאמת עם כל אחת.

אל תשתמשו ב:

• ?all, שאינו מספק מדיניות הרשאה שימושית.
• +all, שמאשר כל שולח באינטרנט.

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

בדיקה 2: CNAME של דואר ב-Cloudflare נמצא תחת proxy

Cloudflare יכול להעביר תעבורת אינטרנט, אך CNAME של דואר חייב להיות DNS בלבד. הדבר כולל mta-sts, autoconfig, autodiscover או מארח אחר שלוח הבקרה דורש.

תסמין: הרשומה מסומנת כחסומה או אינה ניתנת לאימות, אף שהיא ברשימת ה-DNS של Cloudflare.

פתרון: ב-Cloudflare פתחו DNS, מצאו את המארח ושנו את הענן הכתום למצב אפור DNS בלבד. לאחר מכן הפעילו אימות DNS ב-TrekMail.

רשומת A או CNAME הראשי של האתר יכולים להישאר תחת proxy. שנו רק את מארח הדואר שלוח הבקרה מציין.

בדיקה 3: DMARC נמצא במארח שגוי

DMARC שייך ל-_dmarc.yourdomain.com, לא לשורש הדומיין. טפסים מסוימים ממלאים מראש @, ולכן קל לשמור במקום שגוי.

תסמין: רשומת DMARC קיימת ב-DNS, אך TrekMail אינו מוצא אותה.

פתרון: הוסיפו אותה ב-_dmarc. ממשקים מסוימים מבקשים _dmarc ואחרים _dmarc.yourdomain.com. בדקו את רמז הטופס. הסירו רשומה שגויה ב-@ רק לאחר שאישרתם שאינה משמשת למטרה אחרת.

בדיקה 4: DKIM הודבק או פוצל באופן שגוי

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

"p=MIIBIjANBgkqhki..." "...continues here" "...and ends here"

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

תסמין: DKIM גלוי ב-DNS, אך TrekMail מציג "DKIM key invalid" או "p= does not match".

פתרון:

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

בדיקה 5: MTA-STS דורש טיפול

MTA-STS הוא מאפיין אבטחה מומלץ לדומיינים שמקבלים דואר דרך TrekMail. אם לוח הבקרה מציג אותו, דרושים TXT ו-CNAME בשם mta-sts המוצגים שם. אל תוסיפו אותם לדומיין לשליחה בלבד אלא אם לוח הבקרה מבקש זאת במפורש.

חסום על ידי DNS. ה-CNAME בשם mta-sts חסר או מצביע למקום אחר. הוסיפו או תקנו אותו לפי היעד הנוכחי בלוח הבקרה.

חסום על ידי Cloudflare. ה-CNAME קיים אך נמצא תחת proxy. הגדירו את המארח כDNS בלבד, כמתואר בבדיקה 2.

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

בדיקה 6: השוואת חיפוש ציבורי ללוח הבקרה

בזמן הפצה הרשת המקומית ו-TrekMail עשויים לראות תוצאות שונות. חיפוש ציבורי מראה מה רואות רשתות אחרות.

כדי להשוות:

1. פתחו את dnschecker.org או whatsmydns.net.
2. הזינו שם מארח מלא וסוג רשומה, למשל _dmarc.yourdomain.com ו-TXT עבור DMARC.
3. השוו את המארח, הערך ועדיפות MX לטבלת לוח הבקרה.
4. אם החיפוש מציג ערך נכון אך TrekMail עדיין מדווח על הבדל, צרפו את התוצאה לפניית תמיכה.

בדיקה 7: ערך DNS ישן עדיין במטמון

לאחר שינוי, הערך הישן יכול להישאר בפותרים מתווכים עד לתום ה-TTL (Time To Live, בשניות). TTL של 24 שעות (86400 שניות) נפוץ ברשומות ישנות.

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

פתרון: הימנעו מעריכות חוזרות בזמן שאותו שינוי מופץ. להעברה מתוכננת אפשר להנמיך TTL מראש אם הספק תומך. לאחר התייצבות בחרו TTL שמתאים לניהול הרגיל.

פתרון בעיות שלב אחר שלב

1. פתחו את דף הדומיינים ולחצו על הדומיין.
2. אם הצגת התנגשויות זמינה, פתחו אותה. היא מפרידה רשומות לתיקון מפריטים מומלצים ומידע.
3. השוו כל מארח, ערך ועדיפות MX צפויים לרשומה השמורה אצל הספק.
4. בצעו את השינוי הקטן ביותר הנדרש ושמרו רשומות ששירותים אחרים צריכים.
5. לחצו על אימות DNS ב-TrekMail.
6. קראו את המצב החדש. הדומיין פעיל כאשר הרשומות הנדרשות להגדרה שבחרתם תקינות; רשומות מומלצות יכולות להופיע בנפרד.

לבדיקה עצמית במסוף (Mac/Linux/WSL), השתמשו ב:

dig +short MX yourdomain.com
dig +short TXT yourdomain.com
dig +short TXT _dmarc.yourdomain.com
dig +short TXT dkim._domainkey.yourdomain.com
dig +short CNAME mta-sts.yourdomain.com

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

מלכודות נפוצות אצל ספקי DNS

• Cloudflare: רשומות CNAME של דואר חייבות להיות DNS בלבד. הספק עשוי להסתיר נקודה בסוף היעד; השוו את היעד שנפתר במקום להוסיף נקודות כפולות.
• GoDaddy: השתמשו ב-@ לשורש וב-_dmarc ל-DMARC. GoDaddy מוסיף את שם הדומיין בעצמו.
• Namecheap: הוסיפו רשומות ב-Advanced DNS רק אם Namecheap הוא ספק ה-DNS המוסמך. השתמשו ב-@ לשורש.
• Route 53: בחרו באזור המאוחסן שמחובר בפועל לדומיין והדביקו את כל ערך לוח הבקרה.
• בוני אתרים ורשמים: המקום שבו קניתם את הדומיין לא בהכרח מנהל DNS. בדקו שרתי שמות וערכו אצל הספק האחראי.

כאשר הכל תואם אך המצב עדיין אדום

אם לוח הבקרה וחיפוש ציבורי עצמאי מציגים אותן רשומות נדרשות אך TrekMail עדיין מדווח על הבדל, פתחו פנייה עם:

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

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