Context.
I have multiple domains web services being hosted on a Digital Ocean droplet (Ubuntu and Nginx in stack). Apparently, DO automatically sets up a PTR record. However, when I query
host
[...] not found: 3(NXDOMAIN)
The droplet is using postfix, configured as where inet_interfaces = all inet_protocols=ipv4, while mydestination includes the hosted web services domains (both with and without www prefix). These domains issue e-mails via sendmail and a host defined as scheduler.sending.ws
DNS and mail service is run through a second provider (which is NOT the registrar of record for the second level domain). I noticed first of all that an A record is pointing to the proper ip address but with a typo schedule.sending.ws That can be fixed, although I am not certain this is entirely pertinent.
The MX record properly points to the second provider mail.sending.ws
There are also two TXT records for @ and admin pointing to v=spf1 a mx ptr include:someserver.net ~all.
This leads to mails being generated with the following header with a random domain defined in mydestination of the postfix main.cf file:
Received: from www.other.ws ([IP_ADDRESS]:46818)
Thus, two different issuing references, a situation which can easily lead to be flagged as spam.
please excuse my utter confusion and the breaking protocol of asking multiple questions
My present assumption is that:
a) does a new TXT DNS entry need to be set for the issuing domain, such as: v=spf1 a mx include:scheduler.sending.ws include:someserver.net ~all ?
b) if a) is correct, naturally the A record needs to be corrected
c) the mismatch in the headers still needs to be resolved. But this must certainly be specified by the application (and thus specific domain) preparing the e-mail with one of the postfix-defined domains... will postfix play along?
is any data missing to properly address this issue?
No comments:
Post a Comment