Een verzendende applicatie en een inkomende mailbox kunnen verschillende domeinen gebruiken. De records die replies routeren hoeven niet op elk subdomein te staan dat je voor verzending gebruikt.
Hoe gebruikt een verzendende server MX-records?
De verzendende server zoekt het domein van de ontvanger op om de servers te vinden die inkomende e-mail accepteren.
Voor person@example.org zoekt de server MX-records op voor example.org. Elk record benoemt een bestemmingsserver waarvan de hostnaam naar een IP-adres verwijst.
RFC 5321 definieert dit opzoekproces voor SMTP.
De verzendende server meldt een fout wanneer het ontvangerdomein niet bestaat. Na een tijdelijke opzoekfout plaatst de server het bericht in de wachtrij voor een latere poging.
Wat gebeurt er als een domein geen MX-record heeft?
Als er geen MX-records bestaan, behandelt SMTP het domein zelf als bestemming en probeert de adresrecords ervan.
Deze impliciete MX heeft voorkeur nul. Er is geen expliciete MX-lijst die ervoor gaat, dus aflevering verloopt naar het eigen adres van het domein als dat bruikbaar is.
Deze fallback geldt voor een lege MX-lijst. Het redt geen domein waarvan de gepubliceerde MX-records onbruikbaar zijn.
Een null MX is een andere instructie: RFC 7505 definieert een expliciet record dat verklaart dat het domein geen e-mail accepteert. Een afwezig record staat fallback toe. Een null MX weigert aflevering.
Wat betekenen MX-voorkeursgetallen?
Lagere voorkeurswaarden geven aan welke bestemmingen een afzender eerst moet proberen.
Bij waarden 10, 20 en 30 heeft de bestemming op 10 de voorkeur. De overige bieden alternatieven als aflevering daar niet lukt. Als je elke bestemming dezelfde waarde geeft, maakt dat verdeling over gelijkwaardige bestemmingen mogelijk.
Volgens RFC 5321 moeten verzendende servers bestemmingen met dezelfde voorkeur in willekeurige volgorde proberen, tenzij er een duidelijke reden is om een ervan te verkiezen. Gelijke voorkeurswaarden garanderen geen exacte verdeling van verkeer.
Verwijs je MX-record naar een hostnaam waarvan je het adres publiceert, zodat afzenders verbinding kunnen maken. Gebruik een A-record voor het IPv4-adres of een AAAA-record voor IPv6. Gebruik geen CNAME-alias als bestemming. De alias voorkomt dat DNS het adres bij het MX-antwoord opneemt. Dat voegt opzoekacties toe, zoals RFC 2181 uitlegt.
SMTP-clients moeten ondersteunen dat alternatieve bestemmingen worden geprobeerd. De specificatie beveelt aan om minstens twee adressen te proberen als die beschikbaar zijn. Een fout bij het eerste adres hoeft dan niet het einde van de afleveringspogingen te zijn.
Heb je een MX-record nodig om te verzenden?
SMTP vereist geen expliciet MX-record op je domein alleen om een bericht te verzenden.
De afleveringsopzoeking gebruikt het ontvangerdomein. Je verzenddomein heeft nog steeds geldige DNS en authenticatie nodig die voldoet aan de eisen van de ontvanger. Een ontvanger kan eigen controles toepassen op het afzenderdomein.
Een ontbrekend MX-record betekent daarom niet dat een onbereikbaar afzenderdomein acceptabel is voor elke ontvanger.
Waar gaan afleverfouten naartoe?
Afleverfouten gaan naar de envelope-afzender, het adres dat voor foutmeldingen is opgegeven tijdens SMTP-aflevering.
Waar gaan replies naartoe?
Replies gebruiken normaal Reply-To als dat aanwezig is, anders het zichtbare From-adres.
Een verzendsubdomein hoeft niet elke bedrijfsmailbox te hosten. news.example.com kan bijvoorbeeld verzenden terwijl replies naar een werkend adres op example.com gaan. Maak die routeringskeuze expliciet in de adressen van het bericht.
Waar gaan operationele rapporten naartoe?
Operationele adressen zoals postmaster@ en abuse@ geven andere beheerders een manier om aflever- of misbruikproblemen te melden.
Volgens RFC 5321 moet een SMTP-server die e-mail doorstuurt of aflevert, postmaster@ accepteren voor de domeinen die hij bedient. Dit biedt een contactpunt voor problemen met de e-maildienst.
RFC 2142 vereist dat organisaties role-mailboxen ondersteunen als de bijbehorende functie bestaat. Een internetprovider moet bijvoorbeeld abuse@ ondersteunen op zijn organisatiedomein. Dit routeert klachten naar het verantwoordelijke team.
Hoe ontvang je e-mail met Bird?
Je schakelt ontvangst in voor een domein en publiceert de MX-records die Bird teruggeeft.
Het inbound.enabled-veld van de API accepteert true om ontvangst in te schakelen of false om het uit te schakelen. Alleen de records publiceren schakelt de functionaliteit niet in.
Na verificatie wordt e-mail die aan dat domein is gericht inkomende berichten. Gebruik een apart ontvangstsubdomein, want het vervangen van de MX-records van je bedrijfsdomein verandert waar bestaande e-mail aankomt.
Het return-path-record van Bird verwerkt afleveringsfoutmeldingen apart van die inkomende MX-records. De ontvangstgids legt de domeinconfiguratie uit. De bounce-domeingids legt foutafhandeling uit.
Kort gezegd
MX-records routeren inkomende e-mail.
De verzendende server zoekt het ontvangerdomein op om een bestemming te vinden.
Ontbrekende MX-records kunnen terugvallen op adresrecords.
Als er geen MX-records bestaan, kan de verzendende server de adresrecords van het domein gebruiken.
Lagere voorkeurswaarden worden eerst geprobeerd.
Bestemmingen met dezelfde voorkeur worden in willekeurige volgorde geprobeerd als er geen reden is om een ervan te verkiezen.
Verzenden en ontvangen vragen aparte beslissingen.
Uitgaande e-mail heeft nog steeds passende afhandeling nodig voor afleverfouten, replies en operationele contactadressen.