DKIM 'Body Hash Did Not Verify' — Τι Άλλαξε το Μήνυμά σας και Πώς να το Διορθώσετε (2026)

Δημοσιεύτηκε 2026-07-08

Στοιχεία ως 2026-06-29 · μεθοδολογία v7. Συγκεντρωτικά στοιχεία απογραφής για 261 εκατομμύρια βαθμολογημένα domains. Δείτε πώς βαθμολογούμε.

Το “body hash did not verify” σημαίνει ότι η υπογραφή DKIM σας ήταν έγκυρη όταν το μήνυμα σας έφυγε — και κάτι ξανάγραψε το σώμα του μηνύματος μετά. Η υπογραφή δεν είναι σπασμένη· το μήνυμα τροποποιήθηκε κατά τη μεταφορά. Μόνο 3.87% των domains — 10,092,481 — ολοκληρώνουν την πλήρη τριάδα SPF-DKIM-DMARC, σύμφωνα με την απογραφή Defaults.Exposed των 261,086,232 domains (2026-06-29).

Η διόρθωση είναι μια έρευνα, και μετά μια απόφαση. Βρείτε το hop που τροποποιεί το email σας — ένα gateway που προσαρτά αποποίηση, μια συσκευή που ξαναγράφει links, μια mailing list που προσθέτει footer. Στη συνέχεια υπογράψτε μετά από αυτό το hop, σταματήστε την τροποποίηση, ή κάντε την υπογραφή ανεκτή σε αυτήν — με αυτή τη σειρά.

Τι σημαίνει πραγματικά το “body hash did not verify”;

Μια υπογραφή DKIM (RFC 6376) φέρει δύο hashes: bh=, ένα hash του σώματος του μηνύματος όπως υπογράφηκε, και b=, που υπογράφει τις κεφαλίδες συν αυτό το body hash. Ο επαληθευτής υπολογίζει εκ νέου το body hash από το μήνυμα που έλαβε· αν δεν ταιριάζει με το bh=, η επαλήθευση σταματά με τη συμβολοσειρά που όλοι επικολλούν σε κουτί αναζήτησης — μια κεφαλίδα παραλήπτη όπως:

Authentication-Results: …; dkim=fail (body hash did not verify)

Αυτή είναι η τεκμηριωμένη συμβολοσειρά αιτίας της Microsoft· το Gmail συχνά αποδίδει την ίδια διάγνωση ως dkim=neutral (body hash did not verify). Σε κάθε περίπτωση, η απόφαση περιορίζει τεράστια το πρόβλημα. Το κλειδί DNS, ο selector και η ρύθμιση υπογραφής σας είναι όλα καλά. Η κρυπτογραφία έκανε τη δουλειά της: το σώμα άλλαξε μεταξύ υπογραφής και επαλήθευσης — μία προσαρτημένη γραμμή, μία ξαναγραμμένη URL, ένας εκ νέου κωδικοποιημένος χαρακτήρας αρκεί. (Ένα διαφορετικό μήνυμα — signature did not verify, no key for signature — σημαίνει διαφορετική αποτυχία· ξεκινήστε με “DKIM signature not valid”.) Και είναι επείγον γιατί μια αποτυχημένη υπογραφή δεν μπορεί να δώσει στο DMARC ευθυγραμμισμένο pass: εκτός αν ο SPF περνά με ευθυγράμμιση στο ίδιο μήνυμα, το email αποτυγχάνει στο DMARC εντελώς.

Τι άλλαξε το μήνυμά σας; Οι συνήθεις ύποπτοι

Κάτι στη διαδρομή παράδοσης επεξεργάστηκε το σώμα αφού ο signer σας το σφράγισε. Στην πράξη είναι ένα από τέσσερα πράγματα:

Ποιος το τροποποίησε	Τι αλλάζουν	Τυπικό σήμα
Εξερχόμενο gateway / smart host (κανόνες μεταφοράς Exchange, Mimecast, Proofpoint, Barracuda…)	Προσαρτά τη νομική αποποίηση, marketing footer, ή banner “EXTERNAL:” αφού ο διακομιστής email υπέγραψε ήδη	Κάθε μήνυμα σε αυτή τη διαδρομή αποτυγχάνει· άμεσες αποστολές που παρακάμπτουν το gateway περνούν
Συσκευή ασφαλείας / προστασία links	Ξαναγράφει URLs σε ανακατευθύνσεις σάρωσης, προσθέτει wrappers παρακολούθησης	Μόνο μηνύματα που περιέχουν links αποτυγχάνουν
Mailing list (Google Groups, Mailman…)	Προσθέτει ετικέτα θέματος και footer list, μερικές φορές αναδιαρρυθμίζει το σώμα	Μόνο email που αποστέλλεται μέσω της list αποτυγχάνει
Forwarder / relay που επανακωδικοποιεί MIME	Transcodes charset, αναδιπλώνει γραμμές — αόρατο σε άνθρωπο, θανατηφόρο για hash	Αποτυχίες συσπειρώνονται σε έναν παραλήπτη ή διεύθυνση προώθησης

