E-mail versturen vanuit zelfgehoste applicaties

Welke zelfgehoste applicaties e-mail moeten versturen

Om e-mail te versturen vanuit zelfgehoste applicaties heeft u geen mailserver nodig. U heeft een relay nodig: één geauthenticeerd SMTP-account, eenmalig geconfigureerd op de host, waaraan elke applicatie op de server zijn uitgaande e-mail overdraagt. Het beheren van een mailbox is het complexe vraagstuk, en dat is een ander probleem.

Het ontvangen van e-mail betekent dat u verbindingen van het hele internet accepteert op poort 25, spam filtert, mailboxen opslaat en back-upt, en een IP-reputatie verdedigt zolang de server bestaat. Die taak is aanzienlijk moeilijker geworden. Het versturen van e-mail betreft wachtwoordresets, aanmeldingsbevestigingen, "back-up mislukt"-meldingen en notificaties voor forumreacties. Dit zijn korte berichten met een laag volume die één voor één worden verzonden. Een relay handelt deze af en het instellen ervan kost een middag.

Bepaal welk van de twee problemen u daadwerkelijk probeert op te lossen. Of het nog de moeite waard is om een eigen mailbox te beheren is een terechte vraag met een reëel antwoord, en voor de meeste mensen is het antwoord nee. Als uw antwoord ja is, dan is een volledige Mailcow mailserver op een VPS de juiste weg. De andere helft, het versturen, is wat bijna iedereen nodig heeft en waar bijna niemand rekening mee houdt.

Eerst twee termen. SMTP (simple mail transfer protocol) is het protocol dat voor al deze onderdelen wordt gebruikt. Een relay, ook wel een smarthost genoemd, is een server die uw geauthenticeerde e-mail accepteert en deze doorstuurt met gebruik van zijn eigen adressen en zijn eigen reputatie.

Waarom uw VPS geen e-mail kan afleveren op poort 25

Bijna elke VPS-provider blokkeert standaard uitgaand TCP-verkeer op poort 25. Poort 25 is de poort die mailservers gebruiken om met elkaar te communiceren. Een gecompromitteerde VPS met een open uitgaande poort 25 kan direct spam versturen naar elke ontvangende mailserver. Providers droppen deze pakketten in plaats van ze te weigeren; daarom is het symptoom een verbinding die blijft hangen en vervolgens een time-out geeft, in plaats van een directe foutmelding.

Test dit vanaf de server:

sudo apt update && sudo apt install -y netcat-openbsd
nc -vz -w 5 gmail-smtp-in.l.google.com 25
nc -vz -w 5 smtp.relay.example 587

Als het eerste commando de volledige vijf seconden blijft hangen terwijl het tweede direct antwoord geeft, is de blokkade bevestigd. Sommige providers heffen deze op na een accountcontrole. De meeste doen dit niet.

De blokkade is niet de voornaamste reden om een relay te gebruiken. Zelfs met een open poort 25 belandt e-mail die direct vanaf een nieuw VPS-adres wordt verstuurd in de spam of wordt direct geweigerd. Dit komt doordat het adres geen verzendgeschiedenis heeft en zich in een reeks bevindt die door ontvangers als hostingruimte wordt aangemerkt. De richtlijnen voor verzenders van Google vereisen geldige forward en reverse DNS voor het verzendende IP-adres, en veel VPS-adressen hebben een generiek PTR-record (pointer) dat u niet kunt wijzigen. Een relay biedt u adressen die al over een reputatie beschikken.

Submission-poorten zijn de oplossing. Poort 587 ondersteunt STARTTLS, waarbij de sessie in cleartext begint en vervolgens wordt opgewaardeerd. Poort 465 ondersteunt impliciete TLS (transport layer security), waarbij de sessie vanaf de eerste byte versleuteld is. Beide zijn bedoeld voor geauthenticeerde clients, beide zijn open op VPS-netwerken en uw relay ondersteunt er ten minste één.

Kies een relay en een verzendend subdomein

Er zijn veel aanbieders van transactionele e-mail en ze vervullen allemaal dezelfde taak. Beoordeel ze op vier punten:

