Defaults.Exposed › תיקונים › DMARC (הגנת זיוף דואר)

כיצד לתקן DMARC (הגנת זיוף דואר)

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

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

מה זה יכול לעלות לכם

• רמאי שולח ללקוח שלך חשבונית אמיתית-נראית 'מצוות החשבונות שלך' עם פרטי הבנק שלו. הלקוח משלם. אתה מגלה שבועות לאחר מכן כשהוא רודף אחרי הסחורה ששילם עבורה — והוא מחזיק אותך אחראי.
• מייל 'תשלום דחוף' מגיע לאיש הכספים שלך, כביכול ממך, הבעלים. הוא מעביר את הכסף לפני שמישהו חושב לבדוק — וברגע שהגיע לחשבון הפושע, כמעט אף פעם לא מחזירים אותו.
• צוות ה-IT של לקוח גדול מריץ בדיקת אבטחה על הדומיין שלך לפני החתימה. הוא חוזר 'הדואר לא מוגן — ניתן לזייף'. אתה מפסיד את העסקה למתחרה שעבר.
• הדומיין שלך משמש בגל פישינג. לקוחות שנרמו משאירים ביקורות כועסות ומזהירים אחרים. נזק המוניטין נמשך חודשים לאחר המתקפה.
• אפילו הדואר הלגיטימי שלך מתחיל להיסנן לספאם, כי Google ו-Yahoo מסתפקים יותר ויותר — ועכשיו לפעמים דוחים — דומיינים ללא מדיניות DMARC נאכפת.

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

מהו DMARC, בשפה פשוטה

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

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

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

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

מה זה יכול לעלות לך

זה לא תיאורטי. הנה הדרכים הממשיות שבהן דומיין לא מוגן הופך לכסף ונזק אמיתיים:

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

2. העברת כספים בהתחזות למנכ”ל. מייל נראה כאילו הגיע ממך, הבעלים, לאיש הכספים שלך: “תוכל לדחוף את התשלום הזה בדחיפות, אני בפגישה.” זה נראה לגמרי אמיתי כי זה הכתובת שלך — רק מזויפת. התשלום יוצא. דפוס זה — Business Email Compromise — הוא אחד ההונאות היקרות ביותר שפוגעות בעסקים קטנים, בדיוק כיוון שהמייל הגיע מהדומיין שלך, הוא עף ישר מעבר לחשד.

3. החוזה האבוד. לקוח פוטנציאלי רציני מריץ בדיקת אבטחה לפני החתימה. הכלים שלהם מדווחים שהדומיין שלך “ניתן לזיוף — ללא אכיפת אימות דואר”. דגל אדום בודד זה יכול להספיק כדי להעניק את החוזה למתחרה. לעולם לא שומעים את הסיבה האמיתית.

4. פגיעת המוניטין שאי אפשר לבטל. הדומיין שלך נסחף לקמפיין פישינג. עשרות אנשים שרומו בשמך מפרסמים אזהרות וביקורות. המתקפה נמשכת שבוע; השאלה “האם החברה הזו בטוחה בכלל?” נמשכת חודשים.

5. הדואר שלך הולך לספאם. Google ו-Yahoo כעת פועלים לפי חוסר אמון בדומיינים ללא DMARC נאכף. הצעות מחיר, חשבוניות ותשובות ששלחת בעצמך מתחילות בשקט לנחות בתיקיות הספאם. עסקאות נתקעות ואתה לא מבין למה.

מה זה בעצם (ומה נראה “טוב”)

DMARC נמצא כשורת טקסט אחת בהגדרות הדומיין שלך — רשומת DNS “TXT” שמפורסמת בשם המיוחד _dmarc.yourdomain. בתוכה יש כמה הוראות קצרות. שניים מהם חשובים ביותר, והם בדיוק שני הדברים שהערכה זו בודקת.

1. המדיניות (p=) — הוראות השומר. זהו החלק הנשא עיקר משקל הבדיקה. הוא יכול להיות אחד משלושה דברים:

