Cloud & Infrastructure

Πώς ρυθμίζουμε SPF, DKIM και DMARC για να μη πηγαίνουν τα εταιρικά emails στα spam

Πρακτικό tutorial για SPF, DKIM και DMARC σε DNS και Cloudflare, με ασφαλή μετάβαση από p=none σε quarantine και reject.

ichiphost 8 λεπτά ανάγνωσης
Επαγγελματίας ελέγχει εταιρικά emails σε laptop για SPF DKIM και DMARC

Αν τα εταιρικά emails πηγαίνουν στα spam, το πρώτο πράγμα που πρέπει να ελέγξουμε δεν είναι το subject ή το logo. Είναι το DNS του domain. Εκεί δηλώνουμε ποιοι servers επιτρέπεται να στέλνουν email για λογαριασμό της επιχείρησης, πώς υπογράφονται τα μηνύματα και τι πρέπει να κάνει ο παραλήπτης όταν κάτι φαίνεται ύποπτο.

Το 2026 αυτό δεν είναι λεπτομέρεια για τεχνικούς. Gmail, Outlook και Yahoo έχουν γίνει πιο αυστηρά με το email authentication, ειδικά για domains που στέλνουν πολλά μηνύματα ή έχουν newsletter, φόρμες, e-shop, CRM και αυτοματισμούς. Το αποτέλεσμα είναι απλό: ένα domain χωρίς σωστό SPF, DKIM και DMARC έχει χειρότερη αξιοπιστία και είναι πιο εύκολο να χρησιμοποιηθεί σε spoofing ή phishing.

Σε αυτό το tutorial θα δούμε πρακτικά τι σημαίνει κάθε record, τι βάζουμε στο DNS και πώς γίνεται η ίδια διαδικασία μέσα από το Cloudflare. Τα παραδείγματα είναι ενδεικτικά. Πριν τα αντιγράψετε, πρέπει να ξέρετε ποιος πραγματικά στέλνει email για το δικό σας domain.

Διάγραμμα που δείχνει πώς SPF DKIM και DMARC ελέγχουν ένα εταιρικό email
Η απλή λογική: ο παραλήπτης κοιτάζει DNS records και αποφασίζει αν το email είναι αξιόπιστο.

Τι πρόβλημα λύνουν SPF, DKIM και DMARC;

Τα συνηθισμένα συμπτώματα είναι γνωστά. Στέλνετε προσφορά και ο πελάτης δεν τη βλέπει. Η φόρμα επικοινωνίας του WordPress στέλνει ειδοποιήσεις που καταλήγουν στα spam. Το WooCommerce ή το PrestaShop στέλνει παραγγελίες από τον server του site, ενώ το κανονικό email της εταιρείας είναι σε Google Workspace ή Microsoft 365. Ή, ακόμη χειρότερα, κάποιος προσπαθεί να στείλει ψεύτικα emails σαν να είναι από το domain σας.

Το SPF, το DKIM και το DMARC δεν εγγυώνται από μόνα τους ότι κάθε email θα μπαίνει πάντα στο inbox. Η φήμη του domain, το περιεχόμενο, οι λίστες παραληπτών και η συμπεριφορά των χρηστών συνεχίζουν να παίζουν ρόλο. Όμως χωρίς σωστό authentication ξεκινάτε με σοβαρό μειονέκτημα.

Πριν πειράξετε DNS: γράψτε ποιοι στέλνουν email

Το πιο σημαντικό βήμα γίνεται πριν ανοίξουμε Cloudflare ή cPanel. Φτιάχνουμε μια μικρή λίστα με όλες τις πηγές που στέλνουν email για το domain:

  • Google Workspace, Microsoft 365, Zoho ή άλλο mail provider.
  • cPanel mail ή SMTP server του hosting.
  • WordPress, WooCommerce, PrestaShop, Laravel ή custom site που στέλνει φόρμες και παραγγελίες.
  • Newsletter εργαλεία όπως Mailchimp, Brevo, MailerLite ή άλλο ESP.
  • CRM, τιμολόγηση, helpdesk, booking, ERP ή automation πλατφόρμες.

Αν ξεχάσουμε μια νόμιμη πηγή και βάλουμε αυστηρό DMARC πολύ γρήγορα, μπορεί να κόψουμε πραγματικά emails. Για αυτό ξεκινάμε με monitoring και περνάμε σταδιακά σε enforcement.

