Σταματήστε να μαντεύετε το DNS σας: μια φιλική προς developers περιήγηση σε MX, SPF, DKIM και DMARC

Γιατί οι εγγραφές DNS για email έχουν σημασία τώρα

Ο έλεγχος ταυτότητας email κάποτε ήταν προαιρετικός. Το 2026 είναι βασική προϋπόθεση. Το Gmail και το Outlook επιβάλλουν SPF και DKIM για μαζικούς αποστολείς, ενώ το DMARC γίνεται γρήγορα υποχρεωτικό για κάθε domain που στέλνει transactional email. Αν οι εγγραφές DNS σας είναι λάθος, τα email σας δεν φτάνουν—χωρίς bounce, χωρίς προειδοποίηση, απλώς σιωπή.

Το πρόβλημα είναι ότι αυτές οι εγγραφές τεκμηριώνονται σαν RFCs, όχι σαν εργαλεία. Οι περισσότεροι developers αντιγράφουν παραδείγματα από τον οδηγό ρύθμισης του παρόχου email τους και ελπίζουν για το καλύτερο. Αυτό λειτουργεί μέχρι να χρειαστεί να κάνετε troubleshooting, να προσθέσετε μια δεύτερη υπηρεσία αποστολής ή να εξηγήσετε σε έναν πελάτη γιατί τα email από τη φόρμα επικοινωνίας του καταλήγουν στα spam.

Αυτός ο οδηγός εξετάζει τα MX, SPF, DKIM και DMARC με τη σειρά που θα τα συναντήσετε στην πράξη, με αρκετή λεπτομέρεια ώστε να τα ρυθμίσετε σωστά και αρκετό πλαίσιο ώστε να τα αποσφαλματώσετε όταν χαλάσουν.

Εγγραφές MX: πού πηγαίνει το εισερχόμενο email

Οι εγγραφές MX λένε στο internet ποιοι mail servers δέχονται email για το domain σας. Είναι οι απλούστερες από τις τέσσερις, αλλά και οι πιο εύκολο να ρυθμιστούν λάθος.

Μια εγγραφή MX έχει δύο μέρη: έναν αριθμό προτεραιότητας και ένα hostname. Οι χαμηλότεροι αριθμοί προτεραιότητας δοκιμάζονται πρώτοι. Αν χρησιμοποιείτε Google Workspace, οι εγγραφές MX σας μπορεί να μοιάζουν έτσι:

example.com.  MX  1  aspmx.l.google.com.
example.com.  MX  5  alt1.aspmx.l.google.com.
example.com.  MX  5  alt2.aspmx.l.google.com.

Οι τελείες στο τέλος έχουν σημασία—δηλώνουν ότι το hostname είναι πλήρως προσδιορισμένο. Οι περισσότεροι πάροχοι DNS τις προσθέτουν αυτόματα, αλλά όχι όλοι.

Συνηθισμένα λάθη: να δείχνουν οι εγγραφές MX σε εγγραφή A αντί για hostname, να ορίζονται όλες οι προτεραιότητες στον ίδιο αριθμό (κάτι που ακυρώνει τον σκοπό των εφεδρικών servers), ή να ξεχνάτε να αφαιρέσετε παλιές εγγραφές MX όταν μεταφέρεστε σε άλλον πάροχο. Οι ξεπερασμένες εγγραφές MX δεν μένουν απλώς εκεί ακίνδυνα—μπορούν να προκαλέσουν βρόχους αλληλογραφίας ή διαμοιρασμένη παράδοση σε δύο inboxes.

Αν τρέχετε τη δική σας φόρμα επικοινωνίας και θέλετε να αποφύγετε το spam χωρίς να βασίζεστε σε υπηρεσίες τρίτων, η κατανόηση του πώς οι φόρμες γίνονται φορείς spam είναι ένα χρήσιμο σημείο εκκίνησης.

SPF: ποιοι servers επιτρέπεται να στέλνουν ως εσείς

Το SPF (Sender Policy Framework) είναι μια εγγραφή TXT που παραθέτει τις διευθύνσεις IP και τα domains που είναι εξουσιοδοτημένα να στέλνουν email εκ μέρους του domain σας. Είναι ο πρώτος έλεγχος που εκτελούν οι περισσότεροι mail servers όταν λαμβάνουν ένα μήνυμα που ισχυρίζεται ότι προέρχεται από εσάς.