Ελέγξτε πρώτα τη γραμμή με έντονη γραφή — ο διακομιστής email υπογράφει, η edge συσκευή επεξεργάζεται, και κάθε μήνυμα φεύγει με υπογραφή που ήταν αληθινή για τριάντα χιλιοστά του δευτερολέπτου.

Πώς βρίσκω το hop που τροποποιεί το email μου;

Διαφορική διάγνωση — συγκρίνετε μια διαδρομή που λειτουργεί με τη διαδρομή που αποτυγχάνει:

Στείλτε ένα άμεσο δοκιμαστικό μήνυμα σε γραμματοκιβώτιο που ελέγχετε σε κύριο παραλήπτη (το Gmail λειτουργεί καλά), παρακάμπτοντας όσο περισσότερο μπορείτε την εξερχόμενη αλυσίδα σας.
Στείλτε ένα δεύτερο μήνυμα κατά μήκος της αποτυχημένης διαδρομής — μέσω του gateway, μέσω της list, στο domain του επηρεαζόμενου παραλήπτη.
Συγκρίνετε τις γραμμές Authentication-Results και στις δύο πλήρεις κεφαλίδες. Άμεση αποστολή dkim=pass, αποτυχημένη διαδρομή dkim=fail (ή dkim=neutral) με body hash did not verify: ο τροποποιητής βρίσκεται μεταξύ αυτών των δύο διαδρομών.
Κοιτάξτε το σώμα που ελήφθη: αποποίηση, banner, ή footer που δεν πληκτρολογήσατε; Links ξαναγραμμένα σε domain σάρωσης; Αυτό είναι το hop σας, ονομαστικά — και η αλυσίδα Received: δείχνει ποιο relay εμφανίζεται μόνο στην αποτυχημένη διαδρομή.

Οι αναφορές συγκεντρωτικών DMARC σας αφηγούνται την ίδια ιστορία σε κλίμακα: μια πηγή που αναφέρει συνεχώς DKIM fail με SPF pass είναι συνήθως τροποποίηση-κατά-μεταφορά στη δική σας διαδρομή, όχι επιτιθέμενος.

Πώς το διορθώνω;

Εκτελέστε τη δωρεάν σάρωση στο defaults.exposed πριν αλλάξετε οτιδήποτε. Επιβεβαιώνει ότι τα δημοσιευμένα κλειδιά DKIM και η DMARC policy σας είναι σωστά, ώστε να αποσφαλματώνετε το ένα πραγματικό πρόβλημα — η τροποποίηση — και όχι να κυνηγάτε φαντάσματα στο DNS. Η σελίδα διόρθωση DKIM καλύπτει τους ελέγχους πλευράς εγγραφής.
Υπογράψτε μετά το hop τροποποίησης. Η αρχιτεκτονικά σωστή διόρθωση: μετακινήστε την υπογραφή DKIM στην εξωτερικότερη συσκευή που αγγίζει το μήνυμα. Εγκαταστάσεις Exchange-plus-gateway πρέπει να υπογράφουν στο gateway (Mimecast, Proofpoint και παρόμοια το υποστηρίζουν όλα) και να απενεργοποιούν την υπογραφή upstream. Αν το Google Workspace ή το Microsoft 365 είναι το τελευταίο hop σας, υπογράφτε εκεί και μη αφήσετε τίποτα να επεξεργαστεί email μετά — δείτε ρύθμιση DKIM σε Google Workspace ή Microsoft 365.
Ή σταματήστε την τροποποίηση. Αφαιρέστε την επεξεργασία από τη διαδρομή μεταφοράς: η αποποίηση να μπει στην υπογραφή πελάτη ή template αντί για transport rule· το banner “EXTERNAL:” να περιοριστεί μόνο στα εισερχόμενα (η σήμανση των δικών σας εξερχόμενων ως εξωτερικών είναι λάθος ρύθμιση δύο φορές)· το επικυρωμένο εξερχόμενο email να εξαιρεθεί από link-rewriting.
Χρησιμοποιήστε relaxed/relaxed canonicalization (c=relaxed/relaxed). Το simple body canonicalization αποτυγχάνει σε μία μόνο αναδιπλωμένη γραμμή· το relaxed ανέχεται αλλαγές κενών και τέλους γραμμής. Να είστε ειλικρινείς για το όριο: το relaxed συγχωρεί μορφοποίηση, ποτέ περιεχόμενο — ένα προσαρτημένο footer εξακολουθεί να αποτυγχάνει, όπως πρέπει.
Επαναδοκιμάστε και τις δύο διαδρομές, στη συνέχεια επανεκτελέστε σάρωση. Και οι δύο διαδρομές πρέπει τώρα να δείχνουν dkim=pass με το domain σας στο d=, και η αναφορά σάρωσης πρέπει να είναι καθαρή.

