If they want
www.theirsite.com to appear in the URL, in the browser address bar, then the server which answers connections for
www.theirsite.com must serve something for
/new-page, there is no way around that to just completely offload everything to somewhere else - not by subdomains or DNS A record trickery(*).
But there is a very easy way not mentioned so far -
/new-page serves a placeholder page with an
iframe element, and that tells the browser to load content from your server by some other name - a subdomain or any other name. This would show their name in the URL bar, and have the browser make another connection to load the content from your server. You could make a subdomain of their site, and have your server answer to that name, so it looks like a related server.
It would be obvious to anyone who looked at the source code that it was loading from somewhere else, but unless there is some active logon part to the site, security which needs everything on exactly the same name, or HTTPS certificates involved, it would work OK, and to any normal viewing or ordinary user it would show as their site in the URL bar.
The way to integrate it so it looks like part of their site, but is hosted by you, is with a reverse-proxy, as @sam_pan_mariusz suggests.
This is where their webserver answers the connection, their webserver loads the content from your server, and their webserver serves the content back to the browser. It would need configuration on their server to do it, and it would add more work on their server, but to the outside world
/new-page is roughly indistinguishable from any other content on the site.
(*) There is no way to point an A record to a specific page, 'A records' are in DNS and are looked up very early, and URL paths happen in HTTP requests much later, after the connection is open; they are very different layers and they don't mix easily.