...
I don't see a need for an SPF record to *receive* mail.
Me neither. Perhaps it was not clear enough what I said, so I try again. The TXT-SPF record may be the only entry related to mail-sending in the DNS zone of our mail service. We could even omit this, however, I found out, that big mail providers like gmail use the TXT-SPF entry of your zone for sender validation. For example, I got a backup gmail account, and Test-E-mails to this one without SPF (Subject = Test, and body = Test) land directly into the spam box. Test-E-Mails without SPF and containing some expressive phrases have a bigger chance to go into the inbox, yet not 100 %. Mails with a SPF entry in my DNS zone come through by 100 %.
Now, chances are that one of your peers got a gmail account, and it is usually much quicker to set up the SPF for your zone compared to explain to all of your peers that gmail is evil and wait until they switched to another service (hopefully not hotmail). Your customers, the future girl friend, etc. won't respond in that way, but instead would respond to somebody else who is able to send mails to their gmail account.
An MX pointing to a dynamic IP address will probably work quite well, but there are (minor) risks:
Actually it works very well, and the benefits outweigh the risks.
- If your MX isn't reachable (either the line is down or the DNS update hasn't reached the sender yet), a sender can't connect to it. This should be treated as a temporary error and the sender should try again later, but I wouldn't count on every sender behaving correctly here. If it's treated as a permanent error instead, some mails might not arrive
No higher risk than is imposed anyway to my mail service because of grey listing. My policy is, not to accept mails from misbehaving senders.
- Worse (and, of course, much less probable) would be a scenario where an SMTP service is actually reachable on the IP address you owned earlier, and this service accepts unencrypted connections, and the sender accepts that as well. In that case, a mail addressed for your domain could end up on an unrelated system.
Therefore I'd argue the best solution is using a server with static addresses for receiving as well -- this server *could* just act as a gateway, like in my setup
I thought about it, however my risk assessment told me that this one is negligible. My dynamic IP changes only on power outages for more than 15 min, which rarely happens. Nobody can count on this. If somebody else got by accident a mail service running on a dynamic IP in my region, which is not secured against relaying arbitrary mails to local receivers, then he anyway won't find the message to me in the thousands of spam mails in his box. Or even worse, if that service is not secured against relaying to a wider audience in the internet, then the message would finally reach me
The benefits are:
- this is the most cost-effective way of hosting the own mail service that I can think of:
- the SMTP receiver (incoming mails) is listening on my home server and without extra costs on a connection which is payed anyway.
- the SMTP relay (outgoing mails) is part of the domain hosting package at quite a low cost.
- its is quite easy to obtain a let's encrypt certificate for an IP of a server which is under your control and where you can run the certbot, e.g. no DNS fiddling before and after is necessary.
- all local transactional mails (intra domain) are truly end-to-end encrypted even though only transport encryption is involved.
- all mails are stored on your server in-house, and we may securely use IMAP instead of POP3+Removing mails from the server.
- most incoming business e-mails are secured from eavesdropping as well, because bigger companies use their own outgoing mail services and these do contact directly my incoming mail service (I can see this in the server log).
- In my case, the only point left of possible interception is the mail relay at the domain hosting service. I know this and I act accordingly.
In 2018, I wrote a BLog post about my setup with all the details, including webmail:
Home Mail Server with TLS and non-Plaintext Authentication