• p=none — צפייה בלבד. השומר מציין מי עבר אבל לא עוצר אף אחד. זה לא מגן עליך כלל; זהו שלב ניטור, לא הגדרה גמורה. (המנוע שלנו מניקוד זה ככשל — טוב מ-DMARC ללא כלום, אבל לא הגנה.)
• p=quarantine — שלח מזויפים לספאם. הגנה אמיתית, אבל תוקף נחוש מחשב שאנשים יבדקו בתיקיית הספאם שלהם. צעד ביניים סביר — הוא מרוויח כחצי ניקוד.
• p=reject — סרב למזויפים בדלת. המייל המזויף לעולם לא מוגש. זוהי ההגדרה היחידה שמגינה עליך לחלוטין ומרוויחה ניקוד מלא.

מה נראה “טוב”: p=reject. כל פחות משאיר פרצה.

שני פרטים טכניים שהבדיקה שלנו גם בוחנת, שכדאי לדעת:

• מדיניות תת-הדומיין (sp=). אתה יכול להגדיר מדיניות חזקה לדומיין הראשי שלך אבל להשאיר בטעות תת-דומיינים (כמו mail.yourdomain או news.yourdomain) פתוחים לחלוטין. המנוע שלנו מעניש על זה בחומרה — דומיין עם p=reject אבל sp=none מקבל ניקוד נמוך קרוב לאין אכיפה כלל. תוקפים פשוט יזייפו תת-דומיין במקום. תרגול טוב הוא לאפשר ל-sp לרשת את המדיניות החזקה הראשית שלך, או להגדיר אותו ל-reject במפורש.
• האחוז (pct=). במהלך השקה זהירה אתה יכול להחיל אכיפה רק על חלק מהדואר (לדוגמה pct=25). זהו כלי מעבר לגיטימי, אבל השקה חלקית נותנת רק הגנה חלקית, והניקוד שלנו משקף זאת — הוא עולה בהדרגה כשאתה עובר מ-25% ל-100%, אבל ניקוד מלא צריך כיסוי מלא.

2. כתובת הדיווח (rua=) — הנראות שלך. זוהי הבדיקה השנייה בדף זה. התג rua= מבקש מכל ספק דואר בעולם לשלוח לך סיכום יומי של מי ניסה לשלוח דואר בשם הדומיין שלך — המערכות שלך וכל מתחזה. בלעדיו, אתה עף עיוור: אין לך מושג מי מנצל לרעה את שמך. עמו, עסקים מגלים בדרך כלל בין 5 ל-50 שולחים לא מורשים ביום הראשון ממש.

מה נראה “טוב” לדיווח: כתובת rua=mailto: חוקית (או כתובת https: של שירות דיווח) שבאמת מקבלת את הדוחות. הבדיקה שלנו מאמתת את הפורמט — כתובת עם שגיאת הקלדה או בפורמט שגוי פירושה שהדוחות הולכים לשום מקום בשקט, מה שמנגד לניקוד חלקי.

כיצד לתקן (חינם, ~30 דקות פרושות על שבועיים)

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

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

שלב 1 — ודא ש-SPF ו-DKIM קיימים תחילה. DMARC מסתמך עליהם. אם חסר אחד מהם, סדר אלה לפני אכיפת DMARC (ראה דפי SPF ו-DKIM).

שלב 2 — פרסם רשומת ניטור עם דיווח מופעל. הוסף רשומת DNS TXT:

• Host / name: _dmarc.yourdomain (ספק ה-DNS שלך עשוי להציג זאת פשוט כ-_dmarc)
• Type: TXT
• Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain; adkim=s; aspf=s

זה צופה ומדווח ללא חסימת כלום עדיין. חלקי adkim=s; aspf=s מבקשים יישור קפדני — השאר אותם בחוץ בהתחלה אם אינך בטוח, והוסף אותם לאחר שהדואר שלך מאושר כנקי.

שלב 3 — קרא את הדוחות למשך ~שבועיים. דוחות DMARC גולמיים הם XML דחוס. השתמש בשירות דיווח חינמי (לדוגמה dmarcian או כלי ה-DMARC החינמי של Postmark) כדי להפוך אותם ללוח מחוונים קריא. אשר שכל שולח לגיטימי — ספק תיבת הדואר שלך, כלי הניוזלטר, CRM, מערכת תמיכה, אפליקציית חשבוניות — עובר. תקן כל שולח לגיטימי שאינו עובר.

שלב 4 — עבור ל-quarantine. ברגע שהדואר האמיתי שלך נקי, שנה p=none ל-p=quarantine. צפה עוד כמה ימים.

שלב 5 — עבור ל-reject. לבסוף שנה p=quarantine ל-p=reject. אתה עכשיו מוגן לחלוטין. הרשומה הסופית נראית כך:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain; adkim=s; aspf=s

