Sådan konfigureres DNS TXT-zonen til SPF, DKIM og DMARC, og hvordan du forhindrer, at virksomheds-e-mail-beskeder bliver afvist af Gmail - Maillevering mislykkedes

Administratorii af alvorlig privat e-mail til erhvervslivet det står ofte over for mange problemer og udfordringer. Fra bølgerne af SPAM som skal blokeres af specifikke filtre, korrespondancesikkerhed i den lokale e-mail-server og fjernservere, konfiguration si overvågning af SMTP-tjenester, POP, IMAPplus masser af andre detaljer SPF, DKIM og DMARC konfiguration at følge bedste praksis for sikker e-mail.

Mange problemer sende e-mails eller modtager til/fra dine udbydere, vises på grund af forkert konfiguration af området DNS, hvad med e-mail-tjenesten.

For at e-mails kan sendes fra et domænenavn, skal det være det hostet på en e-mail-server Korrekt konfigureret, og domænenavn for at have DNS-zoner for SPF, MX, DMARC SI dkim udvidelse indstillet korrekt i manageren TXT DNS af domænet.

I dagens artikel vil vi fokusere på et ret almindeligt problem private e-mail-servere til virksomheder. Kan ikke sende e-mail til Gmail, Yahoo! eller iCloud.

Beskeder sendt til @ Gmail.com afvises automatisk. "Levering af besked fejlede: returnerer besked til afsender"

Jeg stødte for nylig på et problem på et e-mail-domæne for en virksomhed, hvorfra der jævnligt sendes e-mails til andre virksomheder og til enkeltpersoner, hvoraf nogle har adresser @ Gmail.com. Alle meddelelser sendt til Gmail-konti returneres straks til afsenderen. "Levering af besked fejlede: returnerer besked til afsender".

Fejlmeddelelse returneret til e-mail-serveren på EXIM ser sådan ud:

1nSeUV-0005zz-De ** reciver@gmail.com R=dnslookup T=remote_smtp H=gmail-smtp-in.l.google.com [142.x.x.27] X=TLS1.2:ECDHE-ECDSA-AES128-GCM-SHA256:128 CV=yes: SMTP error from remote mail server after pipelined end of data: 550-5.7.26 This message does not have authentication information or fails to\n550-5.7.26 pass authentication checks. To best protect our users from spam, the\n550-5.7.26 message has been blocked. Please visit\n550-5.7.26  https://support.google.com/mail/answer/81126#authentication for more\n550 5.7.26 information. d3-20020adff843000000b001f1d7bdaeb7si6107985wrq.510 - gsmtp

I dette scenarie er det ikke noget særligt alvorligt, som f.eks inkludere det afsendende domænenavn eller den afsendende IP i en SPAM-liste global eller o større konfigurationsfejl af e-mail-tjenester på server (EXIM).
Selvom mange mennesker ser denne meddelelse med det samme, når de tænker på SPAM eller en SMTP-konfigurationsfejl, er problemet genereret af området. TXT DNS af domænet. Det meste af tiden er DKIM ikke konfigureret i DNS-zonen eller sendes ikke korrekt i domænets DNS-manager. Dette problem findes ofte hos dem, der bruger det CloudFlare som DNS Manager og glem at bestå TXT DNS: mail._domainkey (dkim udvidelse), DMARC si SPF.

Som Gmails afvisningsmeddelelse fortæller os, er ægtheden og godkendelsen af ​​afsenderdomænet mislykket. “Denne meddelelse har ikke godkendelsesoplysninger eller klarer ikke \ n550-5.7.26 godkendelseskontroller." Det betyder, at domænet ikke har DNS TXT konfigureret til at sikre troværdighed for modtagerens e-mail-server. Gmail, i vores script.

Når vi tilføjer et webdomæne med en aktiv e-mail-tjeneste på dets cPanel VestaCP, filerne i DNS-området på det respektive domæne oprettes også automatisk. DNS-zone, der inkluderer konfigurationen af ​​e-mail-tjenesten: MX, SPF, dkim udvidelse, DMARC.
I den situation, hvor vi vælger domænet til at være manager CloudFlare DNS, skal DNS-området på domænets hostingkonto kopieres til CloudFlare, for at e-mail-domænet kan fungere korrekt. Det var problemet i ovenstående scenarie. I en tredjeparts DNS-manager findes DKIM-registrering ikke, selvom den findes på den lokale servers DNS-manager.

Hvad er DKIM, og hvorfor afvises e-mails, hvis vi ikke har denne funktion på et e-mail-domæne?

DomainKeys Identified Mail (DKIM) er en standard e-mail domænegodkendelsesløsning, der tilføjer en Digitale signaturer hver sendt besked. Destinationsserverne kan gennem DKIM tjekke, om beskeden kommer fra afsenderens lovdomæne og ikke fra et andet domæne, der bruger afsenderens identitet som maske. Efter alt at dømme, hvis du har domænet abcdqwerty.com uden DKIM kan e-mails sendes fra andre servere ved hjælp af dit domænenavn. Det er hvis man ønsker et identitetstyveri, som på fagsprog hedder e-mail-spoofing.
En almindelig teknik, når du sender e-mails Phishing si spam.