• een submission-poort, 587 of 465, met SMTP AUTH
• DKIM-ondertekening met uw eigen domein en uw eigen selector, niet alleen met die van hen
• bounce- en klachtgegevens die u kunt inzien, via een dashboard of een webhook
• een pakket dat past bij uw volume. Per augustus 2026 bieden verschillende aanbieders nog steeds enkele duizenden berichten per maand kosteloos aan, en die voorwaarden veranderen vaak; raadpleeg daarom de actuele prijspagina in plaats van een blogpost

Verzend applicatiemail vanaf een subdomein. Gebruik iets als notify.example.com in plaats van example.com. Ontvangers beoordelen de reputatie per domein, dus een foutieve verzending vanuit uw applicaties blijft buiten het domein waarvan uw facturen en de e-mail van uw team afkomstig zijn. Wees realistisch over de beperking: sommige ontvangers voegen signalen van subdomeinen samen op het niveau van het hoofddomein, waardoor een subdomein de schade eerder beperkt dan volledig isoleert.

Configureer de relay eenmalig voor elke zelfgehoste applicatie

De verleidelijke aanpak is om de instellingenpagina van elke applicatie te openen en daar de SMTP-host, gebruikersnaam en het wachtwoord in te voeren. Nextcloud, het forum, Grafana, Vaultwarden en de uptime-monitor hebben allemaal zo'n formulier. Als u dat doet, staan de inloggegevens op zes plekken, in zes formaten, waarvan sommige in een database die u als data back-upt in plaats van als configuratie. Wanneer u het wachtwoord wijzigt, moet u er vijf bijwerken. De zesde stopt met verzenden, en dat gebeurt geruisloos, omdat de meeste applicaties de SMTP-fout aan de serverzijde loggen en de gebruiker nog steeds een succesmelding tonen.

Configureer het in plaats daarvan eenmalig op de host en laat applicaties lokaal verzenden. Twee tools doen dit goed, en de keuze tussen beide draait om wachtrijbeheer.

msmtp is een sendmail-compatibele client zonder daemon. Deze maakt verbinding, verzendt en sluit af. Er is geen wachtrij; als de relay onbereikbaar is, gaat het bericht verloren en krijgt de aanroepende applicatie een exit-status die niet nul is.

Postfix geconfigureerd als een satellite is een volledige mail transfer agent met een echte wachtrij. Deze accepteert het bericht direct, probeert het bij een fout dagenlang opnieuw en bewaart de relay-inloggegevens in een bestand dat alleen toegankelijk is voor root. Gebruik dit wanneer het verlies van een melding tijdens een relay-storing onacceptabel is, of wanneer verschillende applicaties onder verschillende systeemgebruikers draaien.

msmtp, de compacte optie

sudo apt update
sudo apt install -y msmtp msmtp-mta ca-certificates

msmtp-mta installeert de /usr/sbin/sendmail symlink, zodat alles wat sendmail aanroept msmtp bereikt zonder dat het weet dat het bestaat.

Schrijf /etc/msmtprc:

defaults
auth            on
tls             on
tls_trust_file  /etc/ssl/certs/ca-certificates.crt
syslog          on

account         relay
host            smtp.relay.example
port            587
from            apps@notify.example.com
set_from_header on
user            <relay username>
password        <relay password>

account default : relay

set_from_header on stelt altijd een From-header in en overschrijft elke bestaande header, waardoor alles wat de applicatie produceerde wordt vervangen door het adres in from. Zonder dit verzendt een cron-job als root@your-hostname, en de relay weigert dat omdat het geen adres is dat u heeft geverifieerd. syslog on stuurt het logboek via syslog, zodat u het kunt lezen met journalctl -t msmtp. Een gedeeld logfile-pad is het alternatief, en dit vereist schrijfrechten voor elke gebruiker die mail verzendt, wat een risico vormt op een systeem met meerdere gebruikers.

