Hvordan vi konfigurerer DNS TXT -området til SPF, DKIM og DMARC, og hvordan vi undgår forretnings -e -mail -meddelelser afvises af Gmail – Maillevering mislykkedes

Administratorer af alvorlig privat e-mail til erhvervslivet møder ofte mange problemer og udfordringer. Fra bølgerne af Spam som skal blokeres af specifikke filtre, korrespondancesikkerhed i den lokale e-mail-server og fjernservere, Konfigurerer og overvågning af SMTP-tjenester, POP, IMAP, plus mange og mange andre detaljer om SPF, DKIM og DMARC konfiguration at overholde god praksis for afsendelse af sikre e-mails.

Mange problemer vedr afsendelse af 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 mailserver korrekt konfigureret, og domænenavnet skal have DNS-zoner for SPF, MX, DMARC OG DKIM korrekt indstillet i manageren DNS TXT af domænet.

I dagens artikel vil vi fokusere på et ret almindeligt problem private e-mail-servere til erhvervslivet. Manglende evne til at sende e-mail-beskeder til Gmail-konti, Yahoo! eller iCloud.

Beskeder sendt til @Gmail.com afvises automatisk. “Postlevering mislykkedes: Sender besked til afsender”

Jeg stødte for nylig på et problem på et firma-e-mail-domæne, hvorfra der regelmæssigt sendes e-mails til andre virksomheder og til enkeltpersoner, hvoraf nogle har adresser @gmail.com. Alle meddelelser sendt til Gmail-konti blev straks returneret til afsenderen. “Postlevering mislykkedes: Sender besked til afsender”.

Fejlmeddelelsen returneres i e-mail-serveren den EXIM ser sådan ud:

1nSeUV-0005zz-De ** [email protected] 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 inklusive afsenderens domænenavn eller afsender-IP i en SPAM-liste global eller o større konfigurationsfejl af e-mail-tjenester på server (EXIM).
Selvom mange, når de ser denne besked, straks tænker på SPAM eller en SMTP-konfigurationsfejl, er problemet genereret af området DNS TXT af feltet. Det meste af tiden er DKIM ikke konfigureret i DNS-zonen eller er ikke indtastet korrekt i domænets DNS-manager. Dette problem støder ofte på dem, der bruger det CloudFlare som DNS Manager og glem at bestå DNS TXT: mail._domainkey (DKIM), DMARC og SPF.

Som det fortæller os i afvisningsmeddelelsen fra Gmail, er ægtheden og autentificeringen af ​​afsenderdomænet mislykket. “This message does not have authentication information or fails to\n550-5.7.26 pass authentication checks.”. Det betyder, at domænet ikke har DNS TXT konfigureret til at sikre troværdighed for modtagerens e-mail-server. Gmail, i vores scenarie.

Når vi tilføjer et web-domæne med en aktiv e-mail-tjeneste på cPanel eller VestaCP, oprettes filerne fra DNS-zonen på det respektive domæne automatisk. DNS-zonen, der også indeholder konfigurationen af ​​e-mail-tjenesten: MX, SPF, DKIM, DMARC.
I den situation, hvor vi vælger domænet til at være på manageren DNS CloudFlare, DNS-zonen fra domænets hostingkonto, skal kopieres til CloudFlare, for at e-mail-domænet fungerer korrekt. Det var problemet i ovenstående scenarie. I en tredjeparts DNS-manager er der ingen DKIM-post, 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 standardløsning til autentificering af et e-mail-domæne, som tilføjer en Digital signatur til hver sendt besked. Destinationsservere kan tjekke gennem DKIM, om beskeden kommer fra afsenderens juridiske domæne og ikke fra et andet domæne, der bruger afsenderens identitet som en maske. For all del, hvis du har domænet abcdqwerty.com uden DKIM kan e-mail-beskeder 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 e-mails sendes af phishing og Spam.

Også gennem DKIM kan det sikres, at indholdet af meddelelsen blev ikke ændret, efter at den blev sendt af afsenderen.

Hvis DKIM er indstillet korrekt på e-mail-systemets værtsserver og i DNS-zonen, elimineres muligheden for, at dine beskeder når modtageren i SPAM eller slet ikke når dem.

Et eksempel på DKIM er:

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

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

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

“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.”

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 adressen ikke blev brugt af en tredjepart til at bruge din identitet.

Gmail (Google) kan automatisk afvise alle beskeder der kommer fra domæner, der ikke har sådan en DKIM digital signatur.

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

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

Afsender Policy Framework (SPF)Det er en standardmetode til godkendelse af det domæne, hvorfra meddelelserne sendes. SPF -indgange er indstillet Managerul DNS TXT Af dit domæne og i denne indgang specificeres domænenavnet, IP eller områder, der har ret til at sende beskeder i e-mail ved hjælp af dit domænenavn eller organisation.

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 anmodes 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” repræsenterer din mailservers IPv4.