Πρέπει να χρησιμοποιήσω την ετικέτα l= για να κάνω το DKIM να αγνοεί προσαρτημένο περιεχόμενο;

Όχι — και να είστε καχύποπτοι με οποιονδήποτε οδηγό το προτείνει. Η ετικέτα l= κάνει hash μόνο τα πρώτα N bytes του σώματος, οπότε ένα προσαρτημένο footer δεν σπάει πλέον την υπογραφή. “Λειτουργεί” αφήνοντας το τέλος του μηνύματός σας μη υπογεγραμμένο: οποιοσδήποτε κατέχει ένα νόμιμο υπογεγραμμένο μήνυμα μπορεί να προσαρτήσει αυθαίρετο περιεχόμενο και η έγκυρη υπογραφή σας εξακολουθεί να επαληθεύεται πάνω στο αποτέλεσμα. Αυτή είναι μια τρύπα πλαστοπροσωπίας με ενδυμασία διόρθωσης — η πρακτική κατάχρηση έχει αποδειχθεί, και ορισμένοι παραλήπτες τιμωρούν ή αγνοούν το l= ακριβώς για αυτόν τον λόγο. Λύστε την τροποποίηση· μη αφαιρέσετε την υπογραφή από μέρος του email σας.

Τι γίνεται με τις mailing lists — μπορώ να τις διορθώσω;

Κυρίως, όχι — και το να το γνωρίζετε αυτό σας γλιτώνει εβδομάδες. Μια list που προσθέτει ετικέτα θέματος ή footer σπάει το body hash σας εκ σχεδιασμού, και δεν ελέγχετε τη list. Δύο πράγματα βοηθούν:

Αυτό το υπόλοιπο είναι ακριβώς γιατί η εφαρμογή DMARC είναι σταδιακή. Η μετακίνηση από p=none μέσω p=quarantine με αύξηση pct=, ενώ διαβάζετε αναφορές συγκεντρωτικών, σημαίνει ότι τα μηνύματα που έχουν αλλαχτεί από list καραντίνεύονται αντί να καταστρέφονται ενώ αξιολογείτε τον αντίκτυπο — το θέμα του από p=none σε p=reject χωρίς απώλεια νόμιμου email.
Το ARC είναι ο μηχανισμός του παραλήπτη, όχι δικός σας. Το Authenticated Received Chain επιτρέπει στη list να πιστοποιεί πώς έμοιαζε η επικύρωση κατά την άφιξη και στον παραλήπτη να αποφασίσει αν θα το εμπιστευτεί. Δεν υπάρχει τίποτα για εσάς, τον αποστολέα, να ρυθμίσετε. Καλά διατηρημένες lists μετριάζουν ξαναγράφοντας την κεφαλίδα From· οι κακά διατηρημένες απλώς σπάνε το email σας.

Η προώθηση είναι η παρακείμενη περίπτωση — σπάει αξιόπιστα τον SPF αλλά μερικές φορές μόνο τον DKIM, γι’ αυτό ο ευθυγραμμισμένος DKIM είναι το ανθεκτικό-στην-προώθηση σκέλος σας όταν το σώμα επιβιώνει: δείτε προωθημένο email που αποτυγχάνει στον SPF.

Γιατί το DKIM σπάει τόσο συχνά όταν τόσα λίγα domains έχουν καν το πλήρες stack;