Μια βασική εγγραφή SPF μοιάζει έτσι:

v=spf1 include:_spf.google.com ~all

Αναλυτικά:

• v=spf1 δηλώνει την έκδοση SPF
• include:_spf.google.com αναθέτει στην εγγραφή SPF της Google
• ~all είναι μια ήπια αποτυχία—απορρίψτε mail από μη καταγεγραμμένες πηγές, αλλά μην είστε υπερβολικά αυστηροί

Μπορείτε επίσης να χρησιμοποιήσετε ip4: ή ip6: για να επιτρέψετε συγκεκριμένες διευθύνσεις, ή a και mx για να αναφερθείτε στις εγγραφές A και MX του domain σας. Ο μηχανισμός all στο τέλος ελέγχει τι συμβαίνει με mail από πηγές που δεν παραθέσατε: το -all είναι σκληρή αποτυχία (απόρριψη), το ~all είναι ήπια αποτυχία (σήμανση ως ύποπτο), το ?all είναι ουδέτερο (καμία άποψη) και το +all είναι πλήρης ελευθερία για όλους (μην το χρησιμοποιείτε).

Το SPF έχει δύο αιχμηρά σημεία. Πρώτον, χαλάει όταν γίνεται προώθηση email, επειδή ο server προώθησης δεν βρίσκεται στην εγγραφή SPF σας. Δεύτερον, οι εγγραφές SPF έχουν όριο αναζήτησης δέκα DNS queries. Αν συμπεριλάβετε πάρα πολλές υπηρεσίες τρίτων, θα υπερβείτε το όριο και το SPF θα σταματήσει να λειτουργεί. Η λύση είναι να επιπεδοποιήσετε την εγγραφή SPF σας—να αντικαταστήσετε τις οδηγίες include: με τα πραγματικά εύρη IP—αλλά αυτό απαιτεί συντήρηση όταν οι πάροχοι αλλάζουν τις IP τους.

DKIM: κρυπτογραφική απόδειξη της ταυτότητας αποστολέα

Το DKIM (DomainKeys Identified Mail) προσθέτει μια ψηφιακή υπογραφή στο εξερχόμενο email σας. Ο server λήψης ελέγχει την υπογραφή απέναντι σε ένα δημόσιο κλειδί που δημοσιεύεται στο DNS σας. Αν η υπογραφή είναι έγκυρη και το μήνυμα δεν έχει αλλοιωθεί, το DKIM περνά.

Σε αντίθεση με το SPF, το DKIM επιβιώνει από την προώθηση, επειδή η υπογραφή ταξιδεύει μαζί με το μήνυμα. Είναι επίσης πιο ευέλικτο—μπορείτε να έχετε πολλαπλά κλειδιά DKIM για διαφορετικές υπηρεσίες αποστολής, το καθένα με τον δικό του selector.

Μια εγγραφή DNS DKIM μοιάζει έτσι:

default._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Ο selector (default σε αυτό το παράδειγμα) είναι αυθαίρετος—τον επιλέγει ο πάροχος email σας. Η τιμή p= είναι το δημόσιο κλειδί, συνήθως μια μακριά συμβολοσειρά κωδικοποιημένη σε base64. Ο πάροχος email σας δημιουργεί το ιδιωτικό κλειδί και το χρησιμοποιεί για να υπογράφει εξερχόμενα μηνύματα.

Η ρύθμιση DKIM σχεδόν πάντα γίνεται από τον πάροχο email σας. Η δική σας δουλειά είναι να αντιγράψετε την εγγραφή TXT που σας δίνει και να την επικολλήσετε στο DNS σας. Το δύσκολο σημείο είναι ότι ορισμένοι πάροχοι DNS δεν χειρίζονται καλά τις μεγάλες εγγραφές TXT—είτε τις περικόπτουν είτε απαιτούν να χωρίσετε την τιμή σε πολλαπλές συμβολοσειρές μέσα σε εισαγωγικά.

Για να επαληθεύσετε ότι το DKIM λειτουργεί, στείλτε ένα δοκιμαστικό email σε μια διεύθυνση Gmail και ελέγξτε τα headers. Αναζητήστε dkim=pass στο header Authentication-Results.

DMARC: επιβολή πολιτικής και reporting

