Τι κάνει το DMARC που δεν κάνουν το SPF και το DKIM
Το SPF λέει ποιοι servers επιτρέπεται να στέλνουν email για λογαριασμό ενός domain. Το DKIM υπογράφει ψηφιακά το μήνυμα ώστε να επαληθεύεται η ακεραιότητα των τμημάτων του μηνύματος που έχουν υπογραφεί. Κανένα από τα δύο όμως δεν λέει στον παραλήπτη τι να κάνει όταν ο έλεγχος αποτύχει. Αυτό το κενό το καλύπτει το DMARC (Domain-based Message Authentication, Reporting and Conformance), όπως ορίζεται στο RFC 9989, την τρέχουσα προδιαγραφή του DMARC που αντικατέστησε τα RFC 7489 και RFC 9091.
Χωρίς DMARC record, ο ιδιοκτήτης του domain δεν έχει δημοσιεύσει καμία DMARC πολιτική που να δηλώνει στον παραλήπτη πώς προτιμά να αντιμετωπίζονται μηνύματα που δεν μπορούν να πιστοποιηθούν μέσω aligned SPF ή DKIM. Το DMARC επιτρέπει στον ιδιοκτήτη του domain να δηλώσει την προτιμώμενη αντιμετώπιση (handling preference) σε αυτή την περίπτωση, μέσα από μία μόνο εγγραφή TXT στο DNS — η τελική απόφαση όμως παραμένει πάντα στον παραλήπτη (receiver), όπως προβλέπει και το ίδιο το πρότυπο.
Σημασία έχει να διευκρινιστεί ότι το DMARC δεν απαιτεί να περάσουν και οι δύο μηχανισμοί μαζί: αρκεί τουλάχιστον ένας από τους δύο, SPF ή DKIM, να περάσει με σωστό alignment. Σε περιπτώσεις forwarding, το SPF συχνά αποτυγχάνει ή χάνει το alignment με το αρχικό From:. Μηχανισμοί όπως το SRS μπορούν να βοηθήσουν το SPF να περάσει τεχνικά, αλλά όχι απαραίτητα να διατηρήσει το DMARC alignment. Η υπογραφή DKIM συνήθως ταξιδεύει αναλλοίωτη μέσα στο μήνυμα και μπορεί να σώσει το αποτέλεσμα του ελέγχου DMARC, αρκεί ο ενδιάμεσος server να μην έχει τροποποιήσει τα υπογεγραμμένα headers ή το σώμα του μηνύματος — γιατί τότε σπάει και η ίδια η υπογραφή DKIM.
Τα τρία επίπεδα πολιτικής
Η εγγραφή DMARC ορίζει μια παράμετρο p= που μπορεί να πάρει τρεις τιμές:
- p=none — Δεν ζητά καμία αλλαγή στον τρόπο διαχείρισης του μηνύματος εξαιτίας του αποτελέσματος DMARC· ο παραλήπτης μπορεί ούτως ή άλλως να το βάλει σε spam ή να το απορρίψει για άλλους λόγους. Χρησιμεύει κυρίως για παρακολούθηση, μέσω των αναφορών που περιγράφουμε πιο κάτω.
- p=quarantine — Δηλώνει ότι ο ιδιοκτήτης του domain θεωρεί το μήνυμα ύποπτο και ζητά ανάλογη μεταχείριση· στην πράξη αυτό συνήθως σημαίνει αποστολή σε spam/junk αντί στα εισερχόμενα, αλλά η ακριβής εφαρμογή εξαρτάται από τον παραλήπτη.
- p=reject — Ζητά να απορριφθεί εντελώς το μήνυμα που αποτυγχάνει τον έλεγχο.
Σε όλες τις περιπτώσεις πρόκειται για αίτημα προς τον παραλήπτη και όχι για εγγυημένη ενέργεια· η τελική απόφαση παραμένει στον mail server που δέχεται το μήνυμα. Η συνήθης και ασφαλής διαδρομή είναι να ξεκινήσεις από none για να δεις τι συμβαίνει χωρίς ρίσκο, να προχωρήσεις σε quarantine όταν έχεις επιβεβαιώσει ότι οι νόμιμες πηγές αποστολής περνούν DMARC μέσω aligned SPF ή aligned DKIM, και να καταλήξεις σε reject μόνο όταν έχεις επιβεβαιώσει ότι όλες οι νόμιμες πηγές αποστολής (site, CRM, newsletter, κ.λπ.) περνούν τον έλεγχο. Το πρότυπο συνήθως προτείνει αυτή τη σταδιακή προσέγγιση ξεκινώντας από p=none, χωρίς όμως να την ορίζει ως υποχρεωτική ακολουθία.
Αν πας κατευθείαν σε p=reject χωρίς να έχεις ελέγξει πρώτα τα αποτελέσματα, ρισκάρεις να χάνονται νόμιμα email σου χωρίς καμία προειδοποίηση.Τι σημαίνει «alignment»
Το DMARC δεν κοιτάζει απλά αν το SPF ή το DKIM «πέρασαν» σε απόλυτο επίπεδο. Ελέγχει και το alignment: αν το domain που φαίνεται στο πεδίο From: του email ταιριάζει με το domain που πιστοποίησε το SPF ή που υπέγραψε το DKIM. Αν στέλνεις μέσω μιας υπηρεσίας newsletter που χρησιμοποιεί δικό της domain χωρίς σωστό DKIM alignment, το μήνυμα μπορεί να αποτύχει στο DMARC ακόμα κι αν το SPF της υπηρεσίας είναι τεχνικά σωστό. Γι' αυτό, πριν βάλεις πολιτική αυστηρότερη από none, χρειάζεται να έχεις ελέγξει τα συνηθισμένα λάθη στο DKIM και να έχεις ρυθμίσει σωστά το SPF record σου.
Η πρώτη εγγραφή DMARC
Το DMARC record είναι μια εγγραφή TXT στο subdomain _dmarc του domain σου. Το cPanel, μέσα από την ενότητα Email Deliverability, προτείνει αυτόματα και μπορεί να εγκαταστήσει τις βασικές εγγραφές SPF και DKIM, αλλά και μια προτεινόμενη εγγραφή DMARC (Suggested DMARC Record). Αν προτιμάς να ξεκινήσεις πιο σταδιακά ή να προσαρμόσεις μόνος σου την πολιτική, μπορείς επίσης να προσθέσεις ή να τροποποιήσεις την εγγραφή χειροκίνητα από τον Zone Editor του DNS, ως εγγραφή TXT στο _dmarc. Ένα ασφαλές σημείο εκκίνησης είναι το εξής:
_dmarc.example.gr TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.gr"Εδώ η πολιτική είναι none, δηλαδή δεν δηλώνει προτίμηση για διαφορετικό χειρισμό του μηνύματος λόγω DMARC, αλλά ζητά αναφορές (rua) στη διεύθυνση που ορίζεις. Μόλις δεις για μερικές εβδομάδες ότι όλες οι νόμιμες πηγές αποστολής περνούν τον έλεγχο, ανεβάζεις σταδιακά την αυστηρότητα:
_dmarc.example.gr TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.gr"Και τελικά:
_dmarc.example.gr TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.gr"Αν το domain σου έχει subdomains που στέλνουν ή θα μπορούσαν να στείλουν email — π.χ. newsletter.example.gr, αν στέλνεις από διευθύνσεις όπως info@newsletter.example.gr — η παράμετρος sp= χρειάζεται μόνο αν θέλεις να εφαρμόσεις διαφορετική πολιτική DMARC ειδικά για τα subdomains σε σχέση με το κύριο domain, όπως ορίζει το RFC 9989 για την εφαρμογή πολιτικής στα subdomains του Author Domain· αν δεν την προσθέσεις, η πολιτική που έχεις ορίσει στο p= εφαρμόζεται κανονικά και στα subdomains, χωρίς να χρειάζεται ξεχωριστή δήλωση. Θυμήσου ότι το DMARC εξετάζει πάντα το domain που εμφανίζεται στο πεδίο From: του μηνύματος, όχι το hostname του mail server που το παραδίδει.
Τι σου λένε οι αναφορές (rua)
Οι αναφορές DMARC έρχονται σε μορφή XML, συνήθως συμπιεσμένες, και μπορούν να τις στέλνουν οι mail providers που υποστηρίζουν DMARC aggregate reporting, συνήθως καθημερινά. Δεν χρειάζεται να τις διαβάζεις χειροκίνητα σε raw μορφή — υπάρχουν δωρεάν εργαλεία ανάλυσης DMARC που τις μετατρέπουν σε πίνακα. Πρόκειται για συνοπτικές αναφορές (aggregate reports): δεν δείχνουν κάθε μεμονωμένο μήνυμα ξεχωριστά, αλλά συγκεντρωτικά στοιχεία ανά IP αποστολής — πόσα μηνύματα στάλθηκαν από κάθε IP, ποιο ήταν το αποτέλεσμα SPF/DKIM και αν το alignment ήταν σωστό. Αν δεις IP που δεν αναγνωρίζεις να στέλνει μηνύματα «σαν» το domain σου, μπορεί να πρόκειται για spoofing, αλλά πρώτα έλεγξε μήπως ανήκει σε κάποια νόμιμη υπηρεσία αποστολής ή ενδιάμεσο mail system που χρησιμοποιείς — και είναι ακριβώς ο λόγος που υπάρχει το DMARC.
Πριν αλλάξεις πολιτική, έλεγξε τα βασικά
Αν θέλεις πρώτα τη βασική εικόνα του πώς συνδέονται SPF, DKIM και DMARC μεταξύ τους, υπάρχει ήδη αναλυτικός οδηγός για SPF, DKIM & DMARC. Επειδή το DMARC βασίζεται πλήρως στο SPF και στο DKIM, ένα λάθος σε αυτά τα δύο θα σε οδηγήσει σε λάθος συμπεράσματα στις αναφορές. Αν αλλάζεις server ή προσθέτεις υπηρεσία αποστολής, θυμήσου ότι το DNS χρειάζεται χρόνο να ενημερωθεί παντού — κάτι που εξαρτάται από το TTL της εγγραφής. Αν χρησιμοποιείς Google Workspace ή άλλη εξωτερική υπηρεσία email παράλληλα με αποστολές από το site σου, βεβαιώσου ότι κάθε πραγματική πηγή εξερχόμενης αλληλογραφίας είναι σωστά ρυθμισμένη ώστε να περνά DMARC μέσω aligned SPF ή aligned DKIM. Τα MX records αφορούν τη δρομολόγηση της εισερχόμενης αλληλογραφίας και δεν καθορίζουν από μόνα τους ποιες IP πρέπει να περιλαμβάνονται στο SPF.
Πόσο σύντομα να προχωρήσεις σε reject
Δεν υπάρχει σταθερός αριθμός ημερών που ταιριάζει σε όλους — εξαρτάται από το πόσες πηγές αποστολής χρησιμοποιεί το domain σου. Ένα μικρό site με μία μόνο πηγή (π.χ. WordPress με SMTP plugin) μπορεί να δει καθαρά αποτελέσματα μέσα σε λίγες μέρες. Ένα domain που στέλνει από CRM, newsletter, τιμολόγηση και support ταυτόχρονα χρειάζεται περισσότερο χρόνο παρατήρησης πριν κλείσει την πόρτα με p=reject. Η μόνη ασφαλής πρακτική είναι να μην προχωρήσεις στο επόμενο επίπεδο πολιτικής μέχρι οι αναφορές να δείχνουν σταθερά ότι όλες οι ελεγχόμενες νόμιμες πηγές αποστολής περνούν DMARC και να έχεις κατανοήσει τυχόν αναμενόμενες εξαιρέσεις.
