Slik setter du opp DNS TXT-sonen for SPF, DKIM og DMARC og hvordan du forhindrer at bedrifts-e-postmeldinger avvises av Gmail - Postlevering mislyktes

Administratorii av alvorlig privat e-post for bedrifter det møter ofte mange problemer og utfordringer. Fra bølgene av SPAM som må blokkeres av spesifikke filtre, korrespondansesikkerhet i den lokale e-postserveren og eksterne servere, konfigurasjon si overvåking av SMTP-tjenester, POP, IMAP, pluss massevis av andre detaljer SPF, DKIM og DMARC konfigurasjon å følge beste praksis for sikker e-post.

Mange problemer sende e-postmeldinger eller mottaker til/fra leverandørene dine, vises på grunn av feil konfigurasjon av området DNS, hva med e-posttjenesten.

For at e-poster skal sendes fra et domenenavn, må det være det vert på en e-postserver Riktig konfigurert, og domenenavn for å ha DNS-soner for SPF, MX, DMARC SI DKIM satt riktig i lederen TXT DNS av domenet.

I dagens artikkel vil vi fokusere på et ganske vanlig problem private bedrifts-e-postservere. Kan ikke sende e-post til Gmail, Yahoo! eller iCloud.

Meldinger sendt til @ Gmail.com blir automatisk avvist. "Postlevering mislyktes: returnerer melding til avsender"

Jeg har nylig støtt på et problem på et e-postdomene til et selskap, hvorfra det regelmessig sendes e-post til andre selskaper og til enkeltpersoner, hvorav noen har adresser @ gmail.com. Alle meldinger sendt til Gmail-kontoer ble umiddelbart returnert til avsenderen. "Postlevering mislyktes: returnerer melding til avsender".

Feilmelding returnert til e-postserveren på EXIM ser slik ut:

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 scenariet er det ikke noe veldig alvorlig, som f.eks inkludere avsendende domenenavn eller sende-IP i en SPAM-liste global eller o stor konfigurasjonsfeil av e-posttjenester på server (EXIM).
Selv om mange ser denne meldingen umiddelbart når de tenker på SPAM eller en SMTP-konfigurasjonsfeil, er problemet generert av området. TXT DNS av domenet. Mesteparten av tiden er ikke DKIM konfigurert i DNS-sonen eller sendes ikke riktig i DNS-administratoren for domenet. Dette problemet finnes ofte hos de som bruker det CloudFlare som DNS Manager og glem å bestå TXT DNS: mail._domainkey (DKIM), DMARC si SPF.

Som Gmails avvisningsmelding forteller oss, har autentisiteten og autentiseringen av avsenderdomenet mislyktes. "Denne meldingen har ikke autentiseringsinformasjon eller klarer ikke \ n550-5.7.26 å bestå autentiseringskontroller." Dette betyr at domenet ikke har DNS TXT konfigurert for å sikre troverdighet for mottakerens e-postserver. Gmail, i skriptet vårt.

Når vi legger til et webdomene med en aktiv e-posttjeneste på cPanel VestaCP, opprettes også filene i DNS-sonen til det respektive domenet automatisk. DNS-sone som inneholder konfigurasjonen av e-posttjenesten: MX, SPF, DKIM, DMARC.
I situasjonen hvor vi velger domenet som skal være forvalter CloudFlare DNS, må DNS-området til domenets vertskonto kopieres til CloudFlare for at e-postdomenet skal fungere skikkelig. Det var problemet i scenariet ovenfor. I en tredjeparts DNS-administrator eksisterer ikke DKIM-registrering, selv om den finnes på DNS-administratoren til den lokale serveren.

Hva er DKIM og hvorfor blir e-poster avvist hvis vi ikke har denne funksjonen på et e-postdomene?

DomainKeys Identified Mail (DKIM) er en standard autentiseringsløsning for e-postdomene som legger til en digitale signaturer hver melding som sendes. Destinasjonsserverne kan sjekke gjennom DKIM om meldingen kommer fra avsenderens rettsdomene og ikke fra et annet domene som bruker avsenderens identitet som en maske. Etter alt å dømme, hvis du har domenet abcdqwerty. Med uten DKIM kan e-poster sendes fra andre servere som bruker domenenavnet ditt. Det er hvis du ønsker et identitetstyveri, som på fagspråk heter e-post-forfalskning.
En vanlig teknikk når du sender e-postmeldinger phishing si spam.

Det kan også sikres gjennom DKIM at, innholdet i meldingen ble ikke endret etter at den ble sendt av avsenderen.

Å ha DKIM riktig innstilt på den strenge verten til e-postsystemet og i DNS-området eliminerer også muligheten for at meldingene dine kan nå SPAM til mottakeren eller ikke nå i det hele tatt.