Το DMARC (Domain-based Message Authentication, Reporting and Conformance) συνδέει SPF και DKIM και λέει στους servers λήψης τι να κάνουν όταν ο έλεγχος ταυτότητας αποτυγχάνει. Ενεργοποιεί επίσης reporting, ώστε να μπορείτε να δείτε ποιος στέλνει email ως το domain σας—τόσο νόμιμα όσο και πλαστογραφημένα.

Μια ελάχιστη εγγραφή DMARC μοιάζει έτσι:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p=none σημαίνει μόνο παρακολούθηση—μην απορρίπτετε ή θέτετε σε καραντίνα αποτυχημένα μηνύματα
• rua=mailto:[email protected] καθορίζει πού θα αποστέλλονται οι συγκεντρωτικές αναφορές

Μόλις είστε βέβαιοι ότι SPF και DKIM λειτουργούν, μπορείτε να αυστηροποιήσετε την πολιτική σε p=quarantine (αποστολή αποτυχιών στα spam) ή p=reject (άμεσο bounce). Μπορείτε επίσης να ορίσετε πολιτική subdomain με sp= και να καθορίσετε ποσοστό μηνυμάτων στα οποία θα εφαρμόζεται η πολιτική με pct=.

Οι αναφορές DMARC είναι αρχεία XML που αποστέλλονται καθημερινά από μεγάλους παραλήπτες. Είναι εκτενείς και δύσκολες να διαβαστούν ως raw, αλλά σας λένε ακριβώς ποια μηνύματα πέρασαν ή απέτυχαν στον έλεγχο ταυτότητας και γιατί. Αν βλέπετε νόμιμο mail να απορρίπτεται, οι αναφορές θα σας δείξουν ποιος έλεγχος SPF ή DKIM αποτυγχάνει.

Ένα σημείο-παγίδα: το DMARC απαιτεί ευθυγράμμιση. Για το SPF, το domain στο header Return-Path πρέπει να ταιριάζει με το domain στο header From (ή να είναι subdomain). Για το DKIM, το domain d= στην υπογραφή DKIM πρέπει να ταιριάζει με το domain From. Αν χρησιμοποιείτε υπηρεσία αποστολής τρίτου, πρέπει να υποστηρίζει προσαρμοσμένα return paths ή υπογραφή DKIM με το δικό σας domain, όχι το δικό της.

Πώς να ελέγξετε την τρέχουσα ρύθμισή σας

Τα περισσότερα προβλήματα DNS είναι αόρατα μέχρι να προκαλέσουν πρόβλημα. Δείτε πώς να ελέγξετε τις εγγραφές σας πριν χαλάσει κάτι:

1. Query των εγγραφών MX: dig MX example.com πρέπει να επιστρέφει τα hostnames και τις προτεραιότητες των mail servers σας. Επαληθεύστε ότι ταιριάζουν με την τεκμηρίωση του παρόχου email σας.

1. Έλεγχος σύνταξης SPF: dig TXT example.com και αναζητήστε την εγγραφή v=spf1. Περάστε τη από έναν SPF validator για να εντοπίσετε συντακτικά λάθη και παραβιάσεις του ορίου αναζητήσεων.

1. Επαλήθευση κλειδιών DKIM: Στείλτε ένα δοκιμαστικό email και ελέγξτε το header DKIM-Signature. Εξαγάγετε τον selector και το domain, έπειτα κάντε query dig TXT selector._domainkey.example.com για να επιβεβαιώσετε ότι υπάρχει το δημόσιο κλειδί.

1. Επικύρωση πολιτικής DMARC: dig TXT _dmarc.example.com πρέπει να επιστρέφει την εγγραφή DMARC σας. Βεβαιωθείτε ότι το rua= δείχνει σε διεύθυνση που παρακολουθείτε πραγματικά.

1. Δοκιμή από άκρο σε άκρο: Χρησιμοποιήστε μια υπηρεσία όπως το mail-tester.com ή στείλτε σε μια διεύθυνση Gmail και ελέγξτε τα πλήρη headers. Αναζητήστε spf=pass, dkim=pass και dmarc=pass στο header Authentication-Results.

