Hvordan vi konfigurerer DNS TXT -området for SPF, DKIM og DMARC, og hvordan vi unngår forretningsmessige e -postmeldinger blir avvist av Gmail – Postlevering mislyktes

Administratorene av Alvorlig privat e -post for virksomheten Det står ofte overfor mange problemer og utfordringer. Fra bølgene av Spam som skal blokkeres av spesifikke filtre, Korrespondensens sikkerhet I den lokale e -postserveren og eksterne servere, Konfigurere og Overvåking av SMTP -tjenester, Pop, IMAP, pluss mange og mange andre detaljer om Konfigurasjon SPF, DKIM og DMARC For å overholde den gode praksis med sikker e -postfrakt.

Mange problemer av Forsendelses-e-postmeldinger eller mottaker til / fra ATI -leverandører, oppstår på grunn av feil konfigurasjon av området Dns, hva med e-posttjenesten.

Slik at det fra et domenenavn e -postene kan sendes, må det være Hostat på en e -postserver konfigurert riktig, igjen Domenenavn for å ha DNS -områder for Spf, MX, Dmarc OG Dkim Sett riktig i manageren DNS TXT av domenet.

I dagens artikkel vil vi stoppe ved et ganske vanlig problem på Private e-postservere for virksomhet. Umulighet å sende e-postmeldinger til Gmail-kontoer, Yahoo! eller iCloud.

Meldingene som sendes til @gmail.com blir automatisk avvist. “Postlevering mislyktes: returnerende melding til avsender”

Jeg har nylig møtt et problem på Et e-postområde i et selskap, fra hvilke e-postmeldinger til andre selskaper og enkeltpersoner blir sendt regelmessig, noen av dem har adresser @gmail.com. Alle meldinger som sendes til Gmail -kontoer, returnerte umiddelbart til avsenderen. “Postlevering mislyktes: returnerende melding til avsender”.

Feilmelding returnerte til e -postserveren på Exim Ser ut som følger:

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 scenariet er det ikke noe veldig alvorlig, for eksempel Inkludert domenenavnet til frakt eller IP -avsender i en spam -liste global eller o Hovedkonfigurasjonsfeil av e-posttjenester på Sevrer (Exim).
Selv om mange når jeg ser denne meldingen gå med tanken umiddelbart til spam eller en SMTP -konfigurasjonsfeil, genereres problemet av området DNS TXT av domenet. Det meste av tiden eksisterer ikke DKIM konfigurert i DNS -området eller er ikke riktig passert i DNS -manageren. Ofte har dette problemet for de som bruker Cloudflare som DNS Manager og glem å passere DNS TXT: mail._domainkey (Dkim), Dmarc og Spf.

Som han forteller oss i avvisningsmeldingen fra Gmail, mislyktes ektheten og autentiseringen av avsenderen. “Denne meldingen har ikke autentiseringsinformasjon eller unnlater å N550-5.7.26 Pass-godkjenningskontroller.”. Dette betyr at domenet ikke har DNS TXT konfigurert for å sikre troverdighet for mottakerens e-postserver. Gmail, i vårt scenario.

Når du legger til et webdomene med aktiv e-posttjeneste på cPanel eller VESTACP, opprettes også filene i DNS-området til det respektive domenet automatisk. DNS-område som inneholder inkludert e-posttjenestekonfigurasjon: MX, Spf, Dkim, Dmarc.
I den situasjonen der vi velger domenet som skal være på sjefen DNS Cloudflare, DNS-området for vertskontoen for det respektive domenet, må kopieres i skyen, slik at e-postområdet fungerer riktig. Det var problemet i ovennevnte scenario. I en DNS Tert -manager er det ingen DKIM -registrering, selv om hun eksisterer på DNS ​​-sjefen for den lokale serveren.

Hva er DKIM og hvorfor er e-postavvisningen hvis vi ikke har denne funksjonen på en e-post?

Domainkeys Identified Mail (DKIM) Det er en standardløsning for autentisering av et e-postdomene, som legger til en Digital signatur til hver melding sendt. Destinasjonsservere kan sjekke gjennom DKIM hvis meldingen kommer fra avsenderens lov og ikke fra et annet område som bruker avsenderens identitet som en maske. Om betydningen av alle, hvis du har domenet abcdqwerty.com Uten DKIM kan e-postmeldinger fra andre servere sendes ved hjelp av domenenavnet ditt. Det er hvis du vil ha identitetstyveri, som teknisk kalles E -post forfalskning.
En vanlig teknikk når e-postmeldinger fra e-post sendes phishing og spam.

Også gjennom DKIM kan sikres det, Meldingsinnhold ble ikke endret etter at avsenderen ble sendt.

Etter å ha DKIM satt riktig på verten Severis av e-postsystemet og i DNS-området, vil muligheten for meldingene dine nå mottakeren eller ikke ankomme i det hele tatt.

