Never Mind. I figured it out. But I'm not going to just leave it at that, because it's important for me to help anyone else having the same problem. All I did was comment out "mynetworks = 220.127.116.11/24, 127.0.0.0/8", and change "inet_interfaces" to "all". The problem was staring me right in the face, not even two feet in front ...
As Email Marketing continues to grow it's important to ensure all of your emails are properly authenticated with SPF, DKIM, DMARC, and eventually BIMI.
You should start by auditing all of the tools and applications that you use to send emails from your domain. Then be sure to setup SPF and DKIM for each tool or application so its properly authenticated.
This is an answer, hopefully:
I tried to compile OpenDKIM from source, but that got nowhere: the PEM error went away, but the filter failed in other ways fatal to its use.
So I got "dk-filter", which latest version is obsolete, since it uses SHA1 only, calls "relaxed" "nofws", only handles one canonicalization (relaxed or simple,...
I couldn't solve this issue using app password. However I solved it in other way by following steps.
Disabled two factor authentication
Enabled less secure app
Logged in to the gmail account from a browser in the server.
Changed the app password to account password in the .env file
Now it works that way. I even checked this after signing out from the gmail ...
According to your description, this issue occurs randomly when senders who locate in company B send mails to company A?
Does this issue occur to another recipients who outside company A?
What is the version of your outlook client in company A?
To narrow down this issue, run outlook in safe mode and check if this issue is related with add-ins, then see if ...
Your description of your use case is not complete enough. But if your goal is to send email from *@example.com from any of those servers, then the SPF ptr mechanism is designed precisely for this use case.
You would set up proper reverse DNS 18.104.22.168 → sub1.example.com → 22.214.171.124, for each of the subdomain servers.
Then you would install the following SPF ...
It depends a bit on what your aims are, and which problems you into.
There are several SPF mechanisms to match classes of hosts without enumerating all hosts directly in the SPF record, for example:
the ip4 mechanism and equivalent ip6 mechanism to match subnets when all your servers belong to one or more IP-address ranges that are exclusively yours:
I have verified that the key is correct (private<==>public) and accessible by two different means. I am not using KeyTable.
My /etc/opendkim.conf (actual domain disguised) is:
If it's a small business I would tend to cut over directly by changing the MX after prefeeding everyone mailbox PST content to O365 as you have less risk to loose a email in transit.
At the MX cut the Outlook client will stop getting new emails, but the users can use their O365 online via the Microsoft webpage to see their new emails for the time you connect ...
If you don't mind having all emails sent from msmtp-mta with the same "From" header you may use the following configuration. The aliases file is useful so that local recipients (ex: root) work
# or from %U@domain.com
Most correct way to do this nowadays is to create an account on the proper mail service which is fully configured to serve example.com. (Of course, this could be your own server, this doesn't matter.) Then, on your null host, you only configure mail server as a smart host, with SASL authentication.
While it is perfectly possible to set up Postfix like this (...
Agree with what joeqwerty has replied above, you just migrate mailbox's content to your new exchange not the actual mailbox. If you migrate content of mailbox to the new exchange server, you could create a new inbox rule to route the message from the external mailbox to your new exchange mailbox. A inbox rule looks like below:
At the end of the day, you're not migrating the actual mailbox, you're migrating the content of the mailbox. For that you can use any one of a number of third party tools, or simply export the current mailbox to a PST file and import it into the new mailbox.