Βήμα 1: SPF – ποιοι servers επιτρέπεται να στέλνουν;

Το SPF είναι ένα TXT record στο DNS. Λέει στους παραλήπτες ποιοι servers επιτρέπεται να στείλουν email για το domain. Αν χρησιμοποιείτε μόνο Google Workspace, ένα απλό παράδειγμα είναι:

Type: TXT
Name: @
Value: v=spf1 include:_spf.google.com ~all

Αν χρησιμοποιείτε μόνο Microsoft 365, ένα συνηθισμένο παράδειγμα είναι:

Type: TXT
Name: @
Value: v=spf1 include:spf.protection.outlook.com ~all

Αν έχετε περισσότερους από έναν αποστολέα, δεν βάζετε δεύτερο SPF record. Τα ενώνετε σε ένα:

Type: TXT
Name: @
Value: v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:spf.example-newsletter.com ~all

Το ~all σημαίνει soft fail. Είναι πιο ασφαλές στην αρχή, γιατί δεν κόβει επιθετικά κάθε αποτυχία. Το -all είναι πιο αυστηρό και μπαίνει μόνο όταν είστε σίγουροι ότι έχουν δηλωθεί όλοι οι αποστολείς. Επίσης, δεν πρέπει να υπάρχουν δύο διαφορετικά SPF records στο ίδιο domain. Αυτό είναι από τα πιο συχνά λάθη.

Βήμα 2: DKIM – η ψηφιακή υπογραφή του email

Το DKIM υπογράφει το email με κρυπτογραφικό τρόπο. Ο mail provider κρατάει το private key και στο DNS δημοσιεύουμε το public key. Έτσι ο παραλήπτης μπορεί να ελέγξει ότι το μήνυμα δεν αλλοιώθηκε και ότι υπογράφηκε από εξουσιοδοτημένη υπηρεσία.

Συνήθως δεν γράφουμε μόνοι μας το DKIM. Το παίρνουμε από τον provider. Στο Google Workspace δημιουργείται μέσα από το Admin console. Στο Microsoft 365 συνήθως δίνονται CNAME records για selector1 και selector2. Στο cPanel υπάρχει συνήθως ενότητα Email Deliverability που δείχνει SPF και DKIM.

Ένα απλοποιημένο παράδειγμα DKIM TXT record είναι:

Type: TXT
Name: selector1._domainkey
Value: v=DKIM1; k=rsa; p=PUBLIC_KEY_HERE

Στην πράξη, αν ο provider δίνει CNAME αντί για TXT, βάζουμε CNAME. Δεν μετατρέπουμε μόνοι μας τον τύπο record. Αν δίνει selector με άλλο όνομα, χρησιμοποιούμε αυτό που δίνει.

Βήμα 3: DMARC – τι κάνουμε όταν κάτι αποτυγχάνει;

Το DMARC συνδέει SPF/DKIM με το domain που βλέπει ο χρήστης στο πεδίο From. Δηλαδή δεν αρκεί κάτι να περάσει τεχνικά SPF ή DKIM. Πρέπει να ευθυγραμμίζεται και με το domain που εμφανίζεται ως αποστολέας.

Η σωστή αρχή είναι monitoring:

Type: TXT
Name: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.gr; adkim=s; aspf=s

Με p=none δεν μπλοκάρεται τίποτα. Παίρνετε reports για να δείτε ποιοι στέλνουν για το domain και ποιοι αποτυγχάνουν. Για μικρό όγκο μπορείτε να βάλετε ένα mailbox όπως dmarc@yourdomain.gr. Για μεγαλύτερο όγκο είναι καλύτερο ένα DMARC reporting εργαλείο, γιατί τα reports είναι XML και δεν είναι φιλικά για καθημερινή ανάγνωση.

Μετά από έλεγχο, μπορούμε να πάμε σε πιο αυστηρή πολιτική:

Type: TXT
Name: _dmarc
Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.gr; adkim=s; aspf=s

Το τελικό επίπεδο είναι:

Type: TXT
Name: _dmarc
Value: v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.gr; adkim=s; aspf=s