Stel de rechten zelf in. msmtp dwingt rechten af op een configuratie per gebruiker (~/.msmtprc), waarbij het weigert te draaien met contains secrets and therefore must have no more than user read/write permissions. Het dwingt niets af op /etc/msmtprc, omdat het dat bestand simpelweg inlaadt als het leesbaar is.

sudo chown root:root /etc/msmtprc
sudo chmod 600 /etc/msmtprc
printf 'Subject: relay test\n\nsent from the host\n' | sudo sendmail -v you@example.com

-v print het volledige SMTP-gesprek, zodat u elk antwoord van de relay ziet. Een geslaagde verzending eindigt met een 250-antwoord dat het bericht accepteert. Een authentication failed-regel betekent dat de gebruikersnaam of het wachtwoord onjuist is, of dat de relay een API-sleutel verwacht in plaats van het accountwachtwoord.

Nu het addertje onder het gras, en dat is de reden waarom veel mensen bij Postfix uitkomen. Met modus 600 en eigenaar root kan alleen root verzenden. Een applicatie die draait als www-data kan het bestand niet lezen, msmtp slaat het over en de applicatie faalt met een foutmelding dat het standaardaccount niet is gevonden. De oplossing is een groep:

sudo chgrp mail /etc/msmtprc
sudo chmod 640 /etc/msmtprc
sudo usermod -aG mail www-data

Zeg duidelijk wat dat betekent: elk lid van de mail-groep kan het relay-wachtwoord lezen en vanaf die machine mail verzenden als uw domein. Op een VPS die u alleen beheert, is dat acceptabel. Waar verschillende applicaties die u niet zelf heeft geschreven onder verschillende gebruikers draaien, is dat niet zo, en is Postfix het betere antwoord omdat die applicaties de inloggegevens nooit zien.

Postfix als satellite

sudo debconf-set-selections <<'EOF'
postfix postfix/main_mailer_type select Satellite system
postfix postfix/mailname string notify.example.com
postfix postfix/relayhost string [smtp.relay.example]:587
EOF
sudo DEBIAN_FRONTEND=noninteractive apt install -y postfix libsasl2-modules

libsasl2-modules is niet optioneel. Zonder dit logt Postfix warning: SASL authentication failure: No worthy mechs found, omdat de PLAIN- en LOGIN-mechanismebibliotheken niet zijn geïnstalleerd onder /usr/lib/sasl2.

Stel de rest in met postconf -e, die /etc/postfix/main.cf in-place bewerkt:

sudo postconf -e 'relayhost = [smtp.relay.example]:587'
sudo postconf -e 'smtp_sasl_auth_enable = yes'
sudo postconf -e 'smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd'
sudo postconf -e 'smtp_sasl_security_options = noanonymous'
sudo postconf -e 'smtp_tls_security_level = encrypt'
sudo postconf -e 'smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt'
sudo postconf -e 'inet_interfaces = loopback-only'

De vierkante haken rond de relay-hostnaam voorkomen dat Postfix een MX-record voor die naam opzoekt en zorgen ervoor dat het direct verbinding maakt met de naam. Sommige relay-hostnamen publiceren MX-records die naar ergens anders wijzen, en zonder de haken volgt uw mail deze naar de verkeerde server.

smtp_tls_security_level = encrypt maakt TLS verplicht, zodat het bericht nooit in leesbare tekst wordt verzonden. Het verifieert het certificaat niet. De documentatie van Postfix zelf is hier expliciet over: op dat niveau gaat de aflevering door, zelfs als het servercertificaat niet wordt vertrouwd of de verkeerde naam bevat. Als u wilt dat het certificaat wordt gecontroleerd, gebruik dan verify of secure en houd smtp_tls_CAfile ingesteld.

De inloggegevens gaan in één bestand dat alleen toegankelijk is voor root:

echo '[smtp.relay.example]:587 relay-username:relay-password' | sudo tee /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap hash:/etc/postfix/sasl_passwd
sudo systemctl restart postfix

