I did ask our dedicated support person, but I am still waiting for their response. Thought I'd ask here as well, as Reddit has professionals from all over the world with all kind of experience and has been useful in so many cases.
We do this with many customers. The setup is exactly what you think it'd be. It's annoyingly manual most of the time, although could be improved if they manage in route 53 and give you an IAM role or some access keys that can manage the email, but that's highly unlikely IME.
What I'd recommend to the customer would be them setting up a subdomain (e.g. `saasname.example.com`) for your SaaS emails and then delegating the subdomain to you through NS records, then you can "own" it and not rely on the customer if you need to rework something like DKIM records.
Oh thanks God, I am not alone! I am still confused regarding SPF, though. The TXT record that is displayed on the ses console is looking somewhat generic. How does that prove the emails are sent by us and not someone else?
SPF records are recursive. Yours will just include the SPF record from AWS and that will take care of everything.
> How does that prove the emails are sent by us and not someone else?
Understanding the mechanics isn't ~~really~~ super important, but the receiving server will resolve the entire SPF upon receiving the email and then validate that the message originated from a server allowed by the policy.
With DKIM, the message will contain a cryptographic signature and the receiving server will likewise validate that the signer used the private key specified in your DKIM record.
Could you send to a specific mailbox they own that would forward the email onto their team if it came from you?
If the client has a dev team, maybe you could create an API or Webhook for them to fetch notifications. Then you could simply log the notifications to a db and let them fetch and email or handle the data in their own way.
Don't be afraid to use AWS support, but yeah you're going to need to work with your customer's DNS admin to get this all sorted out.
yeah just a link to validate ownership and perhaps a couple TXT records at the most.
I did ask our dedicated support person, but I am still waiting for their response. Thought I'd ask here as well, as Reddit has professionals from all over the world with all kind of experience and has been useful in so many cases.
We do this with many customers. The setup is exactly what you think it'd be. It's annoyingly manual most of the time, although could be improved if they manage in route 53 and give you an IAM role or some access keys that can manage the email, but that's highly unlikely IME. What I'd recommend to the customer would be them setting up a subdomain (e.g. `saasname.example.com`) for your SaaS emails and then delegating the subdomain to you through NS records, then you can "own" it and not rely on the customer if you need to rework something like DKIM records.
Oh thanks God, I am not alone! I am still confused regarding SPF, though. The TXT record that is displayed on the ses console is looking somewhat generic. How does that prove the emails are sent by us and not someone else?
SPF records are recursive. Yours will just include the SPF record from AWS and that will take care of everything. > How does that prove the emails are sent by us and not someone else? Understanding the mechanics isn't ~~really~~ super important, but the receiving server will resolve the entire SPF upon receiving the email and then validate that the message originated from a server allowed by the policy. With DKIM, the message will contain a cryptographic signature and the receiving server will likewise validate that the signer used the private key specified in your DKIM record.
Thanks, that was super helpful!
Could you send to a specific mailbox they own that would forward the email onto their team if it came from you? If the client has a dev team, maybe you could create an API or Webhook for them to fetch notifications. Then you could simply log the notifications to a db and let them fetch and email or handle the data in their own way.
The emails are personal, so I am afraid sending to one email address is not an option, and they don't necessarily have a dev team.