Det kan også sikres gennem DKIM, at indholdet af beskeden blev ikke ændret, efter at den blev sendt af afsenderen.

At have DKIM korrekt indstillet på e-mailsystemets strenge vært og i DNS-området eliminerer også muligheden for, at dine beskeder kan nå SPAM til modtageren eller slet ikke nås.

Et eksempel på en DKIM er:

mail._domainkey: "v=DKIM1; k=rsa; p=MIGfMA0GCSqGfdSIb3DQEBAQUAA4GN ... ocqWffd4cwIDAQAB"

Selvfølgelig er DKIM-værdien opnået ved RSA krypteringsalgoritme er unikt for hvert domænenavn og kan regenereres fra værtens e-mail-server.

At have DKIM installeret og indstillet korrekt TXT DNS manager, er det meget muligt at løse problemet med beskeder, der returneres til Gmail-konti. I det mindste for fejlen "Maillevering mislykkedes":

"SMTP error fra ekstern mailserver efter pipelinet afslutning af data: 550-5.7.26 Denne meddelelse har ikke godkendelsesoplysninger eller klarer ikke \ n550-5.7.26 godkendelsestjek. For bedst muligt at beskytte vores brugere mod spam, er \ n550-5.7.26-meddelelsen blevet blokeret. ”

Som en kort opsummering, DKIM tilføjer en digital signatur til hver meddelelse, der sendes, som gør det muligt for destinationsserverne at verificere afsenderens ægthed. Hvis beskeden kom fra din virksomhed, og tredjepartsadressen ikke blev brugt til at bruge din identitet.

gmail (Google) måske afviser automatisk alle beskeder kommer fra domæner, der ikke har sådan en DKIM digital semantik.

Hvad er SPF, og hvorfor er det vigtigt for sikker afsendelse af e-mail?

Ligesom DKIM, og SPF har til formål at forebygge phishing-beskeder si e-mail-spoofing. På denne måde vil de sendte beskeder ikke længere blive markeret som spam.

Sender Policy Framework (SPF) er en standardmetode til godkendelse af det domæne, hvorfra meddelelser sendes. SPF-indgange er indstillet til TXT DNS manager af dit domæne, og denne post vil specificere domænenavnet, IP-adressen eller domænerne, der har ret til at sende e-mail-beskeder ved hjælp af dit eller din organisations domænenavn.

Et domæne uden SPF kan tillade spammere at sende e-mails fra andre servere, bruge dit domænenavn som en maske. På den måde kan de sprede sig falske oplysninger eller følsomme data kan blive anmodet om på vegne af din organisation

Selvfølgelig kan beskeder stadig sendes på dine vegne fra andre servere, men de vil blive markeret som spam eller afvist, hvis den pågældende server eller domænenavn ikke er angivet i dit domænes SPF TXT-indgang.

En SPF-værdi i DNS-manager ser sådan ud:

@ : "v=spf1 a mx ip4:x.x.x.x ?all"

Hvor "ip4" er IPv4 på din e-mail-server.

Hvordan indstiller jeg SPF til flere domæner?

Hvis vi ønsker at give andre domæner tilladelse til at sende e-mail-beskeder på vegne af vores domæne, vil vi angive dem med værdien "include"I SPF TXT:

v=spf1 ip4:x.x.x.x include:example1.com include:example2.com ~all

Det betyder, at e-mail-beskeder også kan sendes fra vores domænenavn til eksempel1.com og eksempel2.com.
Det er en meget nyttig rekord, hvis vi f.eks. har en Shop Online På adressen"eksempel1.com", Men vi vil gerne have beskederne fra netbutikken til kunderne firmaets domæneadresse, dette væsen"example.com”. I SPF TXT for "example.com", efter behov for at angive ud for IP og "include: example1.com". Så beskeder kan sendes på vegne af organisationen.

Hvordan indstiller jeg SPF til IPv4 og IPv6?

Vi har en mailserver med begge dele IPv4 og med IPv6, er det meget vigtigt, at begge IP'er er angivet i SPF TXT.

v=spf1 ip4:196.255.100.26 ip6:2001:db8:8:4::2 ~all

Dernæst efter "ip" direktivet "include"At tilføje domæner, der er godkendt til forsendelse.

Hvad betyder det "~all","-all"Og"+allaf SPF?

