Ενότητα 4 · 4.4
DMARC σε φάσεις: από το p=none στο p=reject
Ενότητα 4: Παραδοσιμότητα: SPF, DKIM και DMARC στην πράξη · Χρόνος ανάγνωσης: 12 λεπτά
Στόχος μαθήματος: Μετά από αυτό το μάθημα θα μπορείτε να εξηγήσετε πώς λειτουργεί η ευθυγράμμιση, να σχεδιάσετε μια σταδιακή εφαρμογή DMARC από p=none σε p=reject, να επιλέξετε τα σωστά tags (rua, sp, np, t) και να αντιμετωπίσετε τις γνωστές παγίδες σε ανακατεύθυνση και mailing lists.
Βασικές έννοιες: DMARC (RFC 9989), Author Domain (το domain στο Από), ευθυγράμμιση (alignment), relaxed και strict (adkim, aspf), organization domain, DNS tree walk, p=none, p=quarantine, p=reject, rua, sp, np, t=y (testmodus), tags σε αχρηστία pct, rf, ri, mailing lists, επανεγγραφή From, ARC
Τι ελέγχει ακριβώς το DMARC
Το DMARC απαντά σε μία ερώτηση για κάθε εισερχόμενο mail: πέρασε το SPF ή το DKIM για ένα domain που ανήκει στη διεύθυνση Από; Το domain στη διεύθυνση Από ονομάζεται στο πρότυπο Author Domain. Τα βασικά του record βρίσκονται στο μάθημα 4.5 του μαθήματος DNS. Τον Μάιο του 2026 δημοσιεύτηκε το αναθεωρημένο πρότυπο: RFC 9989, με το RFC 9990 για τις συγκεντρωτικές αναφορές και το RFC 9991 για τις αναφορές σφαλμάτων. Υπάρχοντα records με v=DMARC1 παραμένουν έγκυρα κανονικά.
Η ευθυγράμμιση στην πράξη
Το "ανήκει σε" ονομάζεται ευθυγράμμιση (alignment). Υπάρχουν δύο ρυθμίσεις:
- relaxed (προεπιλογή): τα domains έχουν το ίδιο organization domain. Τα
nieuws.example.comκαιexample.comείναι ευθυγραμμισμένα· ταexample.comκαιexample.netόχι. - strict (
adkim=sήaspf=s): τα domains πρέπει να είναι ακριβώς ίδια.
Για το SPF, το DMARC συγκρίνει το domain του Return-Path με το domain στο Από. Για το DKIM, το domain d= μιας έγκυρης υπογραφής. Μερικά παραδείγματα για ένα mail με Van: info@example.com:
| Αποτέλεσμα SPF (Return-Path) | Αποτέλεσμα DKIM (d=) | DMARC |
|---|---|---|
pass για example.com | καμία υπογραφή | pass (ευθυγραμμισμένο SPF) |
pass για bounce.mailer.example | pass για mailer.example | fail (και τα δύο πέτυχαν, κανένα ευθυγραμμισμένο) |
pass για bounce.mailer.example | pass για example.com | pass (ευθυγραμμισμένο DKIM) |
| fail (προωθήθηκε) | pass για example.com | pass (το DKIM επιβιώνει) |
pass για bounce.example.com | κανένα | pass με relaxed, fail με aspf=s |
Αφήστε λοιπόν τα adkim και aspf σε relaxed, εκτός αν έχετε καλό λόγο.
Πώς γνωρίζει ο παραλήπτης ποιο είναι το organization domain; Παλιότερα με τη Public Suffix List, μια λίστα με domains όπως .nl, .co.uk και github.io. Το RFC 9989 το αντικαθιστά με έναν DNS tree walk: ο παραλήπτης αναζητά records _dmarc του domain και των domains ανώτερου επιπέδου. Για έναν απλό χρήστη δεν αλλάζει τίποτα· το παρατηρείτε μόνο αν εργάζεστε με records σε subdomains.
Η εφαρμογή σε τέσσερις φάσεις
Ο στόχος είναι το p=reject: τότε οι παραλήπτες απορρίπτουν mail που προσποιείται ότι είστε εσείς, και αυτή είναι η καλύτερη προστασία κατά ψεύτικων τιμολογίων και phishing στο όνομά σας. Όμως όποιος περάσει αμέσως σε reject χωρίς να γνωρίζει τους αποστολείς του, θα απορρίψει σύντομα και τα δικά του τιμολόγια. Γι' αυτό ακολουθήστε αυτή τη σειρά (η συνιστώμενη γραμμή αυτού του μαθήματος):
Φάση 0: προετοιμασία
- Καταρτίστε την απογραφή όλων των αποστολέων σας (μάθημα 4.2).
- Βεβαιωθείτε ότι κάθε αποστολέας έχει ευθυγραμμισμένο SPF ή DKIM, κατά προτίμηση DKIM, καθώς αυτό επιβιώνει στην ανακατεύθυνση.
- Δημιουργήστε ξεχωριστή διεύθυνση για αναφορές, για παράδειγμα
dmarc@example.com, ή χρησιμοποιήστε μια υπηρεσία αναφορών. Σύντομα θα λαμβάνετε αρκετές αναφορές την ημέρα.
Φάση 1: μέτρηση με p=none
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"Το p=none δεν κάνει τίποτα στο ίδιο το mail. Οι παραλήπτες παραδίδουν τα πάντα όπως πάντα, αλλά σας στέλνουν καθημερινά μια συγκεντρωτική αναφορά (aggregate report) με κάθε server που έστειλε mail εκ μέρους του domain σας και αν πέτυχαν τα SPF, DKIM και DMARC. Με αυτό εκπληρώνετε επίσης την ελάχιστη απαίτηση του Gmail, του Yahoo και της Microsoft για μαζικούς αποστολείς (μάθημα 5.3).
Αφήστε το έτσι τουλάχιστον δύο έως τέσσερις εβδομάδες, και περισσότερο αν έχετε υπηρεσίες που στέλνουν mail μόνο περιστασιακά (μια ετήσια υπενθύμιση, ένα τριμηνιαίο τιμολόγιο). Διαβάστε τις αναφορές (μάθημα 4.5) και διορθώστε κάθε δική σας πηγή που αποτυγχάνει.
Φάση 2: p=quarantine
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"Το mail που δεν περνά το DMARC καταλήγει στον φάκελο ανεπιθύμητων του παραλήπτη. Αν ξεχάσετε μια πηγή, το mail αυτό δεν χάνεται, αλλά είναι δύσκολο να βρεθεί. Αν θέλετε να είστε προσεκτικοί, προσθέστε πρώτα t=y (testmodus): οι παραλήπτες τότε εφαρμόζουν μια βαθμίδα ηπιότερη πολιτική (στο quarantine δηλαδή none), αλλά βλέπετε στις αναφορές τι θα συνέβαινε. Αυτό αντικαθιστά στο RFC 9989 το παλιό tag pct=.
Ελέγξτε ξανά τις αναφορές για μερικές εβδομάδες.
Φάση 3: p=reject
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"Το mail που δεν περνά το DMARC απορρίπτεται. Ο αποστολέας λαμβάνει ένα bounce, στη Microsoft για παράδειγμα με τον κωδικό 5.7.509 και στο Gmail με παραπομπή στην πολιτική DMARC (ενότητα 6). Συνεχίστε να παρακολουθείτε τις αναφορές: νέες υπηρεσίες προστίθενται πάντα.
Πότε μπορεί να γίνει πιο γρήγορα;
Στέλνετε όλο σας το mail μέσω ενός μόνο πάροχου που ρυθμίζει για εσάς το SPF και το DKIM, και τίποτα άλλο δεν στέλνει mail εκ μέρους του domain σας; Τότε μια αυστηρή πολιτική μπορεί να εφαρμοστεί αμέσως. Ορισμένες εταιρείες hosting θέτουν γι' αυτό τον λόγο ως προεπιλογή p=reject. Αν στη συνέχεια αρχίσετε να χρησιμοποιείτε μια υπηρεσία newsletter ή ένα πρόγραμμα λογιστικής, επαναφέρετέ το προσωρινά σε p=none με διεύθυνση αναφοράς, έως ότου αυτή η υπηρεσία λειτουργεί σωστά.
Τα υπόλοιπα tags
| Tag | Για τι | Συμβουλή |
|---|---|---|
rua=mailto:... | Διεύθυνση(εις) για συγκεντρωτικές αναφορές, χωρισμένες με κόμμα | Να συμπληρώνεται πάντα κατά την εφαρμογή |
ruf=mailto:... | Διεύθυνση για αναφορές σφαλμάτων ανά mail (RFC 9991) | Σχεδόν κανένας παραλήπτης δεν τις στέλνει, και μπορεί να περιέχουν προσωπικά δεδομένα. Συνήθως να παραλείπεται |
sp= | Πολιτική για υπάρχοντα subdomains | Να παραλείπεται (τότε ισχύει το p=), εκτός αν τα subdomains στέλνουν mail διαφορετικά |
np= | Πολιτική για subdomains που δεν υπάρχουν | Το np=reject είναι καλή προσθήκη μόλις η κύρια πολιτική σας είναι αυστηρή: κανείς δεν μπορεί τότε να στείλει mail από factuur.example.com αν αυτό το όνομα δεν υπάρχει |
adkim=, aspf= | Strict ή relaxed | Αφήστε relaxed |
t=y | Testmodus: μια βαθμίδα ηπιότερη | Χρήσιμο στη μετάβαση προς quarantine ή reject |
fo= | Πότε δημιουργούνται αναφορές σφαλμάτων | Χρήσιμο μόνο με το ruf |
pct=, rf=, ri= | Σε αχρηστία στο RFC 9989 | Μην τα χρησιμοποιείτε πλέον: οι παραλήπτες που ακολουθούν το νέο πρότυπο τα αγνοούν |
Μια διεύθυνση αναφοράς σε άλλο domain (για παράδειγμα μια υπηρεσία αναφορών) λειτουργεί μόνο αν εκείνο το domain δίνει άδεια με ένα record όπως example.com._report._dmarc.rapportdienst.example. Η υπηρεσία το ρυθμίζει συνήθως αυτή (RFC 9990, κεφάλαιο 4).
Παγίδες
Mailing lists
Μια κλασική mailing list προωθεί το mail σας σε όλα τα μέλη, από τον δικό της server, και συχνά προσθέτει [lijst] στο θέμα ή ένα υποσέλιδο. Τότε το SPF αποτυγχάνει (άλλος server) και το DKIM επίσης (το mail έχει αλλάξει). Με p=reject οι παραλήπτες απορρίπτουν το μήνυμά σας προς τη λίστα. Το σύγχρονο λογισμικό λίστας το λύνει αυτό με επανεγγραφή της διεύθυνσης Από σε διεύθυνση της λίστας ("Jan via Leden"), ή προωθώντας το mail αναλλοίωτο. Αν χρησιμοποιείτε λίστα που δεν το κάνει αυτό, θα το δείτε στις αναφορές σας.
Ανακατεύθυνση
Δείτε το μάθημα 3.3: το SPF χαλάει, το DKIM συνήθως επιβιώνει. Ένας παραλήπτης μπορεί με το ARC να αποφασίσει να εμπιστευτεί έναν γνωστό ανακατευθυντή. Στις αναφορές το αναγνωρίζετε αυτό ως mail από άγνωστο server με DKIM pass και SPF fail· αυτό δεν είναι λόγος να χαλαρώσετε την πολιτική σας.
Δύο records ή τυπογραφικό λάθος
Δύο records DMARC στο _dmarc καθιστούν την πολιτική άκυρη, όπως και ένα τυπογραφικό λάθος στο p= (το p=rejected δεν υπάρχει). Ελέγξτε μετά από κάθε αλλαγή.
Στην πράξη: έτσι φαίνεται σε έναν πίνακα
Σε ένα πακέτο hosting του WebOké ισχύει ως προεπιλογή v=DMARC1;p=reject, χωρίς διεύθυνση αναφοράς. Αυτό είναι ασφαλές αν όλο το mail σας περνά μέσα από αυτούς τους servers. Αν στέλνετε mail και μέσω άλλων υπηρεσιών, θέστε το σε p=none με διεύθυνση rua και ολοκληρώστε τις φάσεις. Στο DirectAdmin αυτό γίνεται στο DNS Administration με το μολύβι δίπλα στο record _dmarc (πεδία Domain policy type και Aggregate Email (RUA))· στο Το WebOké μου με τον βοηθό DMARC στην καρτέλα DNS. Σε άλλους παρόχους δημιουργείτε ένα record TXT στο όνομα _dmarc και πληκτρολογείτε εσείς το κείμενο· το αποτέλεσμα είναι το ίδιο.
Σύνοψη
- Το DMARC πετυχαίνει αν το SPF ή το DKIM πετύχει για ένα domain που είναι ευθυγραμμισμένο με το domain στο Από· η relaxed ευθυγράμμιση δέχεται subdomains.
- Εφαρμογή: απογραφή,
p=noneμεruaκαι ανάγνωση αναφορών,p=quarantine(ενδεχομένως μεt=y), και έπειταp=reject. - Χρησιμοποιήστε
np=rejectγια μη υπαρκτά subdomains μόλις η κύρια πολιτική είναι αυστηρή. Ταpct,rfκαιriείναι σε αχρηστία. - Οι mailing lists και η ανακατεύθυνση δημιουργούν αναμενόμενα σφάλματα· το DKIM και το ARC αντισταθμίζουν μέρος αυτού.
- Ακριβώς ένα record στο
_dmarc, χωρίς τυπογραφικά λάθη.
Κουίζ
Άσκηση
Άσκηση Z4.4: Έλεγχος του DMARC του domain σας και επιλογή του επόμενου βήματος. Συμπληρώστε το δικό σας domain (ή το internet.nl). Συμπληρώστε το record DMARC όπως το βρήκατε, την τιμή του p= και αν περιλαμβάνεται διεύθυνση rua. Επιλέξτε έπειτα ποια φάση της εφαρμογής θεωρείτε ότι είναι το επόμενο βήμα, και γιατί. Το πρόγραμμα ζητά το record ζωντανά, ελέγχει τη σύνταξη σύμφωνα με το RFC 9989 (ένα record, έγκυρο p, γνωστά tags, tags σε αχρηστία ως προειδοποίηση), και τοποθετεί τις απαντήσεις σας δίπλα.
Για περαιτέρω μελέτη
Τα βήματα σε αυτά τα άρθρα ισχύουν για τους πίνακες του WebOké· σε άλλους παρόχους λειτουργεί παρόμοια.
- Δωρεάν μάθημα DNS 4.5: DMARC: τι πρέπει να κάνουν οι παραλήπτες με ψεύτικα emails
- Εγχειρίδιο DirectAdmin 5.9: DMARC instellen
- Τι είναι το DMARC; Εξήγηση σε απλή γλώσσα
- Δημιουργία εγγραφής DMARC στο DirectAdmin
- RFC 9989 (DMARC), ιδίως 4.7 (tags) και παράρτημα C (αλλαγές από το RFC 7489)