Hvordan indstiller jeg SPF til flere domæner?

Hvis vi ønsker at autorisere andre domæner 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 kan sendes fra vores e-mail-domænenavn og fra eksempel1.com og eksempel2.com.
Det er en meget brugbar rekord, hvis vi f.eks. har en Magasin online på adressen “eksempel1.com“, men vi ønsker, at budskaberne fra netbutikken til kunderne skal gå fra virksomhedens domæneadresse, dette væsen “eksempel.com“. I SPF TXT for “eksempel.com”, som vi skal angive sammen med IP og “include:example1.com”. Så beskeder kan sendes på vegne af organisationen.

Hvordan indstilles SPF til IPv4 og IPv6?

Vi har en mailserver med begge dele IPv4 såvel som 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

Næste, efter “ip” direktiv kan bruges “include” for at tilføje domæner, der er godkendt til forsendelse.

Hvad betyder dette “~all“, “-all” og “+all” ale SPF?

Som jeg sagde ovenfor, kan internetudbydere 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. Mærke “alle” fortæller destinationsservere, hvordan de skal behandle disse meddelelser fra andre domæner, der ikke er godkendte, og som sender meddelelser på vegne af dig eller din organisation.

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

-all : Det er det strengeste mærke, der tilføjes til en SPF-indgang. Hvis domænet ikke er på listen, vil beskeden blive markeret som uautoriseret og vil blive afvist af udbyderen. Det vil ikke engang blive leveret til spam.

+all : Meget sjældent brugt og slet ikke anbefalet, 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, først efter en verifikation af “e-mail-header”.

Oversigt: Hvad er Sender Policy Framework (SPF)?

• Deaktiver & Ryd DNS-cache – Windows 7, Vista & XP
• Brug DNS -alternative servere til hurtigere belastning af websider
• Hvordan kan vi ændre DNS -adresse i OS X
• Hvordan kan vi nulstille DNS-cachen i OS X
• Øg hastigheden på internetbrowsing ved hjælp af Google Public DNS

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

Hvad er DMARC, og hvorfor er det vigtigt for e-mail-serveren?

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

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

Når en domæneejer udgiver DMARC i DNS TXT-zonen, vil han få information om, hvem der sender e-mails på hans vegne eller på vegne af den virksomhed, der ejer domænet beskyttet med SPF og DKIM. Samtidig vil de modtagende udbydere af beskederne vide, om og hvordan disse best practice-politikker overvåges af ejeren af ​​det afsendende domæne.

En DMARC-post i DNS TXT kan have formen:

V=DMARC1; rua=mailto:[email protected]; ruf=mailto:[email protected]; p=none; sp=none; fo=0;

I DMARC kan der opstilles flere hændelsesrapporteringsbetingelser, samt de e-mailadresser, som analyser og rapporter kan sendes til. 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 organisationen har pålagt:

v – eksisterende DMARC-protokolversion.
p – anvende denne politik, når DMARC-bekræftelse for e-mail-meddelelser ikke kan udføres. Det kan have værdien: “none“, “quarantine” eller “reject“. Det er brugt “none” for at få rapporter om strømmen af ​​beskeder og deres status.
rua – Det er en liste over URL'er, som internetudbydere kan sende feedback til i XML-format. Hvis vi tilføjer e-mailadressen her, vil linket være af formen: “rua=mailto:[email protected]” .
ruf – Liste over webadresser, hvortil internetudbydere kan sende rapporter om cyberhændelser og forbrydelser begået på vegne af din organisation. Adressen vil være af formen: “ruf=mailto:[email protected]“.
rf – Indberetningsformat for cyberkriminalitet. Den kan formes “afrf” eller “iodef“.
pct – Beder internetudbyderen/ISP'en om kun at anvende DMARC-politikken på 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 “Justeringstilstand” til 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 er angivet “Justeringstilstand” 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 enkelt domæne. Det er dybest set en “jokertegn” for alle underfelter.
ri – Denne værdi angiver det interval, hvormed XML-rapporter for DMARC modtages. Det meste af tiden er det at foretrække, at rapportering foretages dagligt.
fo – Muligheder for rapportering af svindel. “Retsmedicinske muligheder“. De kan have værdierne “0” at rapportere hændelser, når både SPF- og DKIM-verifikation mislykkes, eller værdien “1” for det scenarie, hvor SPF eller DKIM ikke eksisterer eller ikke består kontrollen.

Så for at være sikker på, at din eller din virksomheds e-mails når frem til modtagerne i indbakken, er det nødvendigt at tage højde for disse tre standarder for “bedste praksis for afsendelse af e-mails“. DKIM, SPF og DMARC. Alle disse tre standarder tilhører DNS TXT og kan administreres fra domænets DNS-manager.