תשובה מהירה
איך מגדירים DMARC לדומיין שלי?
פרסמו רשומת TXT ב-_dmarc.yourdomain שכתוב בה v=DMARC1; p=none; rua=mailto:you@yourdomain, קראו את הדוחות המצטברים כחודש, ואז העלו את המדיניות ל-quarantine ולבסוף ל-reject. DMARC מוגדר על ידי RFC 9989 מאז מאי 2026. Postelva מארחת את הרשומה בעורך ה-DNS החינמי שלה.
שלוש מדיניות DMARC ומה כל אחת עושה
| מדיניות | רשומה | השפעה על הודעה שנכשלת ב-DMARC | מתי להשתמש |
|---|---|---|---|
| ניטור | v=DMARC1; p=none; rua=mailto:[email protected] | נמסרת כרגיל; הדוחות נשלחים אליכם | השבועות הראשונים, כדי לראות כל שולח |
| הסגר | v=DMARC1; p=quarantine; rua=mailto:[email protected] | מטופלת כחשודה, בדרך כלל נשלחת לספאם | אחרי ש-SPF ו-DKIM עוברים בכל הדואר הלגיטימי שלכם |
| דחייה | v=DMARC1; p=reject; rua=mailto:[email protected] | נדחית על ידי שרת המקבל | כשהדוחות לא מראים עוד כשל לגיטימי |
הגדרת DMARC בשישה צעדים
אשרו קודם את SPF ואת DKIM
DMARC דורש שלפחות אחד מהם יעבור ויתאים לדומיין ה-From שלכם. פרסמו את שניהם לפני DMARC, לפי המדריכים על SPF ו-DKIM.
בחרו תיבת דואר לדוחות
צרו כתובת כמו dmarc@yourdomain. RFC 9989 קובע שהבעלים חייב להקים תיבת דואר לקבלה וניתוח של דוחות מצטברים.
פרסמו את רשומת הניטור
הוסיפו רשומת TXT עם המארח _dmarc והערך v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.
קראו את הדוחות חודש בערך
דוחות מגיעים בערך פעם ביום ממקבלים ששולחים אותם. חפשו דואר לגיטימי שנכשל ביישור SPF ו-DKIM, ותקנו את השולחים האלה.
מעבר ל-quarantine
שנו p=none ל-p=quarantine. השאירו כך לתקופה דומה, והשוו איך ההודעות טופלו בדוחות.
מעבר ל-reject, או עצירה ב-quarantine
עברו ל-p=reject כשהדוחות נקיים. אם אתם שולחים לרשימות תפוצה מהדומיין הזה, הישארו ב-quarantine.
; stage 1: monitor
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
; stage 2: quarantine
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
; stage 3: reject
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"מה מכילה רשומת DMARC?
רשומת DMARC היא רשומת TXT ב-_dmarc.yourdomain שמתחילה ב-v=DMARC1 ומונה תגים מופרדים בנקודה-פסיק. תג הגרסה בא ראשון והוא רגיש לאותיות גדולות וקטנות. RFC 9989 מגדיר את התגים האלה: p (מדיניות לדומיין), sp (מדיניות לתת-דומיינים קיימים), np (מדיניות לתת-דומיינים שאינם קיימים), adkim ו-aspf (יישור; r למרווח או s למחמיר, ברירת המחדל היא מרווח), rua (כתובות לדוחות מצטברים), ruf (כתובות לדוחות כשלים), fo (אפשרויות כשלים), t (מצב בדיקה, y או n) ו-psd.
אם p חסר, המקבל מתייחס למדיניות כאל none. אם sp חסר, מדיניות p חלה גם על תת-דומיינים. אם rua חסר, לא נשלחים דוחות מצטברים. רשומה מועילה מינימלית מורכבת לכן משלושה חלקים: הגרסה, מדיניות וכתובת דוחות.
תג pct, שמדריכים ישנים רבים עדיין מציגים, הוסר על ידי RFC 9989, כי הוא הופעל לעיתים רחוקות בדיוק, אלא ב-0 וב-100. תג t מחליף אותו: t=y מתנהג כמו pct=0 ו-t=n כמו pct=100, וכ-n הוא ברירת המחדל. מחקו את pct מרשומות ישנות. הרקע הרחב יותר נמצא בSPF לעומת DKIM לעומת DMARC.
מה משמעות היישור ב-DMARC?
יישור פירושו שהדומיין שאומת על ידי SPF או DKIM תואם לדומיין שבכתובת ה-From הנראית. ביישור מרווח, ברירת המחדל, שני הדומיינים צריכים רק את אותו דומיין ארגוני, כך ש-mail.example.com מיושר עם example.com. ביישור מחמיר הם חייבים להיות זהים. RFC 9989 מציין שכמעט כל בעלי הדומיינים מוצאים שיישור מרווח מספיק.
הודעה עוברת DMARC כש-SPF או DKIM עוברים ומיושרים. מספיק אחד מהם. ספק תיבת דואר כמו Proton Mail או Fastmail חותם בדומיין שלכם דרך רשומות ה-CNAME של DKIM, לכן היישור מתקיים בלי עבודה נוספת. המלכודת היא שירות צד שלישי שחותם בדומיין שלו: ה-DKIM שלו עובר אבל לא מיושר, עד שתגדירו עבורו דומיין חתימה משלו.
RFC 9989 מוצא את הדומיין הארגוני דרך מעבר בעץ ה-DNS, עם עד שמונה שאילתות, ולא דרך רשימת סיומות ציבורית. לדומיין רגיל ב-.com או ב-.me זה לא משנה שום דבר שאתם צריכים לעשות.
כמה זמן כדאי להישאר ב-p=none?
הישארו ב-p=none לפחות חודש, ואז ב-p=quarantine לתקופה דומה, לפני p=reject. זה הסדר ש-RFC 9989 ממליץ עליו בהנחיות הפריסה, והוא תואם את עמודי העזרה של הספקים. Mailbox.org פותחת את רשומת הדוגמה שלה ב-p=none ומזהירה שמדיניות מחמירה שנקבעה מוקדם מדי עלולה להחזיר דואר לגיטימי. Proton ממליצה על p=quarantine ומעבר ל-p=reject כשהדואר הלגיטימי עובר.
לפי קריאה של Postelva ב-12 בנובמבר 2026 של הנחיות DMARC של 3 הספקים שמפרסמים אותן (Proton Mail, Mailbox.org ו-Mailfence), 2 מתחילים ב-p=none ו-1 ממליץ על p=quarantine.
לגבי p=reject יש שתי אזהרות. RFC 9989 קובע שדומיין שמשתמש בו לא יכול להסתמך על SPF לבדו וחייב לחתום ב-DKIM, כי SPF נשבר בהעברה. הוא גם קובע שדומיינים שמשתמשיהם שולחים לרשימות תפוצה לא צריכים לפרסם p=reject כלל, כי רשימות לעיתים משנות הודעות, וזה שובר את החתימה.
לאן הולכים דוחות DMARC ומה הם מראים?
דוחות מצטברים נשלחים לכתובת ה-mailto: שב-rua, בדרך כלל פעם ביום מכל מקבל, ומפרטים את המקורות ששלחו דואר עם הדומיין שלכם בשורת ה-From. RFC 9989 מחייב מקבלים לתמוך בכתובות mailto: ומומלץ לשלוח דוחות מצטברים לפחות כל 24 שעות. דיווח מצטבר מוגדר ב-RFC 9990.
דוחות כשלים, שמבוקשים עם ruf, הם עותקים לכל הודעה. מקבלים רבים מסתירים או מטשטשים אותם לשם פרטיות, לכן אל תסמכו עליהם. אם כתובת ה-rua נמצאת מחוץ לדומיין שלכם, בעל הדומיין האחר חייב לאשר אותה ברשומת TXT ב-yourdomain._report._dmarc.otherdomain שמכילה v=DMARC1;, כלל שמונע שימוש לרעה בתיבות דואר של צד שלישי. לדומיין אישי קטן רשימת המקורות קצרה: הספק שלכם, ועוד מעט מאוד.
כדי לקרוא מה ה-DNS מפרסם לפני ואחרי כל שלב, השתמשו בפקודות לבדיקת רשומות MX, SPF, DKIM ו-DMARC.
האם לדומיין האישי שלי יש צורך ב-DMARC?
כן, לכל דומיין ששולח דואר: זה עולה רשומת TXT אחת, והוא חוסם הודעות מזויפות שמשתמשות בשם שלכם. גוגל דורשת DMARC, שבו מדיניות none מספיקה, משולחים שעולים על 5,000 הודעות ביום לחשבונות Gmail, ו-Microsoft מיישמת את אותו סף ל-Outlook.com. תיבת דואר אישית נמצאת הרבה מתחת לגבולות האלה. הרשומה עדיין אומרת למקבלים מה אתם רוצים שייעשה בזיוף.
לדומיין שלא שולח דבר, הגדירו p=reject מיד עם SPF -all ו-MX ריק. Postelva מציעה תבנית "בלי אימייל" למקרה הזה. לדומיין עם תיבת דואר, התחילו מ-none. הצד התחבורתי של אותה הגנה, ההצפנה בין שרתים, מכוסה באיך מגדירים MTA-STS ו-TLS-RPT.
הגדרה שאפשר לצטט: DMARC היא מדיניות DNS שאומרת למקבלים מה לעשות עם דואר שבו תוצאות SPF ו-DKIM אינן מיושרות עם דומיין ה-From, ולאן לשלוח דוחות על כך.
שאלות על הגדרת DMARC
האם RFC 9989 מחייב p=reject?
לא. התקן מגדיר שלוש מדיניות ומשאיר את הבחירה לבעל הדומיין. הוא ממליץ על מסלול הדרגתי ומזהיר מפני p=reject לדומיינים שמשתמשיהם שולחים לרשימות תפוצה.
האם RFC 9989 משנה את רשומת DMARC הקיימת שלי?
רשומות עדיין מתחילות ב-v=DMARC1, כך שרשומה שעובדת ממשיכה לעבוד. התג ri הוסר, pct הוסר, ו-t, np ו-psd נוספו.
מה קורה אם מפרסמים p=reject מוקדם מדי?
דואר לגיטימי שנכשל ביישור, כמו כלי ניוזלטר שנשכח, יידחה על ידי המקבלים. הדוחות ב-p=none קיימים כדי למצוא קודם את השולחים האלה.
האם אפשר להשתמש בתיבת דואר חינמית לדוחות?
כן, כל תיבת דואר שאתם קוראים. כתובת נפרדת או כינוי שומרים את קבצי הדוחות היומיים מחוץ לתיבת הדואר הראשית שלכם.
כמה רשומות DMARC יכול דומיין להחזיק?
אחת לכל שם, ב-_dmarc.yourdomain. לתת-דומיינים יכולה להיות רשומה משלהם, או הם יורשים את המדיניות של ההורה דרך sp.
בקצרה
- DMARC היא רשומת TXT ב-_dmarc.yourdomain שמתחילה ב-v=DMARC1.
- RFC 9989 (מאי 2026) הוא המפרט הנוכחי; הוא מבטל את RFC 7489 ומסיר את pct.
- התחילו ב-p=none עם כתובת rua, וקראו דוחות חודש בערך.
- אחר כך p=quarantine לתקופה דומה, ואז p=reject.
- הודעה עוברת כש-SPF או DKIM עוברים ומיושרים עם דומיין ה-From; יישור מרווח הוא ברירת המחדל.
- דומיין על p=reject לא יכול להסתמך על SPF לבדו ולא צריך לשמש לרשימות תפוצה.
- Postelva מארחת את הרשומה ב-DNS חינמי; .com עולה 12.49 $/שנה בכל שנה.
מקורות (6)
- RFC 9989, Domain-based Message Authentication, Reporting, and Conformance (DMARC) — RFC Editor (נקרא 2026-11-12)
- RFC 7489, DMARC (מבוטל) — RFC Editor (נקרא 2026-11-12)
- SPF, DKIM ו-DMARC לדומיין מותאם — Mailbox.org (נקרא 2026-11-12)
- הגנה על דומיין מותאם ומניעת זיוף — Proton (נקרא 2026-11-12)
- הנחיות לשולחי אימייל — Google Workspace Admin Help (נקרא 2026-11-12)
- חיזוק אבטחת האימייל: דרישות חדשות לשולחים בכמות גדולה — Microsoft Tech Community (נקרא 2026-11-12)