emailauthenticationsendgridinbound

How to authenticate Inbound Mail? With SendGrid specifically?


I created an application which uses SendGrid's Inbound Parse Webhook. Whenever someone emails "whatever@mydomain.com", the email goes to SendGrid, and then SendGrid hits our server with a POST containing the email's contents. We can then feed that email data back into our main application.

I have it all working. But now I do not know how I am supposed to authenticate the messages SendGrid posts to our server. Does anyone know the best course of action for doing this? Verifying that our inbound emails actually come from authorized users of our main application?

Obviously we can check the "From" address in the headers, but I've read that these can be completely spoofed. Apparently "dkim" and "spf", two attributes of the incoming mail from SendGrid, have something to do with authorization. But i cannot find anything in the documentation, or really anywhere else for that matter, that tells me how I should be consuming these "dkim" and "spf" fields to verify message authenticity.

If anyone has any help, general, specific, or otherwise.. It would be greatly appreciated. Thanks in advance.


Solution

  • Well. Since this doesn't seem to be getting a lot of traction I thought I'd post my own janky-ass solution to the problem, on the off chance that anyone else runs across this issue in the future.

    Disclaimer: this could be total garbage nonsense. But it appears to be working all right.

    Basically I ended up taking some critical contextual information about the original message that initiated the inbound email. We encode that information in the local-part of the "Reply To" address that we set up with the SendGridMessage. Then I encrypt the encoded local-part.

    When SendGrid POSTs to our server with the inbound email, we decrypt the "TO" local-part and validate the result. If it decrypts successfully, we check the "FROM", and verify that they are an actual authorized user of our main application. THEN, we verify that THAT user in question has the correct permissions to edit the information associated with the original encoded local-part of the "Reply To".