שלב 6 — אל תשכח תת-דומיינים. ודא שלא השארת sp=none בתוקף. אם לא תפרסם sp כלל, תת-דומיינים יורשים את מדיניות p= הראשית שלך, שזה מה שאתה רוצה.

הערות לפי פלטפורמה נפוצה:

• Google Workspace / Microsoft 365: שניהם תומכים ב-DMARC במלואו. רשומת DMARC עצמה נכנסת בספק ה-DNS שלך, לא בלוח הניהול של Google או Microsoft — ודא ש-SPF ו-DKIM מופעלים בלוח הניהול תחילה, ואז פרסם את רשומת ה-TXT של DMARC ברשם/מארח ה-DNS שלך.
• Cloudflare: DNS > Records > Add record > TXT, name _dmarc, הדבק את הערך. Cloudflare מציע גם ניהול DMARC מובנה שיכול להגדיר זאת ולאסוף את הדוחות עבורך.
• מארחים/רשמים נפוצים (Blacknight, GoDaddy וכו’): חפש “DNS”, “DNS Zone”, או “Advanced DNS”, הוסף רשומת TXT עם name _dmarc והערך לעיל. הפצה לוקחת בדרך כלל כמה דקות עד שעה.

טעויות נפוצות

• עצירה ב-p=none. הטעות הנפוצה ביותר בהרבה. ניטור הוא ההתחלה, לא הסיום — דומיין תקוע ב-none עדיין ניתן לזיוף לחלוטין. המנוע שלנו מניקוד זה ככשל בדיוק מסיבה זו.
• קפיצה ישירה ל-reject ללא ניטור. הטעות ההפוכה. ללא שלב הדיווח ייתכן שלא תבחין ששולח לגיטימי (לעתים קרובות ניוזלטר או כלי חשבוניות) אינו מיושר — ותתחיל לחסום את הדואר שלך.
• שכחת מדיניות תת-הדומיין. p=reject חזק עם sp=none משאיר דלת צדדית פתוחה לרווחה; תוקפים פשוט יזייפו תת-דומיין במקום.
• כתובת דיווח שבורה. rua= עם שגיאת הקלדה (או אחד שחסר קידומת mailto:) פירושו שהדוחות הולכים לשום מקום ואתה נשאר עיוור בלי לדעת. הפורמט חייב להיות mailto: או https: URI חוקי, או שהדוחות לעולם לא מוגשים.
• “אנחנו לא שולחים דואר אז נדלג.” דומיין לא-שולח הוא יעד עיקרי בדיוק כי אף אחד לא צופה בו. פרסם מדיניות reject קפדנית כדי לנעול אותו לחלוטין.

הערה על ניקוד

בדיקת המדיניות (p=) היא אחת הפריטים עם המשקל הגבוה ביותר בכל ההערכה — כי היא הגורם הבודד הגדול ביותר האם ניתן להתחזות לעסק שלך. reject מרוויח את הניקוד המלא; quarantine מרוויח כחצי; none ורשומה חסרה מנוקדות ככשלים. מדיניות תת-דומיין חלשה יותר או השקה חלקית pct= מורידות את הניקוד כדי להתאים לרמת ההגנה האמיתית שיש לך.

בדיקת הדיווח (rua=) נושאת גם משקל אמיתי, אבל חשוב עליה פחות כתיבת סימון ויותר ככלי שמאפשר לך להגיע ל-reject בבטחה. הגדר אותה באותה הזמן כמו הרשומה הראשונית שלך, והיא תשתלם בנראות מהיום הראשון.

הגדירו זאת אצל ספק האחסון שלכם

שלב אחר שלב עבור ספקים פופולריים:

• הגדירו DMARC ב-GoDaddy
• הגדירו DMARC ב-Namecheap
• הגדירו DMARC ב-Cloudflare
• הגדירו DMARC ב-Google Workspace
• הגדירו DMARC ב-Microsoft 365
• הגדירו DMARC ב-Squarespace
• הגדירו DMARC ב-Wix
• הגדירו DMARC ב-AWS Route 53
• הגדירו DMARC ב-Hostinger
• הגדירו DMARC ב-Porkbun
• הגדירו DMARC ב-IONOS
• הגדירו DMARC ב-Bluehost

שאלות נפוצות