The FQDN presented by the MTA to remote servers should match the server's internet FQDN; I'm surprised that hosts rejecting your mail before started accepting it when using
There are a few things that go into this, and what gets checked varies wildly from one mail server to another.
What you're likely running into is a check on the reverse-lookup (
PTR) DNS records for your IP:
- Some mail servers expect that a reverse lookup matches exactly to the FQDN you sent with your
- Some servers also expect that that FQDN resolves back to the IP address of your sending server.
- But, servers with that level of strictness are rare. More often, they will verify that your reverse entry (say,
mail1.mydomain.com) is a child of the domain you're attempting to send mail from (say,
So, if you're in a position to be able to control your reverse DNS (if it's not a commercial internet connection with a static address, you may not be) then get your PTR record set up, and match it to the forward DNS of the server that's sending.
The other aspect to this is the SPF record. Many mail servers will use this as an alternative to that reverse-lookup checking when it's available, or at least as an additional factor in the consideration of whether to drop a message. Tons of info here, the short version is you'll create a DNS record of type
TXT in your domain, which will contain something like this:
v=spf1 mx -all
which will allow the devices in your MX records to send, or this:
v=spf1 ip4:x.x.x.x -all
x.x.x.x is your server's public IP address. Even if you don't have the ability to work with your reverse entries, an SPF record should help a good amount.
On the subject of using your ISP's relayers, that's not terribly relevant when you're operating your own mail domain.. I don't think most ISP's relayers will accept mail that's not from their own domain in this day and age. To clarify, those would be from whoever is providing your internet connection, not DynDNS.