I have a wrapper for PHP & Apache and checked whether it was from a form or script on a website, but it wasn't: it was not being logged. And I checked HTTP logs for possible logins/post from the specific IP address, but nothing comes up.

Please see to the right on this screen, in de Related section your question has been asked many times, with many good replies you can try first. After trying those tactics, update your question here with your findings.
– JayMcTeeAug 1 '17 at 9:21

1

It looks like the message is coming in from a remote client (unless 103.214.xxx.xx belongs to you?). Can you post the xxx_restrictions settings from your main.cf configuration file.
– USD MattAug 1 '17 at 9:22

1 Answer
1

For a start the restrictions should be comma separated, which is probably the main problem.

Also I generally prefer to end with an explicit reject rather than permit. Anything that doesn't happen to match a deny rule is going to end up permitted. (Your reject_unauth_destination should stop any mail to domains you don't specifically allow relay to, but still it's better to just reject by default)

Edit to extend answer:
Based on the logs, the client is connecting remotely and sending an email from the mydomain.com domain to gmail.com successfully, so once you've sorted out the format of the restrictions you just need to identify why it's getting a permit action.

I personally would go with a configuration similar to the following.
Note that I don't know your full environment or configuration so I provide no guarantee that you can just use this without modification or full testing (as I haven't tested it at all either). It's entirely possible something else in your config is broken and causing the original issue