Προσοχή: μην βάζετε κατευθείαν p=reject αν δεν ξέρετε όλους τους servers που στέλνουν emails για το domain σας. Μπορεί να μπλοκάρετε νόμιμα emails από φόρμες επικοινωνίας, CRM, newsletter, e-shop, τιμολόγηση ή αυτοματισμούς.

Επίσης τα adkim=s και aspf=s σημαίνουν strict alignment. Είναι σωστός στόχος για καθαρή ρύθμιση, αλλά σε σύνθετα περιβάλλοντα μπορεί να χρειαστεί αρχικά relaxed alignment ή πιο προσεκτική μετάβαση. Δεν είναι ντροπή να ξεκινήσετε συντηρητικά. Το λάθος είναι να περάσετε σε reject χωρίς δεδομένα.

Διάγραμμα ασφαλούς μετάβασης DMARC από p none σε quarantine και reject
Η πρακτική διαδρομή: πρώτα παρακολούθηση, μετά quarantine και στο τέλος reject.

Πώς γίνεται στο Cloudflare

Αν το domain σας έχει nameservers στο Cloudflare, τότε οι DNS αλλαγές γίνονται από το Cloudflare, όχι από το cPanel ή τον registrar. Αυτό είναι κρίσιμο. Μπορεί το hosting να σας δείχνει τι πρέπει να βάλετε, αλλά αν authoritative DNS είναι το Cloudflare, τα records πρέπει να μπουν εκεί.

  1. Συνδέεστε στο Cloudflare και ανοίγετε το domain.
  2. Πηγαίνετε στο DNS και μετά Records.
  3. Πατάτε Add record.
  4. Για SPF επιλέγετε TXT, στο Name βάζετε @ και στο Content βάζετε το SPF value.
  5. Για DKIM βάζετε ακριβώς τον τύπο record που δίνει ο provider: TXT ή CNAME.
  6. Για DMARC επιλέγετε TXT, στο Name βάζετε _dmarc και στο Content το DMARC value.
  7. Το TTL μπορεί να μείνει στο Auto.
  8. Πατάτε Save και μετά κάνετε έλεγχο με test email.

Στα TXT records το Cloudflare μπορεί να προσθέσει μόνο του εισαγωγικά. Δεν χρειάζεται να παλέψετε με quotes αν το value σώζεται σωστά. Για DKIM CNAME records, αν υπάρχει επιλογή proxy, κρατάμε DNS only. Το email authentication δεν είναι HTTP traffic και δεν περνάει από το πορτοκαλί cloud proxy.

Παράδειγμα Cloudflare DNS records για SPF DKIM και DMARC
Παράδειγμα οργάνωσης DNS records στο Cloudflare. Οι πραγματικές τιμές πρέπει να έρχονται από τον δικό σας mail provider.

Αν έχετε cPanel mail ή hosting email

Σε πολλά hosting πακέτα, το cPanel έχει εργαλείο Email Deliverability. Εκεί συνήθως βλέπετε αν SPF και DKIM περνάνε ή λείπουν. Αν το domain δεν χρησιμοποιεί Cloudflare, το cPanel μπορεί να τα διορθώσει αυτόματα. Αν όμως το DNS είναι στο Cloudflare, το cPanel δεν μπορεί να δημοσιεύσει μόνο του τα records. Πρέπει να αντιγράψετε τις τιμές στο Cloudflare.

Για WordPress sites, μια συχνή σωστή λύση είναι SMTP plugin που στέλνει μέσω του πραγματικού mail provider, αντί ο web server να στέλνει μόνος του. Έτσι οι φόρμες επικοινωνίας, τα WooCommerce emails και οι ειδοποιήσεις του site περνάνε μέσα από υποδομή που έχει σωστό SPF/DKIM.

Πώς ελέγχουμε ότι δουλεύει

Μετά την αλλαγή DNS περιμένουμε λίγο και στέλνουμε test email σε Gmail, Outlook και Yahoo. Στο Gmail μπορείτε να ανοίξετε το μήνυμα και να επιλέξετε Show original. Εκεί πρέπει να βλέπετε SPF, DKIM και DMARC pass. Αν κάποιο failάρει, δεν προχωράμε σε quarantine ή reject.

