Ανάγνωση αναφορών DMARC

Ενότητα 4: Παραδοσιμότητα: SPF, DKIM και DMARC στην πράξη · Χρόνος ανάγνωσης: 12 λεπτά

Στόχος μαθήματος: Μετά από αυτό το μάθημα θα μπορείτε να ανοίξετε και να διαβάσετε μια συγκεντρωτική αναφορά DMARC, να προσδιορίσετε ανά γραμμή ποια είναι η πηγή και γιατί περνάει ή αποτυγχάνει, και να αποφασίσετε τι πρέπει να διορθώσετε, τι μπορείτε να αγνοήσετε και πότε μπορείτε να αυστηροποιήσετε το policy σας.

Βασικές έννοιες: συγκεντρωτική αναφορά (aggregate report, RFC 9990), rua, XML, gzip ή zip, report_metadata, policy_published, record, row, source_ip, count, policy_evaluated (disposition, dkim, spf), identifiers (header_from, envelope_from), auth_results, selector, αναφορά σφαλμάτων (ruf, RFC 9991), υπηρεσία αναφορών, ιδιωτικότητα

Τι λαμβάνετε

Αν έχετε ορίσει μια διεύθυνση rua στην εγγραφή DMARC σας (μάθημα 4.4), τότε μεγάλοι αποδέκτες όπως το Google, το Microsoft και το Yahoo σας στέλνουν περίπου κάθε μέρα μια συγκεντρωτική αναφορά. Πρόκειται για ένα email με συνημμένο, συνήθως ένα συμπιεσμένο αρχείο XML με όνομα όπως:

receiver.example!example.com!1793923200!1794009599.xml.gz

Αυτό σημαίνει: από τον αποδέκτη receiver.example, σχετικά με το domain σας example.com, για την περίοδο μεταξύ των δύο χρονοσφραγίδων (δευτερόλεπτα από το 1970, εδώ 6 Νοεμβρίου 2026, ολόκληρη η ημέρα σε UTC).

Μια αναφορά δεν περιέχει το περιεχόμενο των email, ούτε θέματα, και συνήθως ούτε διευθύνσεις αποδεκτών. Περιέχει, ανά server αποστολής, τον αριθμό μηνυμάτων και το αποτέλεσμα του SPF, DKIM και DMARC. Έτσι αποτελεί μια αξιόπιστη εικόνα του ποιος στέλνει email εκ μέρους του domain σας, ακόμα και πηγές που είχατε ξεχάσει, καθώς και απατεώνες.

Η δομή μιας αναφοράς

Μια αναφορά αποτελείται από τρία μέρη. Παρακάτω τα σημαντικότερα τμήματα από το παράδειγμα αρχείου αυτού του μαθήματος (dmarc-rapport-1.xml).

1. Ποιος αναφέρει, για ποια περίοδο

<report_metadata>
  <org_name>receiver.example</org_name>
  <email>noreply-dmarc@receiver.example</email>
  <report_id>receiver.example-20261106-7f3c2a91</report_id>
  <date_range>
    <begin>1793923200</begin>
    <end>1794009599</end>
  </date_range>
</report_metadata>

2. Ποιο policy βρήκε ο αποδέκτης σε εσάς

<policy_published>
  <domain>example.com</domain>
  <p>none</p>
  <sp>none</sp>
  <np>none</np>
  <adkim>r</adkim>
  <aspf>r</aspf>
  <testing>n</testing>
</policy_published>

Ελέγχετε πάντα αυτό: αν εδώ δεν αναγράφεται αυτό που νομίζετε ότι έχετε στο DNS σας, τότε ο αποδέκτης διάβασε μια διαφορετική (ή παλιά) εγγραφή.

3. Ανά πηγή: μια εγγραφή

Κάθε record αφορά μία διεύθυνση IP αποστολής με έναν συνδυασμό αποτελεσμάτων:

<record>
  <row>
    <source_ip>198.51.100.40</source_ip>
    <count>1250</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <envelope_from>bounce.mailer.example</envelope_from>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>mailer.example</domain>
      <selector>k1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounce.mailer.example</domain>
      <scope>mfrom</scope>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Η σημαντικότερη διαφορά: auth_results έναντι policy_evaluated