Et eksempel på en DKIM er:

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

Selvfølgelig er DKIM-verdien oppnådd av RSA-krypteringsalgoritme er unikt for hvert domenenavn og kan regenereres fra vertens e-postserver.

Å ha DKIM installert og riktig innstilt TXT DNS manager, er det svært mulig å løse problemet med meldinger som returneres til Gmail-kontoer. I det minste for «E-postlevering mislyktes»-feil:

"SMTP error fra ekstern e-postserver etter pipelinet slutten av data: 550-5.7.26 Denne meldingen har ikke autentiseringsinformasjon eller klarer ikke \ n550-5.7.26 å bestå autentiseringskontroller. For å beskytte brukerne våre best mulig mot spam, har \ n550-5.7.26-meldingen blitt blokkert. ”

Som en kort oppsummering, DKIM legger til en digital signatur for hver melding som sendes, som lar destinasjonsserverne bekrefte ektheten til avsenderen. Hvis meldingen kom fra bedriften din og tredjepartsadressen ikke ble brukt for å bruke identiteten din.

Gmail (Google) kanskje avviser automatisk alle meldinger kommer fra domener som ikke har en slik DKIM digital semantikk.

Hva er SPF og hvorfor er det viktig for sikker e-postsending?

Akkurat som DKIM, og SPF har som mål å forebygge phishing-meldinger si e-post-forfalskning. På denne måten vil de sendte meldingene ikke lenger merkes som spam.

Sender Policy Framework (SPF) er en standardmetode for autentisering av domenet meldingene sendes fra. SPF-oppføringer er satt til TXT DNS-behandler av domenet ditt, og denne oppføringen vil spesifisere domenenavnet, IP-adressen eller domenene som har rett til å sende e-postmeldinger med ditt eller organisasjonens domenenavn.

Et domene uten SPF kan tillate spammere å sende e-post fra andre servere, bruke domenenavnet ditt som en maske. På denne måten kan de spre seg falsk informasjon eller sensitive data kan bli forespurt på vegne av organisasjonen din

Selvfølgelig kan meldinger fortsatt sendes på dine vegne fra andre servere, men de vil bli merket som spam eller avvist hvis den serveren eller domenenavnet ikke er spesifisert i domenets SPF TXT-oppføring.

En SPF-verdi i DNS-manager ser slik ut:

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

Hvor "ip4" er IPv4 på e-postserveren din.

Hvordan angir jeg SPF for flere domener?

Hvis vi ønsker å autorisere andre domener til å sende e-postmeldinger på vegne av domenet vårt, spesifiserer vi dem med verdien "include"I SPF TXT:

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

Dette betyr at e-postmeldinger også kan sendes fra vårt domenenavn til eksempel1.com og eksempel2.com.
Det er en veldig nyttig rekord hvis vi for eksempel har en handle På adressen"eksempel1.com", Men vi ønsker at meldingene fra nettbutikken til kundene skal forlate bedriftens domeneadresse, dette er "example.com“. I SPF TXT for "example.com", etter behov for å spesifisere ved siden av IP og "inkluder: eksempel1.com". Slik at meldinger kan sendes på vegne av organisasjonen.

Hvordan angir jeg SPF for IPv4 og IPv6?

Vi har en e-postserver med begge IPv4 og med IPv6, er det svært viktig at begge IP-ene er spesifisert i SPF TXT.

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

Deretter, etter "ip" direktivet "include"For å legge til domener autorisert for frakt.

Hva betyr det "~all","-all"Og"+allAv SPF?

Som nevnt ovenfor kan leverandører (ISPer) fortsatt motta e-poster på vegne av organisasjonen din selv om de sendes fra et domene eller IP som ikke er spesifisert i SPF-policyen. "Alle"-taggen forteller destinasjonsservere hvordan de skal håndtere disse meldingene fra andre uautoriserte domener og sende meldinger på vegne av deg eller din organisasjon.

~all : Hvis meldingen mottas fra et domene som ikke er oppført i SPT TXT, vil meldingene bli akseptert på destinasjonsserveren, men de vil bli merket som spam eller mistenkelige. De vil være underlagt beste praksis fra mottakerleverandørens anti-spam-filtre.

-all : Dette er den strengeste taggen som er lagt til en SPF-oppføring. Hvis domenet ikke er oppført, vil meldingen bli merket som uautorisert og vil bli avvist av leverandøren. Den blir heller ikke levert maci spam.