Et eksempel på DKIM er:

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

Selvfølgelig DKIM -verdien oppnådd av Cripatre RSA -algoritme Det er unikt for hvert domenenavn og kan regenereres fra vertsserveren til e-posttjenesten.

Etter å ha DKIM installert og satt riktig inn DNS TXT Manager, det er veldig mulig å løse problemet med meldingene som er returnert til Gmail -kontoene. I det minste for feilen “Postlevering mislyktes”:

“SMTP-feil fra Remote Mail Server etter pipelined End of Data: 550-5.7.26 Denne meldingen har ikke autentiseringsinformasjon eller unnlater å N550-5.7.26 Pass-godkjenningskontroller. For å beskytte brukerne våre mot spam, er N550-5.7.26-meldingen blitt blokkert.”

Som en kort rekapitulering, DKIM legger til en digital signatur til hver melding sendt, som lar destinasjonsserverne bekrefte ektheten til avsenderen. Hvis meldingen kom fra selskapet ditt og adressen av en tredjepart ikke har blitt brukt, for å bruke identiteten din.

Gmail (Google) kan avviser automatisk alle meldinger som kommer fra felt som ikke har en slik DKIM digital semant.

Hva er SPF og hvorfor er det viktig for sikker forsendelse av e -postmeldinger?

Akkurat som DKIM, og Spf har formålet med å forhindre Mesajele Phishing og E -post forfalskning. På denne måten vil de utsendte meldingene ikke lenger markeres som spam.

Sender Policy Framework (SPF)Det er en standardmetode for autentisering av domenet som meldingene sendes fra. SPF -innganger er satt inn Managerul DNS TXT av domenet ditt og i denne inngangen vil bli spesifisert domenenavnet, IP eller områdene som har rett til å sende meldinger i e-post ved hjelp av domenenavnet eller organisasjonen.

Et domene uten SPF kan tillate spammere å sende e-postmeldinger fra andre servere, Bruker som masken din domenenavn. På denne måten kan de spre seg Falsk informasjon eller Sensitive data kan bli bedt om På vegne av organisasjonen din

Selvfølgelig kan meldinger sendes på dine vegne på andre servere, men de vil bli merket som spam eller avvist, hvis den serveren eller domenenavnet ikke er spesifisert i SPF txt -inngangen til domenet ditt.

En SPF -verdi i DNS Manager ser ut som form:

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

Hvor “IP4” representerer IPv4 på e -postserveren din.

Hvordan setter vi SPF for flere områder?

Hvis vi ønsker å autorisere andre felt til å sende e -postmeldinger på vegne av vårt område, vil vi spesifisere dem med verdien “include” I SPF TXT:

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

Dette betyr at fra vårt navn kan e-postdomenet sendes e-postmeldinger fra eksempel1.com og eksempel2.com.
Det er en veldig nyttig post hvis vi har et eksempel a Magasin online på adressen “Eksempel1.com“, men vi vil at meldingene fra nettbutikken til kundene skal forlate fra Selskapsdomeneadresse, dette vesenet “Eksempel.com“. I SPF txt for “Eksempel.com”, at vi må spesifisere med IP og “Inkluder: Eksempel1.com”. Slik at meldinger kan sendes fra organisasjonens navn.

Hvordan setter vi SPF for IPv4 og IPv6?

Vi har en e -postserver begge med IPv4 så vel som med IPv6, er det veldig viktig at begge IP -ene er spesifisert i SPF TXT.

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

Neste, etter “IP” Direktiv kan brukes “include” For å legge til autoriserte felt for forsendelse.

Hva betyr dette “~all“, “-all” og “+all” Ale SPF?

Som jeg sa ovenfor, kan leverandør (ISP) fremdeles motta e-postmeldinger på vegne av organisasjonen din. Selv om de blir sendt fra et domene eller IP som ikke er spesifisert i SPF -policyen. Merkelapp “alle” Fortell destinasjonsserverne hvordan du behandler disse meldingene fra andre områder som ikke er autorisert og sender meldinger på vegne av deg eller organisasjonen.

~all : Hvis meldingen mottas fra et domene som ikke er oppført i SPF TXT, vil meldingene bli akseptert på destinasjonsserveren, men de vil bli merket som spam eller så mistenkelige. Anti-spam-filtrene med god praksis for mottakeren vil bli underlagt anti-spam-filtrene.

-all : Er den strengeste taggen lagt til en SPF -inngang. Hvis domenet ikke er oppført, vil meldingen bli merket som uautorisert og vil bli avvist av leverandøren. Det vil ikke bli levert selv i spam.

