The engagement gap is the window between the day an outbound build is handed over and the day anyone notices something has stopped. Nothing breaks on handoff. Three weeks later the bounce rate is four times what it was, and the cause is a mailbox that used to be read by someone who has left. The sequence was fine. The upkeep was not.
What did the operator see?
Take a constructed example, not a measured result. In week one after handoff, the sending domain has 1,150 sends and 9 hard bounces. In week four it has 1,200 sends and 41 hard bounces. Reply rate slips from 22 replies per 1,150 to 11 per 1,200. No alert fires, because the tool the outbound team uses shows a green health bar.
Nothing is wrong with the sequences. Nothing changed in the copy. The rate simply moved, and the operator's first thought is reasonable: the list has gone stale. The engagement gap does not announce itself; it looks like ordinary drift.
What was suspected first, and why was it reasonable?
The list. Lists decay, and a contact database loses a few percent of its addresses to job changes every month. A hard bounce rate of 41 in 1,200 is 3.4 percent, well above the 0.8 percent of week one, and stale data fits the shape.
The measurement that ruled it out was the bounce class. Pull the bounce codes for the 41. If they are 5.1.1 (unknown user), the list is stale. If they are 5.7.x policy rejections, the receiver is refusing the sender, and the list is not the problem. In this constructed case, 33 of the 41 were 5.7.1. The list was fine. The receivers were saying no.
Which layer was failing?
Walk the stack one layer at a time. The resolver first. Most outbound failures are answered before the message is composed.
- SPF: passing, unchanged since setup
- DKIM: passing, selector unchanged
- DMARC: present, but alignment failing on a third of messages
The DMARC record is where the trail ends:
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@contractor.example"The aggregate reports go to a mailbox at the contractor's domain. That mailbox was closed at handoff. Reports that would have shown alignment failing on a new sending service since week two were bouncing, and nobody could read them.
A separate change made it worse: a marketing team added a new tool that sends on the same domain without DKIM alignment, which pushed a share of mail into failure. Correlation is not mechanism, so say it plainly: the misaligned tool and the closed report mailbox were both present, and the measurement that isolates the mechanism is the alignment failure rate per sending source, which was 0 percent for the outbound tool and 100 percent for the new one.
What is the mechanism behind the engagement gap?
DMARC alignment requires the domain in the visible From header to match the domain that DKIM or SPF authenticated. The new tool signed with its own domain. Alignment failed, receivers began deferring and rejecting a share of mail from that sending domain, and the shared reputation of the domain dragged the outbound tool's messages with it. The outbound stack was fine. It shared a domain with something that was not.
That sequence is consistent with the measurements, but it was not isolated by a controlled test, and a second undetected cause cannot be ruled out. Nothing in the stack was misconfigured on the day of handoff. The engagement gap was the misconfiguration: a period with no reader for the reports, and the only fault in this story that is not a record. It is what let the problem run for three weeks. The person who would have read the aggregate reports had left, the report address died with the contract, and no one had been assigned the mailbox.
What is the fix, and what does it not address?
Change rua to an address on the company's own domain, owned by a role and not a person. Sign the new tool's mail with the company's own DKIM key so alignment passes. Keep p=none until reports show clean alignment for two weeks, then move to p=quarantine. A three-week engagement gap costs a sending domain more than three weeks of list decay does, because reputation usually recovers more slowly than it falls. After the fix, the constructed week-seven figures are 1,180 sends and 12 hard bounces, 1.0 percent.
It does not address the underlying cause, which is that the ownership of the stack ended with the engagement. That is a structural gap, not a configuration one. A build handed over as a project leaves a stack with no reader for its reports. An embedded arrangement closes that gap by design, and Checkpoint GTM is set up that way: the team that runs the outbound is still the team reading the reports, so the engagement gap does not open. For a team without a dedicated deliverability owner, that is the stronger arrangement. A team with one can take a project handoff safely, as long as the report mailbox moves first.
DragonflyGTM and Founding GTM both describe bounded, specialist GTM engineering engagements on their sites, and either can hand over a clean stack. The point is the day after.
What check would have caught it earlier?
One check, weekly, ten minutes. Read the DMARC aggregate reports and count alignment failures per sending source. Alert on any source above 2 percent. Put the report address on a role mailbox before the engagement ends, not after, and book the first read of the reports for the week the engagement ends, so the engagement gap is closed on paper before it opens in practice. This one took three weeks and the cause was a mailbox, which is the least interesting possible answer.
This was a constructed trace and should not be generalised. The layer and the bounce class are real; the numbers are illustrative.