At work we build and host web based applications. As part of that, our applications generate email. We don’t get too fancy with sending email, we just shoot it out using Windows Internet Information Services (IIS) SMTP service. Traditionally we never really configured it, we just turned it loose.
As the world becomes more and more spam conscious, we spend more time suggesting to our clients that they might have to keep an eye on their spam folders just in case our emails aren’t showing up. Heck, sometimes emails sent to ourselves, as part of testing, don’t show up either. That’s not really an ideal approach and I finally sat down late last week to fix things up a bit.
First I had our server send me an email to my Google Apps account and checked out the “original” version of the mail – this is nice feature of Google Mail that a lot of folks haven’t noticed, but comes in handy for stuff like this:
Two of the lines in the header tell a grim story:
Received-SPF: softfail (google.com: best guess record for domain of transitioning noreply@mycompany.com does not designate 5.79.185.165 as permitted sender) client-ip=5.79.185.165;
Authentication-Results: mx.google.com; spf=softfail (google.com: best guess record for domain of transitioning noreply@mycompany.com does not designate 5.79.185.165 as permitted sender)smtp.mail=noreply@mycompany.com
Clearly I have things to fix.
Sender Policy Framework
First I tackled SPF – for some reason I had no SPF DNS records defined. SPF stands for Sender Policy Framework and you can read all about it over at Wikipedia. The short version is that it is a way for administrators to define which servers are allowed to send email for their domains. Mail servers then look for these SPF records to help determine if mail received is spam or legit.
I found a great SPF Wizard over at openspf.org and used it to determine what my record should look like. We’re a Google Apps customer so I had to make sure I included their servers as well as our assorted app servers. I specified some by IP, some by domain name, included the Google entry and got a record that looks roughly like this:
v=spf1 ip4:5.79.185.165 a a:demo.mycompany.com include:aspmx.googlemail.com ~all
I then popped over to my registrar and added that as a DNS TXT record. Actually, I did it twice. Once for just the domain name and one for the wildcarded subdomains. Gotta cover my bases for the next step.
Reverse DNS and IIS
OK, next I tackled Reverse DNS. I wanted to make sure that application mail server identified itself by a name that would match when other mail servers would look up its IP address. There are two pieces to this one. First my SMTP server and the actual reverse DNS configuration.
By default, IIS SMTP server gives out its internal FQDN (fully qualified domain name) – in other words, something like webserver.ad.companyname.com. For me, this is never the same as the external DNS name – for instance, application.companyname.com. Fixing this in IIS SMTP had stumped for the longest time… but it turns out it is pretty easy to fix.
If you want to see what yours is doing just telnet to port 25 of the mail server and check the greeting. Top of the banner will be the machine name. You can hit enter a few times and then HELO and have a conversation or just type “quit” to be done.
To change the name, go into IIS Manager, right-click on the SMTP node and click properties. Go to the Delivery tab and click “Advanced…” at the bottom. As mentioned, by default the FQDN field is the machine’s internal name. I initially tried setting a value in the “Masquerade domain” field but that didn’t seem to change anything (I guess I should research that…). I took a deep breath and just changed the FQDN field to the server’s external name. Fortunately, all heck did not break out and mail continued to get processed. A quick telnet test showed the right address.
Next I contacted our co-location provider and asked them to setup the reverse DNS for my server’s IP. 10 minutes later the server name matched the IP matched the reverse DNS. Fun!
Results?
Sent another test email to myself and the headers look a lot better now (compare to the ones above):
Received-SPF: pass (google.com: domain of noreply@mycompany.com designates 5.79.185.165 as permitted sender) client-ip=5.79.185.165;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of noreply@mycompany.com designates 5.79.185.165 as permitted sender) smtp.mail=noreply@mycompany.com
Neat, huh? This isn’t a cure all, but I think just these few changes will make a big difference in our mail getting through.
For testing, I found the reports at allaboutspam.com were incredibly helpful. I just set up a quick ASP page to send test mails from my application server to their test service and they’d bounce it back with a nice report link. Slick.
All cynicism aside, most tasks are easy to puzzle out – but not AD integration! My first attempt didn’t work at all. Fortunately, I found an article at EduGeek.net that was immensely helpful, “