+all : Veldig sjelden brukt og ikke anbefalt, lar denne taggen andre sende e-postmeldinger på vegne av din eller organisasjon. De fleste leverandører avviser automatisk alle e-postmeldinger som kommer fra områder med SPF TXT “+all“. Nettopp fordi avsenderens autentiets ikke kan verifiseres, bortsett fra etter en sjekk av “E -postoverskrift”.

Sammendrag: Hva betyr avsenderpolitiske rammer (SPF)?

• Deaktiver & Klar DNS -cache – Windows 7, Vista & Xp
• Bruk DNS alternative servere for raskere lasting av websider
• Hvordan kan vi endre DNS -adresse i OS X
• Hvordan kan vi tilbakestille DNS -cache i OS X
• Øker nettleshastigheten med Google Public DNS

Autoriserer gjennom DNS TXT / SPF -området, IPS og domenenavn som kan sende e -postmeldinger fra ditt felt eller selskap. Samtidig bruker det konsekvensene som blir brukt på meldingene som sendes fra uautoriserte felt.

Hva betyr DMARC, og hvorfor er det viktig for e-postserver?

Dmarc (Domenebasert melding om melding om godkjenning og konformitet) er nært knyttet til policystandarder Spf og Dkim.
DMARC ESTE A. Valideringssystem unnfanget for å beskytte E-postdomenenavnet ditt på ditt eller selskap, av praksis som forfalskning av e -post og phishing svindel.

Bruke SPF (Sender Policy Framework) og DKIM (Domain Keys Identified Mail) -standarder legger til en veldig viktig funksjon. rapporter.

Når en domeneeier publiserer DMARC i DNS TXT-området, vil han få informasjon om hvem som sender e-postmeldinger på vegne av eller av selskapet som eier domenet beskyttet med SPF og DKIM. Samtidig vil mottakerne av meldingene vite om og hvordan disse gode praksisene overvåkes av eieren av avsenderen.

En DMARC -integrasjon i DNS TXT kan være av skjemaet:

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

I DMARC kan du legge flere betingelser for rapportering av hendelser så vel som e-postadressene du kan nå analysene og rapportene. Det anbefales å bruke dedikerte e-postadresser for DMARC fordi volumet av mottatte meldinger kan være betydelig.

DMARC -tagger kan settes i henhold til politikken som er pålagt av deg eller organisasjonen:

v – versjonen av den eksisterende DMARC -protokollen.
p – Bruk denne policyen når du ikke kan sjekke DMARC for e -postmeldinger. Kan ha verdien: “none“, “quarantine” eller “reject“. Det brukes “none” For å få rapporter om strømmen av meldinger og kilden.
rua – Det er en liste over nettadresser som ISP -er kan sende tilbakemeldinger i XML -format. Hvis vi legger til e -postadressen her, vil lenken være av skjemaet: “rua=mailto:[email protected]” .
ruf – Listen over nettadresser som ISP -er kan sende rapporter om hendelser og cyberlovbrudd laget på vegne av din organisasjon. Adressen vil være av skjemaet: “ruf=mailto:[email protected]“.
rf – Formatet for rapportering av cyberlovbrudd. Kan være av form “afrf” eller “iodef“.
pct – Angir internett / ISP -leverandøren for å bruke DMARC -policyen bare for en viss prosentandel av mislykkede meldinger. For eksempel kan vi ha: “pct=50%” eller retningslinjer “quarantine” og “reject“. Vil aldri bli akseptert “none“.
adkim – Spesiell “Justeringsmodus” for DKIM digitale signaturer. Dette betyr at den digitale signaturen til en DKIM -inngang med domenet er sjekket. adkim kan ha verdiene: r (Relaxed) eller s (Strict).
aspf – På samme måte som i tilfelle av adkim er spesifisert “Justeringsmodus” For SPF og støtte de samme verdiene. r (Relaxed) eller s (Strict).
sp – Denne policyen gjelder for å la underdomener avledet fra organisasjonsfeltet bruke verdien av domenet. Dette unngår bruk av separate retningslinjer for hvert område. Det er praktisk talt en “jokertegn” for alle underdomener.
ri – Denne verdien angir intervallet som XML -rapporter vil bli mottatt for DMARC. Det meste av tiden er rapportering å foretrekke å gjøre daglig.
fo – Alternativer for svindelrapporter. “Rettsmedisinske alternativer“. De kan ha verdiene “0” Å rapportere hendelser når du svikter både SPF og DKIM, eller verdi “1” For scenariet der SPF eller DKIM ikke eksisterer eller ikke sjekker.

Så for å være sikker på at dine e -postmeldinger kommer til mottakere av innbokser, må du ta hensyn til disse tre standardene i “God praksis for sendingsmeldinger for forsendelse“. Dkim, Spf og Dmarc. Alle disse tre standardene er relatert til DNS TXT og kan administreres av DNS -sjefen for feltet.