MX-poster – slik finner e-post riktig mottaker

Når noen sender en melding til kontakt@eksempel.no, må avsenders e-postserver finne systemet som tar imot e-post for eksempel.no. Den spør DNS etter MX-poster, forkortelse for Mail Exchange.

MX-posten peker ikke på en bestemt innboks. Den peker på mottakstjeneren for domenet. Mottakstjeneren avgjør deretter om adressen finnes, om meldingen godtas og hvor den leveres.

Et MX-svar består av prioritet og mål

En vanlig post ser slik ut i soneformat:

eksempel.no.  3600  IN  MX  10  mx1.postleverandor.example.

Feltene betyr:

I et kontrollpanel vises rotdomenet ofte som @, blankt felt eller selve domenet. Følg leverandørens format. Et punktum til slutt betyr et fullstendig domenenavn i en sonefil; noen kontrollpaneler legger det til automatisk.

Lavest tall prøves først

Lavere preferansetall betyr høyere prioritet:

eksempel.no.  MX  10  mx1.postleverandor.example.
eksempel.no.  MX  20  mx2.postleverandor.example.

Avsenderen prøver normalt mx1 før mx2. Hvis det foretrukne målet er midlertidig utilgjengelig, kan avsenderen prøve neste brukbare mål og senere forsøke på nytt etter sin køpolicy.

Har flere MX-poster samme preferanse, har de samme prioritet. SMTP-standarden krever at en avsender uten annen grunn til å foretrekke ett mål varierer valget, slik at trafikken fordeles. DNS-rekkefølgen på skjermen er ikke en prioritet i seg selv.

Bruk nøyaktig de prioritetene og målene e-postleverandøren oppgir. Flere poster er ikke automatisk bedre hvis de peker til systemer som ikke deler mottakere og sikkerhetspolicy.

Slik foregår leveringen

Forenklet skjer dette:

1. Avsenderens Mail Transfer Agent finner domenet etter @ i mottakeradressen.
2. Den gjør et MX-oppslag for domenet.
3. Den sorterer brukbare mål etter preferanse.
4. Den slår opp A- og eventuelle AAAA-adresser for MX-målet.
5. Den prøver SMTP-tilkobling til mottakstjeneren.
6. Mottakstjeneren godtar, avviser eller ber avsenderen prøve senere.
7. Ved godkjenning rutes meldingen videre til postboks, alias, gruppe eller filter.

RFC 5321 beskriver SMTP-rutingen og hvordan flere MX-mål skal behandles. DNS-oppslaget beviser ikke at en bestemt mottakeradresse finnes.

MX-målet må være et vertsnavn med adresse

MX kan ikke peke direkte på en IP-adresse.

Riktig:

eksempel.no.  MX  10  mail.eksempel.no.
mail.eksempel.no.  A  192.0.2.20

Feil:

eksempel.no.  MX  10  192.0.2.20

MX-målet skal heller ikke være et CNAME-alias. RFC 2181 presiserer at målet må være et kanonisk navn med adresseposter, ikke en aliaspost. Et oppsett som ser ut til å virke gjennom CNAME, kan gi ekstra oppslag eller feile hos andre sendere.

Bruk leverandørens publiserte mål direkte. Ikke legg en egen CNAME foran for å få et penere navn.

Hva skjer hvis domenet ikke har MX?

Fravær av MX betyr ikke alltid at en SMTP-avsender gir opp umiddelbart. SMTP har en eldre fallbackregel: hvis ingen MX finnes, kan domenets A- eller AAAA-adresse behandles som et implicit MX-mål med preferanse 0.

Dette er ikke et godt oppsett for bedrifts-e-post. Webserverens adresse kan mangle en SMTP-tjeneste, ha annen sikkerhet eller endres uavhengig av e-post. Publiser eksplisitte MX-poster når domenet skal motta e-post.

Null MX når domenet ikke skal motta e-post

Et domene som bevisst ikke tar imot e-post, kan publisere én null MX:

eksempel.no.  MX  0  .

Punktumet som mål betyr at ingen e-posttjeneste finnes for domenet. RFC 7505 krever at null MX står alene; det skal ikke kombineres med vanlige MX-poster.

Dette gir avsendere et tydelig, permanent svar i stedet for at de prøver webserverens adresse og køer meldingen lenge. Bruk bare null MX når virksomheten virkelig ikke skal motta meldinger på domenet, heller ikke til vanlige roller som postmaster eller kundekontakt.

Flere MX-poster er ikke automatisk backup

To navn hos samme e-postleverandør kan være del av leverandørens redundante mottaksplattform. To mål hos forskjellige leverandører er mer komplisert.

En sekundær MX må:

• kjenne hvilke mottakere domenet godtar, eller validere dem pålitelig
• ha tilsvarende spam- og sikkerhetskontroller
• kunne levere meldingene videre til primærsystemet
• unngå å bli et åpent relé
• ha kø, logging og overvåking som passer kravene

Et svakt sekundærmål kan motta mer søppel fordi avsendere med dårlige hensikter prøver å omgå den primære filtreringen. En feilkonfigurert sekundær kan også godta meldingen og senere mislykkes med videresending.

Ikke konstruer egen «backup-MX» med en gammel leverandør bare fordi kontoen fortsatt virker. Bruk e-postleverandørens dokumenterte MX-sett.

MX styrer mottak, ikke vanlig utsending

MX svarer på hvor innkommende e-post til domenet skal leveres. Det bestemmer ikke alene:

• hvilken SMTP-server ansatte bruker for å sende
• om en avsender har lov til å bruke domenet
• om meldingen er signert
• hva mottakeren skal gjøre ved autentiseringsfeil