postmap bouwt de geïndexeerde kopie die Postfix daadwerkelijk leest. Bewerk het tekstbestand later en vergeet postmap, en Postfix blijft de oude database gebruiken zonder dat het logboek u daarvan op de hoogte stelt. Op Postfix 3.9 en nieuwer is het standaard kaarttype lmdb, dus schrijf lmdb: in zowel de parameter als het postmap-argument als u dat verkiest. Het benoemen van het type op beide regels zorgt ervoor dat ze synchroon blijven.

Applicaties adresseren hun mail nog steeds als root@hostname. Herschrijf de afzender:

echo '/.+/    apps@notify.example.com' | sudo tee /etc/postfix/sender_canonical
sudo postconf -e 'sender_canonical_classes = envelope_sender, header_sender'
sudo postconf -e 'sender_canonical_maps = regexp:/etc/postfix/sender_canonical'
sudo systemctl reload postfix

Een regexp:-tabel wordt direct gelezen, dus deze heeft geen postmap nodig. Elk bericht verlaat nu het systeem met dezelfde envelope-afzender en dezelfde From-header, wat de relay vereist. Het nadeel is dat antwoorden allemaal op één plek terechtkomen, dus stel een Reply-To-header in binnen elke applicatie waar antwoorden een persoon moeten bereiken.

Verzend een test en lees het logboek:

printf 'Subject: postfix relay test\n\nsent through the queue\n' | sendmail you@example.com
sudo tail -n 20 /var/log/mail.log

Een afgeleverd bericht logt status=sent gevolgd door het antwoord van de relay zelf tussen haakjes. Al het andere benoemt de reden. status=deferred met Connection timed out betekent dat er nog steeds iets naar poort 25 wijst. Host or domain name not found. Name service error for name=smtp.relay.example type=A betekent dat de relay-hostnaam onjuist is of dat DNS op de machine niet werkt. mailq somt op wat vastzit en sudo postqueue -f probeert het nu opnieuw.

De host-relay bereiken vanuit Docker-containers

Een container kan de sendmail van de host niet aanroepen, omdat het binaire bestand niet in de image staat en de wachtrij niet wordt gedeeld. Geef de containers in plaats daarvan een netwerkdoel. Postfix kan luisteren op het Docker-bridge-adres.

ip -4 addr show docker0
sudo postconf -e 'inet_interfaces = 127.0.0.1, 172.17.0.1'
sudo postconf -e 'mynetworks = 127.0.0.0/8 172.17.0.0/16'
sudo systemctl restart postfix

Lees uw eigen bridge-adres af van dat eerste commando in plaats van dit commando te kopiëren, omdat een Compose-project zijn eigen netwerk op een ander subnet aanmaakt en docker network inspect <name> dit weergeeft. Gebruik hier restart en niet reload: Postfix documenteert dat u moet stoppen en starten na het wijzigen van inet_interfaces, en een reload zal de wijziging niet verwerken. Elke app krijgt vervolgens SMTP-host 172.17.0.1, poort 25, zonder authenticatie en zonder TLS, omdat dat verkeer de host nooit verlaat. Als uw services op een Compose-netwerk staan, behandelt Docker Compose draaien op een VPS waar dat subnet vandaan komt.

Dit is de stap die tot problemen kan leiden. Een Postfix die luistert op een publiek adres met een ruime mynetworks is een open relay: vreemden versturen hun e-mail via uw relay-account, de provider schorst het account en de reputatie van uw domein loopt maandenlang schade op. Controleer beide kanten na elke wijziging.

ss -tlnp | grep ':25'

De uitvoer mag alleen het loopback-adres en het bridge-adres tonen. Vanaf een andere machine moet nc -vz your.server.ip 25 mislukken.

SPF, DKIM en DMARC voor het verzendende domein

Publiceer alle drie de records vóór de eerste echte verzending. Ze zijn gratis, ze zijn onderdeel van DNS en ze zijn het eerste waar ontvangende partijen op controleren.

SPF (sender policy framework) specificeert wie uw domein in de envelope sender mag plaatsen. Publiceer dit op het verzendende subdomein:

notify.example.com.  IN  TXT  "v=spf1 include:_spf.relay.example -all"