Αν κάνετε debugging για το γιατί τα email δεν φτάνουν, τα headers είναι το καλύτερο εργαλείο σας. Οι περισσότεροι mail clients σάς επιτρέπουν να δείτε raw headers—στο Gmail, ανοίξτε το μήνυμα, κάντε κλικ στις τρεις τελείες και επιλέξτε 'Εμφάνιση πρωτοτύπου'. Το header Authentication-Results θα σας πει ακριβώς ποιος έλεγχος απέτυχε και γιατί.

Πότε να χρησιμοποιείτε πολιτικές subdomain

Αν στέλνετε email από πολλαπλά subdomains—π.χ. newsletter.example.com για marketing και app.example.com για transactional mail—μπορείτε να ορίσετε πολιτικές DMARC ανά subdomain. Αυτό σας επιτρέπει να επιβάλλετε αυστηρές πολιτικές σε subdomains που ελέγχετε, διατηρώντας παράλληλα πιο χαλαρή πολιτική στο κύριο domain σας.

Το αντάλλαγμα είναι η πολυπλοκότητα. Κάθε subdomain χρειάζεται τις δικές του εγγραφές SPF, DKIM και DMARC, και πρέπει να παρακολουθείτε ποιες υπηρεσίες αποστολής είναι εξουσιοδοτημένες για ποια subdomains. Για τις περισσότερες μικρές ομάδες, ένα μόνο καλά ρυθμισμένο domain είναι απλούστερο και εξίσου ασφαλές.

Τι να κάνετε όταν χαλάσει ο έλεγχος ταυτότητας

Ο πιο συνηθισμένος τρόπος αποτυχίας είναι η προσθήκη μιας νέας υπηρεσίας αποστολής χωρίς ενημέρωση του DNS. Αν αρχίσετε να χρησιμοποιείτε νέο πάροχο transactional email, πρέπει να προσθέσετε το SPF include ή το εύρος IP του, να ρυθμίσετε υπογραφή DKIM με το domain σας και να επαληθεύσετε την ευθυγράμμιση DMARC.

Το δεύτερο πιο συνηθισμένο πρόβλημα είναι η προώθηση. Αν οι χρήστες προωθούν το email σας σε άλλη διεύθυνση, το SPF θα αποτύχει επειδή ο server προώθησης δεν βρίσκεται στην εγγραφή SPF σας. Το DKIM συνήθως επιβιώνει από την προώθηση, οπότε εφόσον το DKIM περνά και η πολιτική DMARC σας επιτρέπει μερική ευθυγράμμιση, το μήνυμα θα πρέπει να παραδοθεί. Αν βλέπετε προωθημένο mail να απορρίπτεται, ελέγξτε την πολιτική DMARC σας—το p=reject με αυστηρή ευθυγράμμιση θα σπάσει την προώθηση.

Το τρίτο ζήτημα είναι η διάδοση DNS. Οι αλλαγές σε εγγραφές DNS μπορεί να χρειαστούν ώρες για να διαδοθούν, και διαφορετικοί mail servers αποθηκεύουν εγγραφές στην cache για διαφορετικά χρονικά διαστήματα. Αν μόλις ενημερώσατε μια εγγραφή και δεν λειτουργεί, περιμένετε μερικές ώρες και δοκιμάστε ξανά. Μπορείτε να ελέγξετε τη διάδοση με ένα εργαλείο όπως το whatsmydns.net.

Βασικά συμπεράσματα

• Οι εγγραφές MX δρομολογούν το εισερχόμενο mail· τα SPF, DKIM και DMARC πιστοποιούν το εξερχόμενο mail. Λύνουν διαφορετικά προβλήματα και χρειάζεστε και τα τέσσερα.
• Το SPF χαλάει στην προώθηση και έχει όριο δέκα αναζητήσεων. Το DKIM επιβιώνει από την προώθηση αλλά απαιτεί ρύθμιση ανά υπηρεσία. Το DMARC τα συνδέει και ενεργοποιεί reporting.
• Ξεκινήστε με p=none στο DMARC, παρακολουθήστε τις αναφορές για μερικές εβδομάδες και μετά αυστηροποιήστε σε p=quarantine ή p=reject μόλις είστε βέβαιοι ότι το νόμιμο mail περνά.
• Τα σφάλματα DNS είναι σιωπηλά. Δοκιμάστε τη ρύθμισή σας με πραγματικό email και ελέγξτε τα headers για να επιβεβαιώσετε ότι SPF, DKIM και DMARC περνούν.
• Αν ο έλεγχος ταυτότητας χαλάσει μετά την προσθήκη νέας υπηρεσίας αποστολής, ελέγξτε τα SPF includes, τους DKIM selectors και την ευθυγράμμιση DMARC. Τα headers θα σας πουν ποιος έλεγχος απέτυχε.

