Het versturen van e-mail vanaf een eigen server is altijd een “dingetje” geweest.
Een aantal factoren zullen negatief van invloed zijn op ongewenste e-mail filters op server en applicatie niveau.
- Standaard zal jouw website waarschijnlijk gehost worden op een zogeheten “shared hosting omgeving”, waar niet alleen jouw website, maar ook tientallen andere uiteenlopende websites gehost zijn. Er zullen dan vanaf het desbetreffende IP adres niet alleen door jouw website e-mails worden verzonden, maar ook de andere websites sturen e-mails uit vanuit hetzelfde IP adres
- Als je relatief veel e-mails met soortgelijke opbouw en content verzend kan de kans bestaan dat het eerder wordt aangemerkt als een ‘mail bom’, echter als jouw website bijvoorbeeld beschikt over een reserveringsmodule of betaal- en verzendnotificatie mails kun je hier niet omheen, buiten de naam en reserveringsdatum / aankoopgegevens kan de rest van de getoonde informatie in deze e-mails identiek zijn.
Met onderstaande tips heb ik in het verleden succesvolle resultaten geboekt waarmee e-mails minder snel in de ongewenste e-mail folder belanden. Helaas berust dit op mijn eigen ervaringen en hoeft dit geen garanties te bieden dat dit voor jouw case ook het geval is. Zelf heb ik in de Mail-Tester circa 4 punten winst weten te behalen wat de mails daarnaast tevens van de ongewenste e-mail folder naar de inbox wist te verhuizen in diverse Microsoft Office 365 omgevingen. Dit heb ik bereikt door enkel de SPF Records en het ‘Return-Path’ aan te passen, hopelijk kun jij door het toepassen van deze tips soortgelijke resultaten bewerkstelligen.
E-Mail Service
Laten we maar gelijk met de deur in huis vallen, idealiter verstuur je je e-mails niet vanaf een (shared) hosting. De kans is groot dat dit IP Adres door meerdere domeinen (in het verleden) wordt gebruikt waardoor de markering van deze server niet ideaal is. Ook ben je bij het versturen van honderden mails per dag sowieso al snel een “Red Flag” voor Spam filters en kan het optimaliseren van de load om deze pieken te spreiden, of verdere server aanpassingen om netter met uit te sturen mails om te gaan al snel tijdrovend worden.
Als het versturen van bevestigingsmails, notificaties of eender andere mail oplossing een van je core activiteiten is, zou ik aan willen raden om eens te kijken of een E-mail service zoals Mailgun of Amazon SES niet beter geschikt is voor jouw doeleinde, hier zijn echter wel kosten aan verbonden. Mocht je sporadisch een mail versturen of het toch willen proberen, lees dan gerust verder.
SPF – Sender Policy Framework’
SPF staat voor ‘Sender Policy Framework’, iets dat ik voor het schrijven van dit bericht ook nooit uitgeschreven had gezien terwijl ik het toch al enige tijd toepas. Wat ik door ervaring wel weet over deze zogeheten SPF Records is dat ze eigenlijk onmisbaar zijn in de DNS Records van jouw domeinnaam. Nou kan ik hier een heel betoog gaan afsteken over wat SPF precies inhoud en welke parameters tot welk resultaat kunnen leiden. Echter zoals eerder aangegeven ben ik geen DevOps en is er genoeg te vinden over SPF Records waardoor ik het voor nu hou op 2 relatief simpele voorbeelden welke voor mij tot het beoogde resultaat hebben geleid.
Het meest simpele voorbeeld is, stel dat het domein *.doe.com mails verstuurd vanuit IP Adres “192.168.1.1” dan stel je deze als volgt in:
v=spf1 a ip4:192.168.1.1 ip6:::ffff:c0a8:101 -all
Het 2de voorbeeld heb ik toegevoegd omdat in het gros van de gevallen waar ik het de laatste tijd nog mis zie gaan, Microsoft met haar Office 365 pakketten nogal streng blijkt te zijn in deze check. Eigenlijk kan het sowieso geen kwaad om dit toe te voegen aan je SPF Record, maar mocht je er zeker van zijn dat de ontvanger gebruik maakt van Office 365 dan is dit een must om aan je SPF Record toe te voegen.
v=spf1 a ip4:192.168.1.1 ip6:::ffff:c0a8:101 include:spf.protection.outlook.com -all
Tip: zoals je ziet voeg ik ook gelijk het IPv6 adres van de server toe, ik heb al scenario’s gezien waarop spamfilters de check op IPv6 doen i.p.v. de oude, vertrouwde 127.0.0.1 achtige IP adressen.
Het Return-Path instellen
Op de perfect ingerichte webserver, zou je je hierover eigenlijk geen zorgen hoeven maken, maar mocht het je ontbreken aan een DevOps of draai je net als ik op een wat simpeler hosting pakket dan zijn er zaken die je wellicht in kunt stellen op PHP Niveau. Één van de zaken waarop ik veel winst heb weten te boeken is het zogeheten ‘Return-Path’. Dit is wat door de server ten aller tijden aan je mail wordt toegevoegd, zelfs als je bijv. in Contact Form 7 een ‘From:’ adres aangeeft kan er mailtechnisch gezien nog altijd iets staan als “Verzonden door John@Doe.com via returnpath@server.com”. Dit zorgt dus voor een conflict tussen wat jij ziet als afzender en de afzender vanuit de server, iets dat voor Spamfilters een behoorlijke “Red Flag” is als het gaat om de controle op ongewenste e-mails.
Ik ben toen gestuit op onderstaande code waardoor dit (in ieder geval in PHPMailer) is aan te passen zonder daarbij in je serverinstellingen te hoeven duiken. Deze code overschrijft de server afzender (returnpath@server.com, red.) door jouw (ingestelde) afzender (John@Doe.com, red.). Iets wat in mijn tests naast het SPF record een van de grootste winsten opleverde.
/**
* Attempt to override Return-Path
*
* @author: Simon
* @date: 14-3-2018
* @url: http://Simon.vdSteen.me/WordPress/e-mail-headers-optimaliseren-tegen-spam
*/
add_action( 'phpmailer_init', function( $phpmailer ) {
$phpmailer->Sender = $phpmailer->From;
} );
DKIM – DomainKeys Identified Mail
Als laatste wil ik DKIM dan nog even toelichten, zelf heb ik mij hier nooit in verdiept omdat hier extra verificatie en configuratie bij komt kijken, maar mocht je met bovenstaande optimalisaties geen winst in het aantal afgeleverde mails bereiken dan kan dit de moeite zijn om eens in te duiken.
Bij het gebruik van DKIM genereer je ‘keys’ waarmee je de echtheid van je mails waarborgt, middels deze ‘keys’ (een ‘private key’ op jouw server en een ‘public key’ in een DNS Record) leg je een relatie tussen de server waar je de mails vandaan stuurt en de DNS van het domeinnaam. Vervolgens controleert de ontvangende mailserver op basis van de ingestelde ‘selector’ of de versleutelde header uit de mail overeenkomt met de ‘key’ in het DNS Record, waardoor de authenticiteit van de verzendende server kan worden gewaarborgd.
Mail-Tester
Wanneer je bovenstaande optimalisaties hebt doorgevoerd, is het tijd om te testen. Dit doe ik in dit geval door het gebruik van Mail-Tester
De slogan van Mail-Tester is: “Test de Spamyness van je emails”. Deze dienst is opgezet door de ontwikkelaars achter MailPoet en AcyMailing. Hoewel ook zij met hun jarenlange ervaring geen garanties kunnen geven dat jouw e-mails überhaupt aankomen, is het een goede eerste indicatie van de kwaliteit van jouw e-mail headers en de relatie tussen server en DNS instellingen. Indien zelfs Mail-Tester jouw e-mail headers al met een 1.2 beoordeelt kun je er vrij zeker van zijn dat de kans dat jouw berichten ooit het daglicht zullen zien relatief laag is. Mail-Tester geeft een goede eerste indicatie omtrent het technische niveau van de e-mails die vanuit jouw WordPress website worden gegenereerd.
Dus naast het testen of de mails goed in jouw mailbox aankomen, stel ik ten aller tijden voor om na livegang ook een test e-mail naar een Mail-Tester e-mailadres te sturen om te kijken of er nog verbeterpunten zijn. Dit doe je door te surfen naar https://www.mail-tester.com/ en het hier aangeduide e-mail adres in het afleverveld van je contactformulier te plaatsen.