Kopieer de include:-waarde van de instellingenpagina van uw relay, omdat een include die niet kan worden omgezet een permanente fout geeft in plaats van een pass. SPF-evaluatie stopt na tien DNS-querymechanismen en geeft permerror terug, wat door ontvangers als een fout wordt beschouwd; houd het aantal includes daarom beperkt. Publiceer precies één v=spf1-record per naam: twee records resulteren eveneens in een permerror.

DKIM (domainkeys identified mail) ondertekent elk bericht met een privésleutel die de relay beheert, waarna ontvangers de bijbehorende publieke sleutel uit DNS ophalen. Uw relay verstrekt u een selector en een TXT-record of CNAME om te publiceren:

sel1._domainkey.notify.example.com.  IN  CNAME  sel1.dkim.relay.example.

DKIM is belangrijker dan SPF, omdat DKIM intact blijft bij het doorsturen van e-mail. Wanneer een mailinglijst of een .forward-regel uw bericht doorstuurt, komt het aan vanaf het IP-adres van de doorstuurserver; SPF faalt dan, terwijl de handtekening nog steeds valideert.

DMARC (domain-based message authentication, reporting and conformance) instrueert ontvangers wat ze moeten doen wanneer geen van beide controles overeenkomt, en verzoekt hen om rapportages terug te sturen. Publiceer dit op het organisatiedomein:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r"

Begin bij p=none en lees de rapporten gedurende twee weken. p=none verandert niets aan de aflevering, het activeert enkel de rapportagefunctie. Hiermee ontdekt u welke systemen namens uw domein verzenden waarvan u het bestaan was vergeten. Stap daarna over naar p=quarantine en vervolgens naar p=reject. Het publiceren van p=reject op de eerste dag is de manier waarop men ontdekt dat hun facturatiesysteem namens het domein verzond, vaak pas nadat een klant meldt nooit een factuur te hebben ontvangen.

Controleer wat de buitenwereld ziet, niet wat uw DNS-paneel toont:

dig +short TXT notify.example.com
dig +short TXT sel1._domainkey.notify.example.com
dig +short TXT _dmarc.example.com

Een lege uitvoer betekent dat het record nog niet is verspreid of dat de naam onjuist is. Een record dat u vijf minuten geleden heeft gecorrigeerd, kan in caches onjuist blijven gedurende de resterende duur van de vorige TTL (time to live); controleer daarom de TTL voordat u conclusies trekt.

Houd From en Return-Path op één lijn

Elk bericht bevat twee afzenderadressen en deze worden op verschillende manieren gecontroleerd. De envelope sender wordt opgegeven in het SMTP MAIL FROM-commando en verschijnt in het afgeleverde bericht als Return-Path. De header From is het adres dat de lezer ziet.

SPF controleert het domein van de envelope sender tegen het verbindende IP-adres. DKIM rapporteert het domein dat het bericht heeft ondertekend als d=. DMARC slaagt alleen wanneer ten minste een van die twee domeinen overeenkomt met het domein in de header From. Bij 'relaxed alignment' (adkim=r, aspf=r, wat de standaard is) telt een subdomein ook mee, dus een envelope sender op notify.example.com komt overeen met een header From op example.com. Bij 'strict alignment' is dit niet het geval.

De praktische regel is kort: gebruik hetzelfde domein voor de header From en de envelope sender, dan doet dit probleem zich nooit voor. Dat is precies wat set_from_header on doet in msmtp en wat sender_canonical_maps doet in Postfix.

Bekijk het oordeel in een afgeleverd bericht. In Gmail toont "Show original" de header die de ontvanger heeft geschreven:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@notify.example.com;
       spf=pass (google.com: domain of apps@notify.example.com designates 198.51.100.25 as permitted sender) smtp.mailfrom=apps@notify.example.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

Alle drie de controles slagen daar. Elke andere melding benoemt de controle die is mislukt en meestal ook de reden waarom; dit is de snelste manier om dit onderwerp te debuggen.

Bounces en klachten, voordat het volume toeneemt