Utgående e-post og domeneautentisering krever et riktig oppsett for avsendertjenestene. Les SPF, DKIM og DMARC i sammenheng etter at mottaket virker.

En MX-endring flytter heller ikke gamle postbokser eller historikk. Data må migreres separat med en plan for brukere, aliaser, mapper og tidspunkt.

Slik kontrollerer dere MX-poster

På macOS eller Linux:

dig eksempel.no MX +short

På Windows:

nslookup -type=MX eksempel.no

Bytt eksempel.no med domenet dere har ansvar for. Et forventet svar kan se slik ut:

10 mx1.postleverandor.example.
20 mx2.postleverandor.example.

Kontroller deretter at hvert mål har adresseposter:

dig mx1.postleverandor.example A +short
dig mx1.postleverandor.example AAAA +short

Tomt AAAA-svar er ikke nødvendigvis feil; leverandøren kan bruke bare IPv4. Et MX-mål uten noen brukbar adresse er derimot ikke leverbart.

Sammenlign med instruksen fra leverandøren. Et DNS-verktøy kan vise hva som er publisert, men ikke vite hva avtalen deres skulle inneholde. Se guiden til å sjekke DNS-poster for autoritative oppslag og flere resolvere.

Skill DNS-feil fra SMTP-feil

Et korrekt MX-svar betyr bare at avsenderen finner mottakssystemet. Leveringen kan fortsatt feile fordi:

• mottakeradressen ikke finnes
• postboksen er full
• mottakstjeneren avviser avsender eller innhold
• forbindelsen til port 25 blokkeres eller får tidsavbrudd
• TLS-forhandling feiler
• leverandøren har en hendelse
• meldingen blir godtatt, men filtrert eller satt i karantene

Be om hele SMTP-statuskoden og teksten fra returmeldingen. En 5.x.x-kode er normalt permanent, mens 4.x.x vanligvis ber avsenderen prøve senere. Hvis domenet håndhever transport-TLS, kontroller også MTA-STS-policyen og TLS-RPT-dataene . Ikke del privat meldingsinnhold eller passord i feilsøkingen.

Bruk guiden når bedriften ikke mottar e-post når DNS ser riktig ut.

Vanlige MX-feil

Gamle og nye leverandører ligger samtidig

Hvis begge settene publiseres uten en gjennomtenkt migrering, kan noen sendere levere til gammel tjeneste og andre til ny. Prioritet er failover, ikke en migreringsmotor.

Lavt og høyt tall tolkes motsatt

Lavest tall er mest foretrukket. Ikke bruk markedsord som «primær» uten å kontrollere tallene.

Målet er proxied i en web-CDN

Vanlig webproxying passer normalt ikke for SMTP-målet. Hos plattformer som skiller mellom proxied og DNS-only, må e-postrelaterte vertsnavn følge e-postleverandørens instruks.

MX legges på www

MX kan teknisk publiseres for et subdomene, men e-post til navn@eksempel.no slår opp eksempel.no, ikke www.eksempel.no. Legg posten på riktig navn.

Postboksen er ikke opprettet

DNS kan være perfekt mens mottakeren mangler. Opprett brukere, aliaser og grupper før trafikken flyttes.

MX-målet endres for å «matche» eget domene

Bruk leverandørens mål ordrett. Et penere, selvlaget vertsnavn kan bryte adresseoppslag, sertifikater og supportforutsetninger.

Flytt e-postleverandør uten å miste oversikten

En trygg MX-endring begynner før DNS:

1. Kartlegg alle postbokser, aliaser, grupper, videresendinger og systemavsendere.
2. Opprett og test mottakerne hos ny leverandør.
3. Konfigurer utgående SMTP, SPF, DKIM og DMARC etter migreringsplanen.
4. Senk TTL minst én eksisterende TTL-periode før byttet hvis rask overgang er nødvendig.
5. Migrer historiske data eller start kontrollert synkronisering.
6. Publiser nøyaktig MX-settet den nye leverandøren oppgir.
7. Kontroller autoritative svar og flere resolvere.
8. Test inn og ut med eksterne avsendere uten sensitive data.
9. Følg køer, returmeldinger og begge systemer gjennom overgangsperioden.
10. Fjern gammel tjeneste først når cache, restlevering og datakopi er håndtert.

Hvor lenge gammel tjeneste bør beholdes avhenger av TTL, leverandørens køpolicy og migreringsmetoden. Ikke bruk et fast døgnantall uten å kontrollere det faktiske oppsettet. Følg den komplette planen for å flytte e-post .

Hvis dere bruker e-post gjennom Vymo

Et .no-domene hos Vymo inkluderer ikke automatisk en e-postkonto. E-post er et separat produkt fra 19,- per konto per måned inkludert merverdiavgift. Basis har 15 GB per konto, ubegrensede aliaser, webmail og standard IMAP-/POP3-tilgang.

Ved oppsett gir Vymo dere de MX- og autentiseringspostene som gjelder for den bestilte e-posttjenesten. Ikke kopier mål fra et skjermbilde, en annen kunde eller en generell artikkel. DNS-verdiene må være de som hører til deres leveranse.

Se e-postplanene og hva som inngår hvis virksomheten trenger postbokser. Har dere allerede en leverandør, kan Vymo håndtere .no-domenet mens MX peker dit dere velger.

MX er en liten DNS-post med stor konsekvens. Publiser leverandørens eksakte mål, forstå preferansen og test både DNS og faktisk levering før gammel løsning stenges.