+all : Svært sjelden brukt og anbefales ikke i det hele tatt, denne taggen lar andre sende e-post på vegne av deg eller din organisasjon. De fleste leverandører avviser automatisk alle e-postmeldinger som kommer fra domener med SPF TXT."+all". Nettopp fordi autentisiteten til avsenderen ikke kan verifiseres, bortsett fra etter en "e-postheader"-sjekk.

Sammendrag: Hva betyr Sender Policy Framework (SPF)?

• Deaktiver og tøm DNS-hurtigbuffer - Windows 7, Vista og XP
• Bruk alternative DNS-servere for raskere lasting av nettsider
• Hvordan endre DNS adresse i OS X
• Hvordan tilbakestille DNS cache i OS X
• Øk hastigheten Internett-surfing med Google Public DNS

Autoriserer gjennom TXT / SPF DNS-sonen, IP-er og domenenavn som kan sende e-postmeldinger fra ditt domene eller firma. Det gjelder også konsekvensene som gjelder meldinger som sendes fra uautoriserte domener.

Hva betyr DMARC og hvorfor er det viktig for e-postserveren din?

DMARC (Domenebasert meldingsautentiseringsrapportering og samsvar) er nært knyttet til politiske standarder SPF si DKIM.
DMARC er en valideringssystem designet for å beskytte ditt eller bedriftens e-postdomenenavn, praksis som e-postforfalskning og phishing-svindel.

Ved å bruke Sender Policy Framework (SPF) og Domain Keys Identified Mail (DKIM) kontrollstandarder, legger DMARC til en svært viktig funksjon. rapporter.

Når en domeneeier publiserer DMARC i DNS TXT-området, vil han eller hun få informasjon om hvem som sender e-postmeldinger på vegne av ham eller henne eller selskapet som eier domenet beskyttet av SPF og DKIM. Samtidig vil mottakerne av meldingene vite om og hvordan disse retningslinjene for god praksis overvåkes av eieren av avsenderdomenet.

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 sette flere vilkår for rapportering av hendelser og e-postadresser for analyser og rapporter. Det er tilrådelig å bruke dedikerte e-postadresser for DMARC siden volumet av meldinger som mottas kan være betydelig.

DMARC-tagger kan settes i henhold til retningslinjene pålagt av deg eller organisasjonen din:

v - versjon av den eksisterende DMARC-protokollen.
p - bruk denne policyen når DMARC ikke kan verifiseres for e-postmeldinger. Det kan ha verdien: "none","quarantine"Eller"reject". Benyttes "none” for å få rapporter om meldingsflyt og pin-statussora.
rua – Det er en liste over URL-er som Internett-leverandører kan sende tilbakemelding på i XML-format. Hvis vi legger til e-postadressen her, vil lenken være:rua=mailto:feedback@example.com".
ruf – Listen over nettadresser som Internett-leverandører kan sende rapporter om cyberhendelser og forbrytelser begått på vegne av organisasjonen din. Adressen vil være:ruf=mailto:account-email@for.example.com".
rf - Rapporteringsformat for nettkriminalitet. Den kan formes"afrf"Eller"iodef".
pct - Instruerer Internett-leverandøren om å bruke DMARC-policyen bare for en viss prosentandel av mislykkede meldinger. For eksempel kan vi ha:pct=50%"Eller retningslinjer"quarantine"Og"reject". Det vil aldri bli akseptert."none".
adkim – Spesifiser "Alignment Mode” for DKIM digitale signaturer. Dette betyr at matchingen av den digitale signaturen til en DKIM-oppføring med domenet kontrolleres. adkim kan ha verdiene: r (Relaxed) eller s (Strict).
aspf – På samme måte som i saken adkim "Alignment" er spesifisert Mode” for SPF og støtter de samme verdiene. r (Relaxed) eller s (Strict).
sp – Denne policyen gjelder for å tillate at underdomener avledet fra organisasjonsdomenet bruker DMARC-verdien til domenet. Dette unngår bruk av separate retningslinjer for hvert område. Det er praktisk talt et "jokertegn" for alle underdomener.
ri - Denne verdien angir intervallet som XML-rapporter vil bli mottatt for DMARC. I de fleste tilfeller er rapportering å foretrekke på daglig basis.
fo - Alternativer for svindelrapporter. "Rettsmedisinsk options". De kan ha verdiene "0" for å rapportere hendelser når både SPF- og DKIM-verifiseringen mislykkes, eller verdien "1" for scenariet der SPF-en eller DKIM-en ikke eksisterer eller ikke består verifiseringen.

Derfor, for å sikre at din eller bedriftens e-poster når innboksen din, må du vurdere disse tre standardene."beste fremgangsmåter for å sende e-poster". DKIM, SPF si DMARC. Alle tre standardene er relatert til DNS TXT og kan administreres fra domenets DNS-manager.