Pela doc, o waitForEmail com filtro, mais o waitForRegexMatch pro código, já cobrem o que eu ia sugerir.

Complementando o item 4 do jeffwudev: em provedor transacional nem precisa ser repetido, um único 550 5.1.1 já costuma contar como hard bounce e mandar o endereço pra lista de supressão, que em geral não expira sozinha. O provedor passa a descartar os envios antes de chegarem no relay. Com inbox temporária isso pouco importa, mas com profilePath persistente basta uma rodada em que o e-mail seja disparado com o cliente desconectado (fila atrasada, close() cedo, job cancelado) pra queimar o endereço no staging. O teste passa a estourar timeout, e ninguém pensa em olhar o painel de supressão.

Outro detalhe: a doc pede pra sempre passar timeout, mas como a espera não tem limite por padrão, é só alguém esquecer, em pytest ou JUnit (sem timeout por teste por padrão), pra um filtro errado segurar o job de CI até o timeout do runner. Um default razoável e um erro de timeout listando o que chegou e não bateu no filtro ajudariam no debug.

Uma dúvida: o Cloudflare Email Routing já grava SPF/DKIM num ARC-Authentication-Results; esse header chega intacto no getRawEmail pra dar assert no teste, ou o relay mexe nos headers?