Εδώ βρίσκεται ο πυρήνας της ανάγνωσης. Στο παραπάνω παράδειγμα, στο auth_results αναγράφεται δύο φορές pass: το DKIM πέρασε για το mailer.example και το SPF πέρασε για το bounce.mailer.example. Παρ' όλα αυτά, στο policy_evaluated αναγράφεται δύο φορές fail. Αυτό δεν είναι αντίφαση: το policy_evaluated μετράει μόνο έναν επιτυχή έλεγχο που είναι ευθυγραμμισμένος με το header_from. Κανένα από τα δύο domains δεν ανήκει στο example.com, οπότε το DMARC αποτυγχάνει.

Έτσι διαβάζετε κάθε γραμμή:

1. Κοιτάξτε το policy_evaluated. Υπάρχει pass στο dkim ή στο spf; Τότε το DMARC περνάει και αυτή η πηγή είναι εντάξει.
2. Αποτυγχάνουν όλα; Κοιτάξτε στο auth_results τα domains. Πρόκειται για μια δική σας υπηρεσία που όμως περνάει για το δικό της domain; Τότε πρέπει να ενεργοποιήσετε στην υπηρεσία αυτή το DKIM με το δικό σας domain (μάθημα 4.3).
3. Αποτυγχάνει και στο auth_results, ή λείπει εντελώς το DKIM; Ψάξτε ποιος είναι ο κάτοχος της διεύθυνσης IP (reverse DNS, μάθημα 5.1, ή μια αναζήτηση whois). Είναι ένα από τα δικά σας συστήματα: διορθώστε το. Είναι άγνωστο και πρόκειται για ύποπτους αριθμούς: πιθανότατα πλαστογράφηση.

Μοτίβα που θα βλέπετε συνεχώς

Προσέξτε επίσης το IPv6: ένας δικός σας server που μερικές φορές στέλνει μέσω IPv6, ενώ το SPF σας αναφέρει μόνο τη διεύθυνση IPv4, δίνει softfail σε αυτές τις γραμμές. Με μια υπογραφή DKIM το DMARC περνάει ακόμα, αλλά είναι ένδειξη ότι το SPF σας είναι ελλιπές.

Από την αναφορά στην απόφαση

Είστε έτοιμοι να αυστηροποιήσετε το policy σας (από none σε quarantine, κατόπιν σε reject) όταν:

• κάθε πηγή που ανήκει σε εσάς έχει τουλάχιστον ένα pass στο policy_evaluated·
• αυτό ισχύει ήδη εδώ και μερικές εβδομάδες, σε όλους τους μεγάλους αποδέκτες·
• ό,τι αποτυγχάνει ακόμα είναι μόνο ανακατευθυνθέν email με έγκυρη υπογραφή DKIM (που τελικά περνάει) ή σαφής πλαστογράφηση.

Αν αποτυγχάνει μια μεγάλη δική σας πηγή, όπως στο παράδειγμα η υπηρεσία newsletter με 1250 μηνύματα, τότε είναι πολύ νωρίς. Με p=reject ο αποδέκτης θα απέρριπτε αυτά τα 1250 newsletters.

Να κάνετε τις αναφορές ευανάγνωστες

Μία αναφορά σε έναν επεξεργαστή κειμένου είναι διαχειρίσιμη. Είκοσι τη μέρα όχι. Υπάρχουν τρεις τρόποι:

• Μια υπηρεσία αναφορών (υπάρχουν πολλές, ορισμένες και με δωρεάν έκδοση). Ορίζετε τη διεύθυνσή τους στο rua και εκείνες δημιουργούν γραφήματα και λίστες. Προσοχή: τότε δίνετε σε αυτή την υπηρεσία πρόσβαση στο ποιοι servers στέλνουν email εκ μέρους σας, και η διεύθυνση αναφοράς βρίσκεται στο domain τους (δείτε την άδεια μέσω _report._dmarc στο μάθημα 4.4). Επιλέξτε μια υπηρεσία που εμπιστεύεστε και που τηρεί τον GDPR.
• Ένα δικό σας εργαλείο: υπάρχουν open source προγράμματα που εξάγουν αναφορές από ένα mailbox και τις παρουσιάζουν σε μια επισκόπηση.
• Ανάγνωση με το χέρι με έναν XML-viewer ή πρόγραμμα περιήγησης, για περιστασιακή χρήση.