Een bounce treedt op wanneer een ontvanger uw bericht weigert. Een hard bounce is permanent en Gmail duidt dit aan als 550 5.1.1 The email account that you tried to reach does not exist. Een soft bounce is tijdelijk, vaak een 4xx-code voor een volle mailbox of greylisting, waarbij de relay het automatisch opnieuw probeert.

Relays meten uw hard bounce-percentage en schorten accounts op die blijven mailen naar adressen die niet bestaan, omdat dat patroon kenmerkend is voor een gekochte lijst. Klachten wegen zwaarder. Een klacht is een persoon die op de spamknop drukt. De richtlijnen voor verzenders van Google (gecontroleerd in augustus 2026) vragen verzenders om onder een spampercentage van 0,30% te blijven zoals gerapporteerd in Postmaster Tools, en adviseren om onder de 0,10% te blijven.

Zorg dat de volgende vier zaken geregeld zijn voordat het volume toeneemt:

• een webhook, of een wekelijkse controle van de suppression list van de relay, zodat u bounces daadwerkelijk ziet
• een From-adres dat een echte mailbox is die iemand leest, met Reply-To ingesteld voor waar antwoorden thuishoren
• bevestiging voordat een adres aan iets wordt toegevoegd, zodat u nooit mailt naar een adres dat de eigenaar niet zelf heeft ingevoerd
• een rate limit op elk formulier dat mail activeert

Die laatste twee punten zijn waar zelfgehoste applicaties het eerst falen. Een onbeveiligd aanmeldformulier laat iedereen het adres van een vreemde invullen, uw server verstuurt de bevestiging en de vreemde markeert dit als spam. Het stoppen van subscription bombing bij uw aanmeldformulier is zowel een taak voor afleverbaarheid als voor misbruikpreventie.

Houd bulkmail buiten dit pad. Nieuwsbrieven vereisen lijstbeheer en unsubscribe-headers die transactionele mail nooit heeft, dus verstuur deze via een zelfgehoste Listmonk-instantie op een eigen subdomein met een eigen reputatie. Notificatiemail van een zelfgehost forum zit hier tussenin; transactioneel van aard maar met een bulkvolume, en dit is meestal het eerste dat laat zien of uw configuratie standhoudt.

Ter referentie: de regels van Gmail voor bulkverzenders zijn van toepassing bij meer dan 5.000 berichten per dag naar Gmail-adressen en vereisen SPF, DKIM, DMARC en one-click unsubscribe bij marketingmail. De meeste zelfgehoste applicaties bereiken die grens nooit. De authenticatiekant wordt tegenwoordig echter van elke verzender verwacht, ongeacht het volume.

Test het voordat u het vertrouwt

swaks is hiervoor de juiste tool. Het spreekt SMTP en geeft het volledige gesprek weer, zodat u ziet welke stap is mislukt.

sudo apt install -y swaks
swaks --to you@example.com --from apps@notify.example.com --server smtp.relay.example --port 587 --tls --auth-user '<relay username>' --auth-password '<relay password>'

Hiermee test u de inloggegevens rechtstreeks tegen de relay. Om het pad te testen dat uw applicaties daadwerkelijk gebruiken, wijst u het naar de host-relay:

swaks --to you@example.com --from apps@notify.example.com --server 127.0.0.1

Controleer vervolgens het resultaat van begin tot eind, vanaf de server, met echte e-mail. Niets hiervan kan worden bewezen op basis van configuratiebestanden, dus voer de test zelf uit:

• verstuur naar een scoringsservice zoals mail-tester.com, die uw SPF, DKIM, DMARC en de inhoud van het bericht leest en de redenen achter de score geeft
• verstuur naar een mailbox bij elk van de twee providers waar uw gebruikers daadwerkelijk zitten, en lees Authentication-Results in het onbewerkte bericht
• doorloop één bericht via learndmarc.com wanneer het uitlijningsresultaat niet duidelijk is
• activeer een verzending vanuit de applicatie zelf, niet alleen vanaf de opdrachtregel, omdat de applicatie degene is die de From-header instelt

