The ideal situation would be to have your queue store its messages indefinitely, provide you with message position as it delivers messages to you, and allow you to resume your subscription from a certain position (instead of only from now forward). That way, your subscriber can keep track of the last message it successfully processed and start from that position forward when it restarts. EventStore does this. It is an append-only database which also behaves as a queue that you can subscribe to.
Assuming your current queue only gives subscribers messages from now forward, you will have to store the messages as they come in (file or database or whatever). As you successfully send messages to 3rd parties, you will have to record the last successful one (per 3rd party) so you can resume from there if it gets too far behind or crashes. Periodically, I assume you will want to delete old messages which all 3rd parties have processed.
You can either save the checkpoint (id of last successfully processed message) before or after delivering the message.
Saving checkpoint before delivery is called At Most Once Delivery, because it's possible that the message never gets delivered. For example: Checkpoint gets saved, but before delivery the computer crashes. Upon reboot, the loaded checkpoint says that message was already processed and loads next one.
Saving checkpoint after delivery is called At Least Once Delivery, because it's possible to deliver the message multiple times. For example: Message is sent, but computer crashes before checkpoint is saved. Upon reboot, checkpoint is pointing at same message that was sent, which will get resent again.
At Least Once Delivery (saving checkpoint after successful delivery) is safer so long as messages do not induce side effects (i.e. they are idempotent). For instance, if the message is CountIncreasedBy:5, then it has a side effect because it's new value depends on the old value, and processing this message more than once is going to skew the value on the receiver. However, if the message says NewCountSetTo:37, then you can process that any number of times in a row and it will always have the same effect.
However, with "at least once" you also have to watch for poison messages. These are messages which always crash when they are attempted to be delivered, thus you are not able to proceed any further. They will get retried infinitely unless you put something in place to watch for that.
Also note that if there are no circumstances in which the 3rd parties can catch up (i.e. it's not just burst traffic, but average traffic that overwhelms the 3rd party), then you are going to run into the same overflow problem on your hard drive. At that point, you will have to use offline methods or just skip messages once processing gets too far behind.