Τα DMARC reports δεν είναι άμεσα. Συνήθως θέλουν χρόνο και αρκετή κίνηση για να βγάλουν χρήσιμο συμπέρασμα. Για μικρή επιχείρηση, ελέγχουμε για μερικές ημέρες έως λίγες εβδομάδες, ανάλογα με τον όγκο αποστολών. Για domain που στέλνει newsletter ή transactional emails, η παρακολούθηση πρέπει να είναι πιο προσεκτική.

Τα συχνότερα λάθη

  • Δύο SPF records στο ίδιο domain αντί για ένα ενιαίο record.
  • SPF που περιλαμβάνει μόνο Google ή Microsoft, ενώ το site στέλνει emails από τον web server.
  • DKIM record δημοσιευμένο στο λάθος DNS panel.
  • Newsletter που στέλνει με From το domain σας χωρίς σωστό domain authentication.
  • Φόρμες επικοινωνίας που βάζουν ως From το email του πελάτη αντί για εταιρικό address του domain.
  • Άμεση μετάβαση σε p=reject χωρίς DMARC reports.
  • Αλλαγές στο cPanel ενώ το πραγματικό DNS είναι στο Cloudflare.

Checklist πριν θεωρήσουμε ότι τελειώσαμε

  • Έχουμε καταγράψει όλους τους mail senders.
  • Υπάρχει μόνο ένα SPF record.
  • Το SPF περιλαμβάνει όλους τους νόμιμους αποστολείς.
  • Το DKIM είναι ενεργό στον mail provider και δημοσιευμένο στο DNS.
  • Το DMARC ξεκινά σε p=none για monitoring.
  • Τα reports δείχνουν ποιοι περνάνε και ποιοι αποτυγχάνουν.
  • Πηγαίνουμε σταδιακά σε quarantine.
  • Μόνο μετά περνάμε σε reject.
  • Κάνουμε test από φόρμα site, e-shop, CRM και newsletter, όχι μόνο από το webmail.

Ασφαλής πορεία εφαρμογής

Το SPF, το DKIM και το DMARC είναι από τις πιο πρακτικές ρυθμίσεις που μπορεί να κάνει μια επιχείρηση για να προστατεύσει το domain της και να βελτιώσει την αξιοπιστία των emails της. Δεν είναι μαγικό κουμπί για inbox placement, αλλά είναι η βάση. Χωρίς αυτά, κάθε υπόλοιπη προσπάθεια για deliverability ξεκινάει στραβά.

Η σωστή προσέγγιση είναι απλή: βρίσκουμε όλους τους αποστολείς, δημοσιεύουμε SPF και DKIM, ξεκινάμε DMARC με reports και μόνο αφού δούμε καθαρά δεδομένα περνάμε σε πιο αυστηρή πολιτική.

Αν τα emails της επιχείρησής σας πηγαίνουν στα spam ή θέλετε σωστή ρύθμιση SPF, DKIM και DMARC, μπορούμε να ελέγξουμε το domain σας και να προτείνουμε ασφαλή ρύθμιση χωρίς να χαθούν νόμιμα emails. Επικοινωνήστε με την iChipHost για τεχνικό έλεγχο DNS, hosting και email deliverability.

Πηγές

#Business Email #DKIM #DMARC #Email Deliverability #SPF #Technical SEO
ΣΥΝΕΧΙΣΤΕ ΤΗΝ ΑΝΑΓΝΩΣΗ

Σχετικά Άρθρα

Επιλεγμένα άρθρα με κοινή θεματολογία, κατηγορία ή ετικέτες.

Όλα τα άρθρα

AI

AI plugins για WordPress και e-shop: οδηγός 2026

Εικόνα: Drew Williams μέσω Pexels License, με editorial επεξεργασία από iChipHost. Πηγή εικόνας. Συντάκτης: Ιωάννης Παπαδάκης, IT Manager Το πιο συχνό λάθος με τα AI plugins είναι ότι ξεκινάμε από το όνομα του μοντέλου:...

AI

Codex, Sol, Fable και τα νέα AI εργαλεία: ποιο χρησιμοποιούμε και πότε

Εικόνα: Rahul Pandit μέσω Pexels License, με editorial επεξεργασία από iChipHost. Πηγή εικόνας. Συντάκτης: Ιωάννης Παπαδάκης, IT Manager Το 2026 η συζήτηση για την τεχνητή νοημοσύνη έχει περάσει σε άλλο επίπεδο. Δεν μιλάμε πια...

Κλήση τώρα Ζητήστε προσφορά