Rules for Sending Mail
Or How to Improve the Likelihood of Delivery
We'd love to get mail from you! Unfortunately, spam has made e-mail, and the internet in general, a pretty unpleasant place to be. To help you help us get your mail, and keep out the spam, here's what we look for when deciding whether to accept or reject mail.
We use a fairly simple convention in the text below: "SHALT" and "SHALL" means we will perform a hard reject, right then and there. "SHOULD" means we consider it a point against you. Violation of too many SHOULDs will result in a rejection of your mail, with a listing of the violated SHOULDs helpfully included.
General Connection
- Thou Shalt Have rDNS (PTR record)
- PTR records help track the owner of an IP and abuse. Plus, lots of botnet spam zombies lack PTR records, and (this is the best part) they generally can't give themselves PTR records. A legitimate mail operator, however, should find it to be no trouble at all. rDNS makes the internet a better place for everybody, so be sure you've got it.
- Thou Should Have FCrDNS (Forward-Confirmed Reverse DNS)
- FCrDNS is just a fancy way of saying if your PTR record says your IP belongs to some.host, then some.host better resolve to that IP. In other words, that your records match.
- Thou Should Not Have a Dynamic-Looking PTR Record
- Lots of residential IP addresses have PTR records that look similar to 192-168-33-7.some-isp.net. If yours looks like that, you'll get lost in a sea of botnet zombie machines and your mail is much less likely to be delivered. Set yourself up with a nice, friendly hostname.your-domain.tld. If you can't think of anything to call it, name the host after your mother. She'll like that.
- Thou Should Not Be On DNS Blacklists
- It will severely hamper your efforts to mail us, and we're nicer than most: we require at least two of the blacklists we check to mention you before outright rejecting a message just in case one of the lists is wrong. But even being on one blacklist means you've got much less room for error before we stop talking to you.
- Thou Should Be Registered on dnswl.org
- We'll be a little more lenient if they vouch for you.
EHLO / HELO
- Thou Shalt Issue an EHLO or HELO
- It's just plain rude not to say hello first. If you don't issue an EHLO or HELO first, we won't accept MAIL FROM or RCPT TO commands. Also, the EHLO or HELO must be accepted for further commands to function.
- Thou Shalt Not Forge Credentials
- The SMTP hello is "Hi, I'm Bob." not "Hello Jim nice to see you.". The HELO name or IP address should be your name or IP address, but it most definitely must not be our name or IP address.
- If Using IP Literals, Thou Shalt Use Correct Syntax
- SMTP requires IP literals be enclosed in brackets, like so: [192.168.51.12].
- Thou Should Not Use IP Literals
- Real mailservers have names. The only reason we don't reject IP literals outright is because the SMTP spec specifically disallows it.
- Thou Should Use a Real Hostname as the EHLO
- If you say "EHLO tom.your-domain.tld", then tom.your-domain.tld should exist and resolve to an IP address. Because if the host doesn't exist, how can it be talking to us?
- Thou Should Not Issue an SPF Reject All on the EHLO Name
- If you HELO as suzy.domain.tld, you should not have an SPF record of "v=spf1 -all" for suzy. We don't do a hard reject because SPF saying things about HELO names took us by surprise, so we feel for you if you missed it. We certainly did!
MAIL FROM
- Thou Should Use Valid Syntax
- In particular, note that SMTP does not allow for a space before or after the colon in "MAIL FROM:<address>".
- Thou Should Not Use Our Domain as the Sender
- Odds are, if you're claiming to send mail from somebody@mbmacorp.com (or any of the other domains we handle) you are lying. We know who we are, and you aren't it!
- Thine Domain Shall Exist
- If you send mail from bob@some-domain.tld, then some-domain.tld better exist. How are we supposed to reply if your domain doesn't exist?
- Thine Domain Should Have an MX Record
- Yes, SMTP allows for fallback to the A record, so it isn't strictly required, but come on, it's not that hard to add one MX record to your DNS config.
- If Thee Has an SPF Record, It Shall Allow Mail
- In other words, if your SPF record says "v=spf1 -all" (this domain never sends mail), we'll take you at your word and assume the mail to be a forgery.
RCPT TO
- Thou Should Use Valid Syntax
- In particular, note that SMTP does not allow for a space before or after the colon in "RCPT TO:<address>".
- Thou Shalt Send Us Only Our Own Mail
- Don't try to use us as an open relay. If you want to send mail to some.domain.we.do.not.handle, you can't send it through us.
DATA
- Thou Should Include Date and Message-Id Headers
- SMTP spec says "MUST" for Date header. So we're actually being overly lenient because we've seen some rather large companies fail to include it and we aren't big enough to mandate changes.
- Thou Should Not Forward Messages Marked as Spam
- If you think it's spam, why would we want it? Yeah, I'm looking at you, AOL, with your X-Spam-Flag: YES.
- Thou Shalt Not Send Viruses
- You might be able to sneak one past the virus scanner if you tried, but please don't. We don't like viruses.
- Thou Shalt Not Send Spam
- Spam, here, being defined as "stuff which scores above an arbitrary threshold in SpamAssassin". Spam which passes SA will obviously not be rejected. But, if your spam makes it into our inbox, we'll be very disappointed in you for spamming us. Please don't do it. It's not nice.