I’m trying to have all domains send through peerlesswebhositing.com because that is where the cert is.
You’ve still got some wrongthink about how SPF works (and you’re not alone…it’s never explained very well…it took me a good while of coming back to it every few days to grasp just what the heck they were trying to say in the specification).
You cert doesn’t matter in this stage of the transfer–nobody uses SMTPS for MTA-to-MTA transmission (no passwords are used), and even if they did, that’s not what SPF is saying.
SPF is set per-domain, and it says “This is a server that I allow to send mail on my behalf.” The “server” in this message is an IP address. No hostnames involved, and your clients (mail clients, I mean, like Thunderbird, Usermin and Squirrelmail) don’t know or care anything about it.
So, for example, the SPF record on Virtualmin.com is:
virtualmin.com. IN TXT "v=spf1 a mx a:virtualmin.com ip4:70.86.4.226 ?all"
The domain is irrelevant from the angle you’re trying to come at it from. SPF is looked up by domain, and returns an IP (and some other crap).
In short, you don’t need to include any extraneous domains in each SPF record (peerlesswebhosting.com is extraneous in this case), but you need one for every domain that you want your server to send mail for.
Not having a slave would not lead to the original issue reported. If you’ve already been delegated authority for your IP, you’ll need to setup a reverse zone for it. Webmin can help there…it’s not a virtual hosting issue, so Virtualmin doesn’t try to address the issue.
Just to be clear: We’re talking about two issues. Not having reverse resolution is a bounceable offense on many mail servers. Not having correct SPF records is bounceable on some mail servers (particularly Yahoo Mail).
So, the most pressing issue is getting reverse resolution working. Your IP doesn’t appear to be delegated to your nameserver, so your ISP/host will have to provide reverse resolution for you (or delegate it). The name it reverse resolves to DOES NOT MATTER. This is another point that folks want to come at from the wrong angle. As long as reverse resolution works and the name that it returns also resolves back to the IP, you will be fine (unless you force your MTA to claim it isn’t that name).
Our mail server is “e2.4.5646.static.theplanet.com.” Because our hosting provider does the reverse resolution for us. Doesn’t matter that it isn’t “virtualmin.com” or “mail.virtualmin.com”. It resolves when you lookup the name of 70.86.4.226, and when you lookup the hostname and resolves back to that IP. This makes everybody happy. It means I’m not lying about my hostname when I connect somewhere–it provides some level of assurance that I’m not pretending to be someone I’m not. Note that none of these things has any relation at all to the domains on the mail I’m sending. That’s at a whole other layer of processing, and will never cause a bounce at this layer (SPF does care what domain is on the mail, but only from the perspective of asking the DNS server that is authoritative for that domain, “Hey, what mail servers do you allow to send mail on your behalf?” Again it doesn’t care what those mail servers are named…just so long as they are allowed to send mail for the domain in question, according to the DNS server authoritative for that domain).
In no case does the name of the server matter, as long as resolution works both ways.