Επειδή το DKIM είναι το εύθραυστο μεσαίο παιδί της τριάδας: ο SPF είναι μια στατική εγγραφή DNS, το DMARC μια δήλωση policy, αλλά το DKIM πρέπει να επιβιώσει το ταξίδι. Μόνο 51.84% των βαθμολογημένων domains δημοσιεύουν ανιχνεύσιμο κλειδί DKIM στο DNS, σύμφωνα με την απογραφή Defaults.Exposed, και μόνο 10,092,481 domains — 3.87% των 261,086,232 βαθμολογημένων — κατέχουν SPF, DKIM και enforcing DMARC policy μαζί (το μοντέλο ωριμότητας υιοθέτησης SPF αναλύει τη σκάλα). Η σωστή διόρθωση αυτού είναι το πιο δύσκολο μέρος για να ενταχθείτε σε αυτό το 3.87%.

Συχνές ερωτήσεις

Είναι το “body hash did not verify” σημάδι ότι κάποιος πλαστοπροσωπεί το domain μου; Συνήθως όχι — ένας παλαιοπροσωπητής συνήθως δεν μπορεί να παράγει καν την υπογραφή DKIM σας, οπότε το email τους δείχνει καμία υπογραφή ή no key. Ένα αποτυχημένο body hash σημαίνει ότι ένα μήνυμα που υπογράφηκε πραγματικά από την υποδομή σας επεξεργάστηκε αργότερα. Ελέγξτε τον gateway σας πριν υποθέσετε επιτιθέμενο.

Ο SPF περνά σε αυτά τα μηνύματα — είμαι ακόμα ΟΚ; Προς το παρόν, ίσως: το DMARC χρειάζεται μόνο ένα ευθυγραμμισμένο pass. Αλλά το pass του SPF εξαφανίζεται τη στιγμή που κάποιος προωθεί το μήνυμα, και αν δεν ευθυγραμμίζεται με το domain From σας δεν μέτρησε ποτέ για το DMARC. Με μόνο 3.87% των domains να κατέχουν την πλήρη τριάδα (απογραφή 2026-06-29 των 261,086,232 domains), το “ένα σκέλος να κουτσαίνει” είναι η κανονική κατάσταση — και η διορθώσιμη.

Η αλλαγή σε relaxed/relaxed canonicalization θα λύσει το πρόβλημα αποποίησης; Όχι. Το relaxed ανέχεται μόνο αλλαγές κενών και αναδίπλωσης γραμμών. Μια προσαρτημένη αποποίηση είναι αλλαγή περιεχομένου, και το hash πρέπει να αποτυγχάνει σε αυτήν — αυτό είναι το DKIM που λειτουργεί σωστά. Μετακινήστε το σημείο υπογραφής ή μετακινήστε την αποποίηση.

Η αποτυχία συμβαίνει μόνο σε ένα domain πελάτη. Γιατί; Η πλευρά τους σχεδόν σίγουρα τροποποιεί εισερχόμενα email — μια συσκευή ασφαλείας που ξαναγράφει links ή σφραγίζει banners πριν εκτελεστεί ο επαληθευτής τους, ή ένας εσωτερικός προωθητής που επανακωδικοποιεί το σώμα. Στείλτε τους αυτή τη σελίδα διάγνωσης· η διόρθωση βρίσκεται στο gateway τους, όχι στο DNS σας.

Στείλτε στον ιδιοκτήτη την αναφορά

Αν διορθώνετε αυτό για έναν πελάτη ή τον εργοδότη σας, κλείστε τον κύκλο με αποδείξεις. Μόλις διορθωθεί το hop τροποποίησης, επανεκτελέστε τη δωρεάν σάρωση και προωθήστε τη βαθμολογημένη αναφορά στον ιδιοκτήτη της επιχείρησης: με ημερομηνία, σε απλή γλώσσα, με DKIM και DMARC σε μία σελίδα. Είναι το τεκμήριο που θα χρειαστούν για την ανανέωση ασφάλισης κυβερνοεπιθέσεων και το επόμενο ερωτηματολόγιο προμηθευτών — απόδειξη ότι το email που φεύγει από την εταιρεία είναι το email που φτάνει.

Ελέγξτε το domain σας → · Οδηγός “DKIM signature not valid” → · Διόρθωση DKIM → · Πώς βαθμολογούμε → · Μόνο συγκεντρωτικά δεδομένα. Δεδομένα αποθηκευμένα και επεξεργασμένα στην ΕΕ.