דילוג לתוכן
פינג

בדיקת רשומות דואר: MX, SPF, DKIM ו־DMARC

מקלידים דומיין ומקבלים בדיקה של כל רשומות הדואר שלו: לאן מגיע הדואר (MX), מי רשאי לשלוח בשמו (SPF), האם המיילים חתומים (DKIM) ומה שרתים עושים עם מייל מזויף (DMARC). לכל בעיה מופיע הסבר בעברית ומה לתקן.

אם תשאירו ריק, נבדוק selectors נפוצים של Google, Microsoft 365, Mailchimp ועוד.

פונה לשירות חיצוני. השאילתות נשלחות מהדפדפן שלכם ישירות לשרתי ה־DNS של Google ו־Cloudflare. רק אם שניהם לא זמינים, הן עוברות דרך השרת שלנו. שום דבר לא נשמר.

איך זה עובד

  1. מקלידים דומיין

    הדומיין שמופיע אחרי ה־@ בכתובת המייל, למשל example.co.il.

  2. מוסיפים selector של DKIM (לא חובה)

    אם לא יודעים מהו, נבדוק את הנפוצים: Google Workspace, Microsoft 365 ועוד.

  3. עוברים על הממצאים

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

למה מיילים מגיעים לספאם

מאז פברואר 2024 ג׳ימייל דורש מכל שולח לפחות SPF או DKIM, ומי ששולח יותר מ־5,000 הודעות ביום לחשבונות ג׳ימייל צריך SPF, DKIM וגם DMARC (אפילו במדיניות p=none). גם Yahoo פרסמה דרישות דומות.

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

מקורות: Google: הנחיות לשולחי דואר · Yahoo: דרישות לשולחים

SPF ומגבלת 10 השאילתות

רשומת SPF היא רשומת TXT אחת שמתחילה ב־v=spf1 ומפרטת אילו שרתים רשאים לשלוח בשם הדומיין. כל include, a, mx, ptr, exists ו־redirect גורם לשאילתת DNS נוספת, ויש מגבלה של 10 שאילתות כאלה, כולל אלה שבתוך ה־include.

מעבר ל־10 התוצאה היא permerror, ו־SPF מפסיק לעבוד לגמרי. זו טעות נפוצה אצל מי שמוסיף עוד ועוד שירותי שליחה. הכלי סופר את השאילתות לעומק ומראה מאיפה כל אחת מגיעה.

מקורות: RFC 7208: SPF, סעיף 4.6.4

DKIM: חתימה דיגיטלית על כל מייל

שרת השליחה חותם על כל הודעה במפתח פרטי, והמפתח הציבורי מתפרסם ב־DNS בכתובת selector._domainkey.domain. השרת המקבל בודק את החתימה ומוודא שההודעה לא שונתה בדרך.

מפתח RSA חייב להיות באורך 1024 ביט לפחות, ומומלץ 2048. בודקים DKIM לפי ה־selector, שמופיע בכותרות של מייל שנשלח מהדומיין (בשדה s= בכותרת DKIM-Signature).

מקורות: RFC 6376: DKIM · RFC 8301: אורך מפתח ואלגוריתמים

DMARC: מה קורה למייל מזויף

DMARC היא רשומת TXT בכתובת _dmarc.domain שאומרת לשרתים מה לעשות כשמייל נכשל ב־SPF וב־DKIM: none (רק לדווח), quarantine (לספאם) או reject (לדחות).

הדרך הבטוחה: מתחילים ב־p=none עם כתובת דיווח (rua), קוראים את הדוחות כמה שבועות, ורק כשכל השולחים הלגיטימיים עוברים, מחמירים ל־quarantine ואז ל־reject.

מקורות: RFC 7489: DMARC

שאלות נפוצות

מה זה רשומת SPF?

רשומת TXT בדומיין שמפרטת אילו שרתים רשאים לשלוח מייל בשמו. למשל v=spf1 include:_spf.google.com ~all אומרת שרק השרתים של Google Workspace רשאים לשלוח, וכל השאר חשודים.

איך יודעים מה ה־selector של DKIM?

פותחים מייל שנשלח מהדומיין, בוחרים "הצגת המקור" (Show original), ומחפשים את השורה DKIM-Signature. הערך שאחרי s= הוא ה־selector. ב־Google Workspace הוא לרוב google, וב־Microsoft 365 הוא selector1 או selector2.

אפשר שתי רשומות SPF?

לא. אם יש שתי רשומות שמתחילות ב־v=spf1, התוצאה היא permerror ושתיהן לא עובדות. מאחדים אותן לרשומה אחת עם כל ה־include.

מה ההבדל בין ~all ל־-all?

~all (softfail) אומר שמייל משרת אחר חשוד, ובדרך כלל הוא יסומן כספאם. -all (fail) אומר לדחות אותו. בפועל רוב השרתים מסתמכים על DMARC כדי להחליט, ושתי האפשרויות מקובלות.

מה זה Null MX?

רשומת MX עם נקודה בלבד (0 .) שאומרת שהדומיין לא מקבל דואר בכלל. זה שימושי לדומיינים שמשמשים רק לאתר, כדי ששולחים יקבלו דחייה מיידית במקום לחכות.

עוד כלים שיכולים לעזור

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