Leave the NS and SOA records alone.
When you delete a hosted zone and then put it back, you're not exactly putting it back. You're just creating one similar to (but not identical to) the original.
When you click on a domain in "Hosted Zones," you see 4 name servers assigned to the hosted zone by Route 53 on the far right side of the screen. These will also be the default values for the NS records, which should never¹ be edited.
Each time you create a hosted zone, these 4 will almost always be different -- meaning that your hosted zone now lives on 4 new, different authoritative name servers in Route 53.
But the Internet is still expecting the old 4 nameservers to have your records... which they don't.
You have to update the authoritative nameservers with your registrar. In this case, that's actually a different part of Route 53.
In the Route 53 console, click "Registered Domains."
Select your domain.
Choose "add/edit name servers."
Enter the correct values for the Route 53 name servers, which are the ones mentioned above, which you'll see when you click on the domain from the Hosted Zones page.
When transferring a domain's registration to Route 53 when a hosted zone for the domain is already present, live, and working in Route 53, don't delete the hosted zone. As part of the transfer, you want to select the option to continue using the "current" nameservers in this case, because they are already the correct values.
Same answer to a different question on Stack Overflow.
¹should never be edited unless you're doing some white label hackery -- but don't do that. As explained at the bottom of the linked page, white label name servers seem to represent a significant administrative burden if you want geographic or latency-based DNS responses to work as expected, which would include A-record aliases that point to CloudFront. Otherwise, the default values for NS and SOA in Route 53 are always already correct, and the problem is somewhere else.