Οι αναφορές σφαλμάτων (ruf, RFC 9991) είναι διαφορετικές: ανά αποτυχημένο email, μερικές φορές με τμήματα του email μέσα. Σχεδόν κανένας μεγάλος αποδέκτης δεν τις στέλνει, ακριβώς λόγω της ιδιωτικότητας. Δεν τις χρειάζεστε για να εφαρμόσετε σωστά το DMARC.

Στην πράξη: έτσι μοιάζει

Στο WebOké μπορείτε να συμπληρώσετε τη διεύθυνση αναφοράς στο εργαλείο DMARC στο DirectAdmin ή στο Το WebOké μου (δείτε το μάθημα 4.4), και επιλέγετε εσείς ένα mailbox όπου θα καταφθάνουν οι αναφορές· μια ξεχωριστή διεύθυνση όπως dmarc@ με δικό της φάκελο αποτρέπει την κατάκλυση του κανονικού σας email. Η ανάγνωση γίνεται με μια υπηρεσία αναφορών ή ένα πρόγραμμα της επιλογής σας. Αυτό λειτουργεί το ίδιο σε κάθε πάροχο: η αναφορά είναι ένα τυποποιημένο format.

Σύνοψη

• Μια συγκεντρωτική αναφορά είναι ένα καθημερινό αρχείο XML (συχνά συμπιεσμένο) ανά αποδέκτη, με τον αριθμό μηνυμάτων και τα αποτελέσματα ανά IP αποστολής.
• Το auth_results δίνει το ακατέργαστο αποτέλεσμα SPF και DKIM· το policy_evaluated μόνο ό,τι πέρασε με ευθυγράμμιση. Ένα pass στο auth_results μπορεί να είναι fail στο DMARC.
• Το ανακατευθυνθέν email αναγνωρίζεται από DKIM pass με SPF fail· η πλαστογράφηση από όλα fail σε άγνωστη IP.
• Αυστηροποιήστε το policy σας μόνο όταν όλες οι δικές σας πηγές περνάνε για μερικές εβδομάδες.
• Οι αναφορές σφαλμάτων (ruf) είναι σπάνιες και δεν χρειάζονται.

Κουίζ

Άσκηση

Άσκηση Z4.5: Ανάγνωση μιας αναφοράς DMARC. Ανοίξτε το παράδειγμα αρχείου dmarc-rapport-1.xml (μια συγκεντρωτική αναφορά για το example.com, με πλασματικά δεδομένα). Απαντήστε στις ερωτήσεις: ποιο policy βρήκε ο αποδέκτης, πόσα μηνύματα αναγράφονται συνολικά στην αναφορά, πόσα από αυτά απέτυχαν στο DMARC, ποια γραμμή είναι η υπηρεσία newsletter και τι πρέπει να γίνει εκεί, ποια γραμμή είναι ανακατευθυνθέν email, ποια γραμμή είναι πιθανότατα πλαστογράφηση, τι πρέπει να αλλάξει στην εγγραφή SPF σύμφωνα με τη γραμμή 6, ποια γραμμή περνάει μόνο χάρη στο DKIM σε μια υπηρεσία με δικό της Return-Path, και μπορεί το domain τώρα να μεταβεί σε p=quarantine; Το πρόγραμμα ελέγχει τις απαντήσεις σας με σταθερό κλειδί και εξηγεί για κάθε ερώτηση ποια γραμμή της αναφοράς δίνει την απάντηση.

Για περαιτέρω μελέτη

Τα βήματα σε αυτά τα άρθρα ισχύουν για τους πίνακες ελέγχου του WebOké· σε άλλους παρόχους η διαδικασία είναι παρόμοια.

• Τι είναι το DMARC; Εξήγηση σε απλή γλώσσα
• Εγχειρίδιο DirectAdmin 5.9: DMARC instellen
• Δωρεάν μάθημα DNS 4.5: DMARC: τι πρέπει να κάνουν οι παραλήπτες με ψεύτικα emails
• RFC 9990 (DMARC Aggregate Reporting), με το παράδειγμα αναφοράς στο παράρτημα B· RFC 9991 (Failure Reporting)