Som nævnt ovenfor kan udbydere (ISP'er) stadig modtage e-mails på vegne af din organisation, selvom de sendes fra et domæne eller IP, der ikke er specificeret i SPF-politikken. Tagget "alle" fortæller destinationsservere, hvordan de skal håndtere disse beskeder fra andre uautoriserede domæner og sende beskeder på vegne af dig eller din organisation.

~all : Hvis beskeden modtages fra et domæne, der ikke er opført i SPT TXT, vil beskederne blive accepteret på destinationsserveren, men de vil blive markeret som spam eller mistænkelige. De vil være underlagt anti-spamfiltrene for god praksis fra modtagerudbyderen.

-all : Dette er det strengeste tag tilføjet til en SPF-indgang. Hvis domænet ikke er på listen, vil beskeden blive markeret som uautoriseret og vil blive afvist af udbyderen. Den bliver heller ikke leveret maci spam.

+all : Meget sjældent brugt og anbefales overhovedet ikke, dette tag tillader andre at sende e-mails på vegne af dig eller din organisation. De fleste udbydere afviser automatisk alle e-mails, der kommer fra domæner med SPF TXT."+all“. Netop fordi afsenderens ægthed ikke kan verificeres, undtagen efter et "e-mail-header"-tjek.

Resumé: Hvad betyder Sender Policy Framework (SPF)?

• Deaktiver & ryd DNS-cache - Windows 7, Vista og XP
• Brug alternative DNS-servere for hurtigere indlæsning af websider
• Sådan ændres DNS-adresse i OS X
• Sådan nulstilles DNS-cache i OS X
• Øg hastigheden Internet-browsing med Google Public DNS

Autoriserer via TXT / SPF DNS-zonen, IP'er og domænenavne, der kan sende e-mails fra dit domæne eller din virksomhed. Det gælder også de konsekvenser, der gælder for beskeder, der sendes fra uautoriserede domæner.

Hvad betyder DMARC, og hvorfor er det vigtigt for din e-mailserver?

DMARC (Domænebaseret meddelelsesgodkendelsesrapportering og overensstemmelse) er tæt forbundet med politiske standarder SPF si dkim udvidelse.
DMARC er en valideringssystem designet til at beskytte dit eller din virksomheds e-mail-domænenavn, praksis som e-mail-spoofing og phishing svindel.

Ved at bruge Sender Policy Framework (SPF) og Domain Keys Identified Mail (DKIM) kontrolstandarder tilføjer DMARC en meget vigtig funktion. rapporter.

Når en domæneejer udgiver DMARC i DNS TXT-området, vil han eller hun indhente information om, hvem der sender e-mails på vegne af ham eller hende eller den virksomhed, der ejer domænet beskyttet af SPF og DKIM. Samtidig vil modtagerne af beskederne vide, om og hvordan disse god praksis-politikker overvåges af ejeren af ​​det afsendende domæne.

En DMARC-post i DNS TXT kan være:

V=DMARC1; rua=mailto:report-id@rep.example.com; ruf=mailto:account-email@for.example.com; p=none; sp=none; fo=0;

I DMARC kan du sætte flere betingelser for indberetning af hændelser og e-mailadresser til analyser og rapporter. Det er tilrådeligt at bruge dedikerede e-mail-adresser til DMARC, da mængden af ​​modtagne beskeder kan være betydelig.

DMARC-tags kan indstilles i henhold til den politik, som du eller din organisation har pålagt:

v - version af den eksisterende DMARC-protokol.
p - anvende denne politik, når DMARC ikke kan verificeres for e-mail-beskeder. Det kan have værdien: "none","quarantine"Eller"reject“. Anvendes "none” for at få rapporter om meddelelsesflow og pin-statussora.
rua - Det er en liste over URL'er, som internetudbydere kan sende feedback på i XML-format. Hvis vi tilføjer e-mailadressen her, vil linket være:rua=mailto:feedback@example.com".
ruf - Listen over webadresser, som internetudbydere kan sende rapporter om cyberhændelser og forbrydelser begået på vegne af din organisation. Adressen vil være:ruf=mailto:account-email@for.example.com".
rf - Indberetningsformat for cyberkriminalitet. Den kan formes"afrf"Eller"iodef".
pct - Instruerer internetudbyderen om kun at anvende DMARC-politikken for en vis procentdel af mislykkede meddelelser. For eksempel kan vi have:pct=50%"Eller politikker"quarantine"Og"reject“. Det vil aldrig blive accepteret."none".
adkim – Angiv "Justering Mode” for DKIM digitale signaturer. Det betyder, at matchningen af ​​en DKIM-posts digitale signatur med domænet kontrolleres. adkim kan have værdierne: r (Relaxed) eller s (Strict).
aspf - På samme måde som i sagen adkim "Justering" er angivet Mode” for SPF og understøtter de samme værdier. r (Relaxed) eller s (Strict).
sp - Denne politik gælder for at tillade underdomæner afledt af organisationens domæne at bruge domænets DMARC-værdi. Dette undgår brugen af ​​separate politikker for hvert område. Det er praktisk talt et "wildcard" for alle underdomæner.
ri - Denne værdi angiver det interval, hvormed XML-rapporter modtages for DMARC. Det meste af tiden er rapportering at foretrække på daglig basis.
fo - Muligheder for svindelrapporter. “Forensic options“. De kan have værdierne "0" for at rapportere hændelser, når både SPF- og DKIM-verifikationen mislykkes, eller værdien "1" for scenariet, hvor SPF'en eller DKIM'en ikke eksisterer eller ikke består verifikationen.

For at sikre, at din eller din virksomheds e-mails når din indbakke, skal du derfor overveje disse tre standarder."bedste praksis for at sende e-mails". dkim udvidelse, SPF si DMARC. Alle disse tre standarder tilhører DNS TXT og kan administreres fra domænets DNS-manager.