הרשמה לניוזלטר

    כל השדות הם חובה למילוי

    חזרה לעמוד הקודם

    שימוש ב-DNS כנגד התחזות בדוא"ל

    מבוא

    דיוג (phishing) היא שיטה להונאת משתמשים ברשת האינטרנט. גורם זדוני מנסה להתחזות לאתר אינטרנט, לכתובת דוא"ל או שירות רשת שאינם בבעלותו. תוך הצגת מצג שווא בכסות הנראית אותנטית, הוא מפתה את המשתמשים להאמין למידע שהוא מספק. מטרת התקיפה היא בדרך כלל לדלות מהם מידע סודי כגון מספר כ.אשראי, קוד סודי, סיסמאות, וכו'.
    התופעה אינה מוגבלת לעולם העסקי או הכלכלי, והיא קיימת בכל מקום בו קיים אינטרס ומידע מוגן: פרסום, פוליטיקה, איסוף מידע אישי למאגרי מידע וכו'.

    מסיבות היסטוריות, פרוטוקול הדואר האלקטרוני (SMTP) מכיל חולשה מובנית – היעדר מנגנון אימות הצד השולח. גורמים זדוניים מנצלים לרעה את היעדר ההגבלות על כתובתו של השולח, והמשמעות היא שלשדה "from" (אשר עבור רוב המשתמשים משמש לזיהוי השולח), ניתן להזין כל כתובת דואר, ובכך להטעות את הנמען.

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

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

    בהתאמה, גם ספק שירות הדוא"ל הנכנס ירצה להגן על המשתמשים שלו (הנמענים), ולכן גם הוא ירצה לצרוך מידע שיאפשר לוודא מהימנות הדוא"ל הנכנס.

    שלוש המתודולוגיות נקראות:  DMARC, DKIM, SPF

    שלושתן עושות שימוש בתשתית ה-DNS (ר"ת של Domain Name System) לפרסום המידע הנ"ל, ובאמצעותו מאפשרות:

    • לציין מהם שרתי הדואר המורשים לשלוח דוא"ל מהדומיין האמור (SPF).
    • לפרסם מפתח קריפטוגרפי שבאמצעותו ניתן לאמת דוא"ל חתום (DKIM).
    • להגדיר מדיניות תגובה במקרה של חריגה או בעיה (DMARC).
    Sender Policy Framework - SPF

    SPF הינו מנגנון המאפשר לוודא כי שרת דואר אשר שולח מייל ב-domain name מסוים, הוא אכן שרת שאושר ע"י מחזיקו החוקי של שם המתחם הנ"ל. זהו מנגנון נפוץ וקל ליישום. ניתן לממש אותו באופן די מיידי ובכך להגדיל את רמת המהימנות של דברי דוא"ל הנשלחים מהארגון.

    מחזיק של domain name, ממנו נשלח דוא"ל, ירצה לפרסם את רשימת השרתים המורשים לשלוח דוא"ל בשם המתחם שלו:

    • פרסום המידע נעשה באמצעות תשתית DNS.
      יש להוסיף לשרת ה- DNS שמחזיק את ה-domain name המדובר, רשומה שבה מופיעים כל השרתים המורשים לשלוח עבורו דוא"ל. רשומת DNS כזאת היא מטיפוס TXT: זוהי רשומה עם שדה טקסט חופשי. התוכן והמבנה המותרים בשדה הטקסט מוגדרים ב- RFC7208.
    • מנגנון SPF בודק את הכתובת המופיעה במעטפת המייל (שדה return-path או envelope from). שרת הדואר הנכנס, בעת הגעת הודעה חדשה, מבצע שאילתה לשרת ה-DNS המחזיק את ה-domain name  של הכתובת הנ"ל.
    • בתשובה, אמורה לחזור רשומה עם רשימת שרתי הדוא"ל המותרים עבור ה-domain name המדובר.
    • אם השרת השולח לא מופיע בתשובה, יש להתייחס למייל הנכנס בחשד.

    מימוש SPF

    רשומת SPF ניתן לייצר בקלות במגוון אתרים. דוגמא: https://mxtoolbox.com/spf.aspx

    עבור שם המתחם example.com, הרשומה יכולה להיראות כך :

    example.com TXT "v=spf1 a mx ip4:xxx.xxx.xxx.xxx include:mail.service.com -all”

    מבנה (משמאל לימין):

    • שם המתחם: example.com
    • טיפוס (type): רשומה מסוג TXT
    • תוכן:
      • V מגדיר את גרסת SPF. נכון להיום – גרסה 1: V=spf1
      • רשימת שרתי הדוא"ל המותרים: (אחד או יותר הבאים)
        • כל A Record או MX Record שכבר קיימים באותו שם-מתחם
        • כתובת IPv4 ו/או IPv6 אחת או יותר. ניתן לספק גם טווח, למשל: x.x.x.0/24
        • אחרי תגית "include", שם של שרת אחר . בדוגמא הנ"ל mail.service.com
        • לכל השאר… (כל מה שלא הוגדר):
          all – כל כתובת אחרת תכשל.
          all ~ כל כתובת אחרת תתועד כאסורה אבל תעבור (Soft fail)

    הערות:

    1. רשימת השרתים המרכיבה את שדה הטקסט, היא במתכונת דומה להגדרת FW, כלומר- ברגע שיש התאמה היא מתבצעת.
      המילה השמורה "all" בסוף הרשימה מייצגת את כל מה שלא נלכד לפני כן.
    2. הצירוף של הסימן – או ~ עם המילה "all" הינו למעשה אחד מארבע אפשריים שניתן לצרף לכל אחד מהערכים בשדה התוכן:
      • סימן + (פלוס)
        משמעות: PASS. הערך/ הכתובת שאחריו מאופשרת. זהו ערך ברירת מחדל, והוא מצורף דיפולטיבית לכולם אלא אם צויין אחרת.
      • סימן – (מינוס)
        משמעות: FAIL. לא לאפשר דוא"ל מהערך שאחריו.
      • סימן ~ (טילדה)
        משמעות: SOFT FAIL. לאפשר גם במקרה כישלון, לצורך בדיקות.
      • סימן ? (שאלה)
        משמעות: NEUTRAL. לא ליישם שום מדיניות על הכתובת/ הערך שאחרי.
    3. לכל domain name יש לוודא שקיימת רשומה אחת בלבד עבור SPF. קיומן של רשומות נוספות עלולה ליצור בעיות חוסר אחידות בתשובות. הוספה / שינוי ערכים צריך להתבצע על הרשומה הקיימת או במקומה.
    4. עלולים להיות כשלונות בהעברת דוא"ל בתצורת server-based forwarding ללא שינוי כתובת השולח לזו של מי שהעביר, אם מדיניות SPF הוגדרה כ: all- (מדיניות FAIL).
    Domain Keys Identified Mail - DKIM

    DKIM הינו מנגנון המאפשר אימות הודעת דוא"ל באמצעות חתימה דיגיטלית.

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

    חתימה של קלט כלשהו הינו תהליך המורכב משלושה שלבים:

    • חילול זוג מפתחות חתימה – פרטי וציבורי. זוהי פעולה חד פעמית, שלאחריה יש לחדש את המפתחות תקופתית. המפתח הפרטי משמש לביצוע החתימה ולכן יש לשמור עליו בסוד. לחילופין, את המפתח הציבורי יש לפרסם ברבים כיוון שהוא נחוץ לתהליך הפענוח.
    • אלגוריתם חתימה – על הקלט שאותו רוצים לחתום מופעלת פונקצית גיבוב (Hash function). התוצאה שמתקבלת עוברת לשלב הבא – הצפנתה באמצעות המפתח הפרטי. התוצאה המתקבלת משתי הפעולות הנ"ל היא חלק אחד של החתימה, החלק הקריפטוגרפי. אליו מצרפים את הקלט המקורי (לפני שנחתם) ואת סוג פונקצית הגיבוב שבה נעשה שימוש. כל אלה מרכיבים את החתימה הדיגיטלית.
    • אלגוריתם פיענוח – הצד המפענח מבצע:
      • מפעיל את אותה פונקצית גיבוב על הקלט המקורי (שניהם ידועים כיוון שהם מצורפים לחתימה).
      • באמצעות המפתח הציבורי מפענח את החלק הקריפטוגרפי (שהוצפן ע"י המפתח הפרטי).
      • התוצר של שתי הפעולות הנ"ל צריך להיות זהה. אם זה כך, החתימה תקינה.

    עקרון השימוש ב- DKIM:

    משלוח:

    • הודעות דואר יוצא נחתמות בשרת הדוא"ל החיצוני של הארגון, החשוף לעולם (בדרך כלל שרת mail relay). עליו מותקנת תוכנת חתימה ייעודית (כפי שיורחב בהמשך).
    • הקלט שנחתם הוא שדות בכותרת (header) של הודעת הדוא"ל הנשלחת.
    • בשרת ה-DNS אשר מחזיק את שם המתחם של השולח, צריכה להימצא רשומה ייעודית. בדומה ל- SPF גם רשומה זו היא מטיפוס TXT, כמתואר ב- RFC6376. הרשומה תכיל את החלק הציבורי של המפתח החותם על דואר יוצא.

    קבלה:

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

    מימוש DKIM

    1. חילול זוג מפתחות RSA אפשרי בכמה דרכים:
      • עצמאית במערכת ההפעלה.
        • בסביבת חלונות: ניתן לחולל מפתח באמצעות PuTTYgen
          מדריך כאן: https://winscp.net/eng/docs/ui_puttygen
        • בסביבת לינוקס: מגוון דרכים, למשל באמצעות openssl

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

    ייצור רשומת DNS (פרסום המפתח הציבורי)

      • המפתח הציבורי מפורסם באמצות רשומה מטיפוס TXT אשר מורכבת משם המתחם השולח (עם שינויים אשר יפורטו להלן), ומידע נוסף אותו מעוניינים לפרסם. מידע זה מכיל מספר שדות רשות, ושדה אחד חובה – שדה המפתח הציבורי.
      • את הרשומה ניתן לייצר באתרי אינטרנט ייעודיים (דוגמת האתר שהוזכר בסעיף 1 לעיל)

    דוגמא:
    רשומת DNS של מפתח ציבורי בשם "key1" עבור שם המתחם example.com תיראה כך:

    רשומת DNS של מפתח ציבורי בשם "key1"

      • בכל domain name ניתן להגדיר מספר מפתחות. כל מפתח = רשומת DNS ייעודית.
        שמה של הרשומה הוא הערך המבדיל אותה. הוא מורכב מערך שנקרא "סלקטור" (שהוא שם שרירותי, אך ייחודי של המפתח) + ערך קבוע שנקרא domainkey_
        כפי שניתן לראות בדוגמה, שמה של הרשומה הוא sub domain, שתי רמות תחת שם המתחם המקורי. במקרה הנ"ל שם המפתח (הסלקטור) הוא "Key1", וה- subdomain המתקבל הוא: key1._domainkey.example.com
      • שדה ה- TXT ברשומת DKIM מכיל את המידע אותו רוצים לפרסם. הוא מורכב מתגיות כדלהלן:
        • תגית חובה – P, מכילה את המפתח הציבורי.

    השאר הן תגיות רשות. אלא אם מציינים אחרת, יש להן ערכים ברירת מחדל (default) כמפורט:

        • תגיות מומלצות:
          • תגית V: גרסת DKIM. כיום הגרסה היא DKIM1. התגית נחשבת רשות אולם מומלץ מאוד לכלול אותה בראש הרשימה.
          • תגית t: תצורת בדיקת החתימה כפי שמחזיק שם המתחם מגדיר
            • t=s מציין "strict" המשמעות היא שחייבת להיות התאמה בין שמות הדומיינים בכותרת המייל ובשדה המתאים בחתימה.
            • t=y מגדיר כי DKIM נמצא במצב בדיקות. זה משמש לבדיקת תקינות החתימה לפני העברה למצב ייצור. 
        • תגיות אופציונליות:
          • תגית k: סוג המפתח ששימש לחתימה. ברירת מחדל- RSA
          • תגית h: פונקציות גיבוב נתמכות (SHA1, SHA256). ברירת מחדל- כולן
          • תגית n: הערות שמחזיק שם המתחם רוצה להוסיף. ברירת מחדל – ריק
          • תגית s: מציין את סוג השירות לשימוש עתידי. כיום רק ל- SMTP וזהו ערך ברירת המחדל
    1. מימוש חתימה:
      לתשומת לב: אין באמור להלן כדי להמליץ על מי מהרכיבים, ואין כל הכרה במהימנות או אמינות המוצרים.
      • מימוש DKIM על שרת דוא"ל חיצוני החשוף לעולם – MTA/ Mail Relay.
        תפקידו לחצוץ בין שרת הדואר הארגוני לבין הרשת החיצונית, ולבצע מטלות שונות טרם שליחת הדוא"ל (למשל חתימת DKIM).
        יש מגוון רחב של שרתי SMTP אשר יכולים לשמש כ- MTA . בקישור להלן השוואת היכולת שלהם בהקשר של מתודולוגיות מניעת ספאם.

    נציין כאן שניים:

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

    DKIM-Signature: v=1; a=rsa-sha1; q=dns/txt;
    d=example.com;
    [email protected];
    s=key1;
    c=relaxed/simple; q=dns/txt;
    t=1117574938; x=1118006938;
    h=from:to:subject:date;
    b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR
    bh=FGJvHD4U2NzgO3YD9EdNrQ7Kec4RLAxMjM03NAY6ODfqLTHI=;

    נתאר את השדות העיקריים המרכיבים את החתימה.
    שדות חובה:

      • שדה v: גרסת DKIM (נכון להיום הערך חייב להיות 1)
      • שדה a: אלגוריתם החתימה. ניתן לבחור מבין שניים אפשריים: rsa-sha256 או rsa-sha1 (סוג פונקצית הגיבוב – SHA, סוג המפתח – RSA)
      • שדה d: שם המתחם
      • שדה s: שם הסלקטור (שם המפתח כפי שהוא ברשומת ה-DNS שמזהה אותו)
      • שדה h: הקלט שנחתם. הקלט הוא שדות ב- Header של הדוא"ל: from, to, subject, date
      • שדה b: החלק הקריפטוגרפי של החתימה. זהו התוצר של הפעלת פונק' הגיבוב והמפתח הפרטי על השדות שהוגדרו בשדה h, מקודד בפורמט Base64.
      • שדה bh: התוצר של הפעלת פונקצית הגיבוב על גוף האימייל (body) בפורמט Base64

    שדות רשות:

      • שדה t: הזמן בו התבצעה החתימה בפורמט Epoch (שניות מ-1970). משמש כחותמת זמן (timestamp).
      • שדה x: זמן פקיעת תוקף החתימה, בפורמט Epoch.

    ** שני השדות הנ"ל על אף שהם אופציונליים, מומלץ לוודא את קיומם. זה מעיד על "אמיתות" המייל, בניגוד לדואר זבל. ספאמרים לא מציינים זמנים כדי לא לתקף את החתימה שלהם.
    יש לזכור: חתימה שתוקפה פג תיחשב כפגומה. **

      • שדה i: זהות היישות שבשמה נחתם הדוא"ל. בפורמט דוא"ל, שם המתחם צריך להתאים לשדה d.
      • שדה c: מידת "הנירמול" (canonicalization) המותרת. שרותי דוא"ל לעתים מוסיפים להודעות דוא"ל רווחים ותווי סוף שורה, דבר שעלול לפגום בחתימה. מידת השינוי המותר מוגדרת בפורמט value1/value2. הערך הראשון מייצג את מידת השינויים בכותרת הדוא"ל (header) והשני בגוף הדוא"ל. הערך המותר הוא:
        • simple: סבילות נמוכה לשינויים
        • relaxed: מאפשר שינויים "מקובלים"
      • שדה q: סוג השאילתה לקבלת המפתח הציבורי. נכון להיום הערך היחיד הוא "dns/txt"
      • שדה l: מספר התווים ששימשו לחישוב שדה bh. מטרת הערך בשדה זה היא לטייב את תהליך הפענוח (עבור מקרים מסוימים), אולם מתברר שהזנת הערך הזה מייצרת בעיות אחרות ולכן מומלץ לא להשתמש בו.
      • שדה z: רשימת השדות המקורית ב- header (בשונה משדה h בו יש רק השדות שנחתמו). גם שדה זה לא מוגדר היטב ולכן אין צורך להשתמש בו.

    סיכום – תיאור תהליך בדיקת דוא"ל חתום

    שרת דוא"ל מקבל דוא"ל חתום. הוא קורא את החתימה. לפי שדה S ושדה d הוא מבצע שאילתת DNS.
    בדוגמא שהצגנו – לדומיין key1._domainkey.example.com

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

    DMARC

    Domain based Message Authentication Reporting and Conformance

    DMARC הינו מנגנון למימוש מדיניות דוא"ל. הוא מבוסס על פעולתם של שני המנגנונים הקודמים, SPF ו- DKIM, ובאמצעותו ניתן להגדיר מדיניות תגובה בהתאם לתוצאות:

    1. מה על הנמען לעשות עם דבר הדואר במקרה שנכשל אימות ההודעה (DKIM) או השולח (SPF)?
      • הסגר (quarantine) להמשך טיפול
      • דחיה (reject) ומחיקת ההודעה
      • לא לבצע דבר
    2. כיצד לדווח למנהל המערכת (administrator) על כשלונות
      • הודעת דוא"ל עם ריכוז כשלונות לפי תקופה (למשל יומי)
      • דיווח על כל כישלון

    נוסף על מדיניות תגובה, ניתן באמצעות DMARC להגדיר מדיניות אכיפה. כלומר לטייב את בדיקת כתובות המקור השולח. כזכור, בפרוטוקול SMTP אין אימות של שולח ההודעה. מנגנון SPF מטפל בבעיה ע"י ווידוא השרת השולח אל מול כתובת המעטפת. באמצעות DMARC ניתן לוודא שגם שם המתחם בשדה from "מיושר" (aligned), וגם זה שבחתימת ה- DKIM.

    את המדיניות וסט ההנחיות מגדיר ומפרסם הצד השולח, מחזיק שם המתחם.
    גם במקרה זה, פרסום המדיניות מבוסס DNS וגם הוא עושה שימוש ברשומות מטיפוס TXT, כפי שמוגדר ב- RFC7489 .
    קריאה והסברים נוספים: https://dmarc.org/overview/

    הגדרת DMARC

    בסעיף להלן נתאר את האפשרויות בהגדרת מדיניות האכיפה והתגובה.

    ע"מ להגדיר רשומת DMARC ניתן להסתייע באתרי אינטרנט, למשל: https://www.kitterman.com/dmarc/assistant.html

    מספר הערות:

    1. שמה של הרשומה הוא תמיד sub-domain בפורמט dmarc.domain-name_
    2. גרסת DMARC היא 1
    3. בדומה למנגנונים הקודמים, גם מדיניות DMARC נמצאת באזור הטקסט החופשי של הרשומה, וגם היא מורכבת משדות המגדירים אותה. חלק מהשדות הינם חובה, השאר הם רשות, ולרובם יש ערך ברירת מחדל, כך שאם הוא מקובל על מחזיק שם-המתחם, אין צורך לציין אותו.
    4. טרם הפעלת DMARC מומלץ להגדיר את המדיניות בתצורת "ניטור":
      • מדיניות: NONE (ללא חסימת דוא"ל)
      • דיווח מרוכז תקופתי (דיווח פרטני על כל חריגה יכול להיות מסיבי)
      • דוגמה:
        _dmarc.example.com IN TXT “v=DMARC1; p=none; pct=100; rua=mailto:[email protected]”
    5. בתום הגדרת DMARC ניתן לבדוק את תקינות הרשומה במגוון אתרים. למשל: https://dmarcian.com/dmarc-inspector/

    רשומה לדוגמא:

    _dmarc.example.com IN TXT “v=DMARC1; p=reject; sp=reject; pct=50;
    fo=1;ri=43200;rua=mailto:[email protected]”

    הסבר לדוגמא:

    • DMARC גרסא 1.
    • יש לדחות הודעות דוא"ל שלא עברו את הבדיקות בהצלחה
    • יש לדחות הודעות דוא"ל גם מתת-דומיינים,  אם לא עברו את הבדיקות בהצלחה
    • יש לבדוק חצי מהודעות הדוא"ל המגיעות משם המתחם
    • יש לשלוח דיווח גם אם אחת הבדיקות נכשלת (DKIM או SPF)
    • דוח מרוכז יישלח כל 12 שעות
    • הדוח יישלח לכתובת הרשומה

    רשימת השדות מפורטת להלן:

    שם הפרמטר

    הסבר

    ערך ברירת מחדל

    שדות חובה

    v

    גרסת DMARC

    שדה חובה. הערך האפשרי היחיד DMARC1

    p

    המדיניות (Policy) שיש להפעיל במקרה של כישלון:
    none – העברה לנמען
    quarantine – הכנסה להסגר
    reject – דחיה ומחיקת ההודעה

    שדה חובה. אין ערך ברירת מחדל. יש לציין במפורש

    שדות רשות

    pct

    אחוז דברי הדוא"ל שעליהם תופעל המדיניות (לכל domain name). ערך זה מאפשר הפעלה מדורגת של המדיניות.

    100%
    כל המיילים

    ruf

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

    אין ערך ברירת מחדל.
    אם יש נדרש, יש לציין במפורש

    rua

    כתובת דוא"ל למשלוח דוחות סיכום (aggregated)

    אין ערך ברירת מחדל.
    אם נדרש, יש לציין במפורש

    sp

    הפעלת מדיניות גם על sub-domain:
    none
    quarantine
    reject

    אין ערך ברירת מחדל.
    אם נדרש, יש לציין במפורש

    adkim

    רמת אכיפת DKIM:
    השוואת שם המתחם בשדה "d" בכותרת (header) של חתימת DKIM לעומת הערך בשדה "from"
    ב- header של המייל.
    r = relaxed מייל מ- sub domain יתקבל
    s = strict  מייל מ- sub domain לא יתקבל.
    דוגמא: ב- from כתוב [email protected]
    לעומת הערך בשדה d הוא: example.com

    r
         

    aspf

    רמת אכיפת SPF:

    השוואת שם המתחם בשדה "MailFrom" במעטפת הדוא"ל
    לעומת הערך בשדה "from" (ב- header של הדוא"ל).
    r = relaxed מייל מ- sub domain יתקבל
    s = strict  מייל מ- sub domain לא יתקבל.

    r

    fo

    דיווח כישלון כאשר:
    0 = שתי הבדיקות נכשלו
    1= אחת מהבדיקות נכשלה
    d = רק אם DKIM נכשל
    s = רק אם SPF נכשל

    0

    rf

    פורמט דוח כישלון
    afrf
    iodef

    afrf

    ri

    תדירות משלוח דיווח, בשניות

    86400 (24 שעות)
    הפעלת שלושת המנגנונים אצל ספקי דואר אלקטרוני בענן

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

    Gmail:

    Office 365

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