FAQ

Q: Μπορώ να έχω πολλαπλές εγγραφές SPF;

A: Όχι. Οι πολλαπλές εγγραφές SPF θα προκαλέσουν την αγνόηση όλων τους. Αν χρειάζεται να εξουσιοδοτήσετε πολλαπλές υπηρεσίες, χρησιμοποιήστε οδηγίες include: μέσα σε μία μόνο εγγραφή SPF ή παραθέστε απευθείας εύρη IP. Προσέξτε το όριο των δέκα αναζητήσεων.

Q: Χρειάζομαι DMARC αν στέλνω μόνο λίγα email την ημέρα;

A: Ναι. Το DMARC δεν αφορά τον όγκο—αφορά την απόδειξη ότι είστε αυτός που λέτε ότι είστε. Ακόμη και μικρά domains ωφελούνται από το DMARC, επειδή αποτρέπει την πλαστογράφηση και σας δίνει ορατότητα σε προβλήματα παράδοσης. Ξεκινήστε με p=none και μια διεύθυνση reporting.

Q: Τι συμβαίνει αν DKIM και SPF αποτύχουν και τα δύο, αλλά το email φαίνεται νόμιμο;

A: Εξαρτάται από την πολιτική DMARC σας. Αν είναι p=none, το mail παραδίδεται με προειδοποίηση. Αν είναι p=quarantine, πηγαίνει στα spam. Αν είναι p=reject, γίνεται bounce. Γι' αυτό πρέπει να παρακολουθείτε τις αναφορές DMARC πριν επιβάλετε αυστηρή πολιτική—μπορεί να έχετε νόμιμους αποστολείς που δεν γνωρίζατε.

Q: Μπορώ να χρησιμοποιήσω το ίδιο κλειδί DKIM για πολλαπλά domains;

A: Τεχνικά ναι, αλλά μην το κάνετε. Κάθε domain πρέπει να έχει το δικό του ζεύγος κλειδιών DKIM. Η κοινή χρήση κλειδιών κάνει την περιστροφή δυσκολότερη και αυξάνει την έκταση της ζημιάς αν παραβιαστεί ένα ιδιωτικό κλειδί.

Q: Πόσο συχνά πρέπει να κάνω rotation στα κλειδιά DKIM;

A: Δεν υπάρχει καθολικός κανόνας, αλλά μία φορά τον χρόνο είναι λογικό για τα περισσότερα domains. Αν υποψιάζεστε ότι ένα κλειδί έχει παραβιαστεί, κάντε rotation αμέσως. Βεβαιωθείτε ότι δημοσιεύετε το νέο δημόσιο κλειδί στο DNS πριν αρχίσετε να υπογράφετε με το νέο ιδιωτικό κλειδί, και αφήστε το παλιό κλειδί στο DNS για μερικές ημέρες μετά το rotation ώστε να καλύψετε καθυστερημένο mail.

<!-- tool-cta:start -->

💡 Δοκιμάστε αυτό: Ελέγξτε τη δημοσιευμένη πολιτική οποιουδήποτε τομέα με το DMARC Lookup, για να δείτε πώς συνδυάζονται στην πράξη οι εγγραφές MX, SPF και DMARC.

<!-- tool-cta:end -->

Πηγές

• RFC 7208: Sender Policy Framework (SPF) — Η προδιαγραφή SPF, συμπεριλαμβανομένων των κανόνων σύνταξης και του ορίου των δέκα αναζητήσεων.
• RFC 6376: DomainKeys Identified Mail (DKIM) — Η προδιαγραφή DKIM, που καλύπτει τη δημιουργία και την επαλήθευση υπογραφών.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — Η προδιαγραφή DMARC, συμπεριλαμβανομένης της σύνταξης πολιτικών και της μορφής συγκεντρωτικού reporting.
• Google Workspace: Prevent spoofing and spam — Πρακτική καθοδήγηση για τη ρύθμιση SPF, DKIM και DMARC σε domains Google Workspace.