Eén eerlijke waarschuwing tot slot. Een gloednieuw domein met alle drie de records correct ingesteld belandt soms nog steeds in de spam, omdat het geen geschiedenis heeft en ontvangers voorzichtig zijn met domeinen die vorige week zijn aangemaakt. Begin klein en verstuur e-mail die mensen verwachten. De reputatie wordt vanaf dat punt opgebouwd, en geen enkele configuratie kan dat proces overslaan.

FAQ

Waarom is uitgaande poort 25 geblokkeerd op mijn VPS?

Vrijwel elke provider blokkeert standaard uitgaande TCP-poort 25. Een gecompromitteerde server met deze poort open kan namelijk direct spam versturen naar ontvangende mailservers. De pakketten worden genegeerd in plaats van geweigerd; het symptoom is daarom een verbinding die blijft hangen en uiteindelijk een timeout geeft, in plaats van een foutmelding. Bevestig dit door nc -vz -w 5 gmail-smtp-in.l.google.com 25 uit te voeren naast nc -vz -w 5 smtp.relay.example 587: de eerste blijft hangen, de tweede antwoordt direct. De oplossing is niet om de blokkade op te heffen. Verstuur mail via een relay op submission-poort 587 of 465; deze blijven open en zijn bedoeld voor geauthenticeerde clients.

Heb ik SPF, DKIM en DMARC nodig voor slechts een paar notificaties vanuit mijn app?

Ja, en het volume maakt hierbij niet uit. Ontvangers passen dezelfde controles toe op één wachtwoordreset als op een campagne van vijftigduizend berichten. Zonder SPF en DKIM is uw mail niet geauthenticeerd, en de huidige richtlijnen van Google vereisen ten minste één van beide voor elke verzender. Zonder DMARC ontvangt u geen rapporten, waardoor het eerste teken van een probleem een gebruiker is die meldt dat de resetlink nooit is aangekomen. Alle drie zijn DNS-records, ze kosten niets en het publiceren ervan duurt ongeveer tien minuten.

Moet ik msmtp of Postfix gebruiken als relay-client?

Gebruik msmtp wanneer één persoon de server beheert en het verlies van een bericht tijdens een relay-storing acceptabel is. Het is een enkel configuratiebestand zonder daemon, en omdat het niet in een wachtrij plaatst, is een bericht verloren als de relay onbereikbaar is. Gebruik Postfix als satelliet wanneer u een wachtrij wilt die dagenlang opnieuw probeert te verzenden, of wanneer meerdere apps onder verschillende systeemgebruikers draaien. Postfix bewaart het relay-wachtwoord in een bestand dat alleen toegankelijk is voor root, terwijl de configuratie van msmtp leesbaar moet zijn voor elke gebruiker die mail verstuurt.

Waarom wordt de mail van mijn app geweigerd omdat deze afkomstig is van root?

Cron-jobs en veel apps bouwen de afzender op basis van de lokale gebruiker en hostnaam, wat resulteert in iets als root@srv1.localdomain. Dat is geen adres dat u heeft geverifieerd bij de relay, dus de relay weigert het bericht met een 553 of 554-antwoord waarin het afzenderadres wordt genoemd. Los dit op hostniveau op in plaats van in elke app: set_from_header on in combinatie met een from-adres in /etc/msmtprc, of sender_canonical_maps met sender_canonical_classes = envelope_sender, header_sender in Postfix. Stel Reply-To in binnen elke app als antwoorden een persoon moeten bereiken.

Beschermt een apart subdomein voor app-mail mijn hoofddomein echt?

Gedeeltelijk, en het is nog steeds de moeite waard. Ontvangers houden de reputatie per domein bij, dus klachten tegen notify.example.com blijven grotendeels beperkt tot notify.example.com, terwijl uw hoofddomein mail blijft afleveren. De beperking is reëel: sommige ontvangers aggregeren subdomeinsignalen naar het organisatiedomein, en een DMARC-beleid dat op organisatieniveau is gepubliceerd, is van toepassing op subdomeinen tenzij u sp= afzonderlijk instelt. Beschouw het subdomein als schadebeperking in plaats van als garantie.