When attackers copy the verify footer

The second question we get on almost every call, right after the DMARC one, is "won't attackers just copy the footer?" Yes. They will, and Fromenance communication provenance is built on the assumption that they will. A copied footer says "forward this to verify@bank.com", which is an instruction to deliver the lure straight to your fraud team, where it fails, because the code belongs to a registration and a recipient the attacker does not control.

Why the footer gets copied

The footer is the most trustworthy looking sentence in a real message: "Not sure this email is from JT Merlin Bank? Forward it to verify@jtmerlin.com or enter code KX73-PQ9G at jtmerlin.com/verify." A lure that includes it looks more legitimate to a customer, so copying it is the rational move. It is also the last thing the attacker wants the customer to actually do.

What happens when they do

The verify code belongs to one registration, which carries one recipient hash and one content fingerprint. When a copied footer arrives on a lure:

1. The code resolves to the original registration. It is a real code.
2. We compare the recipient. If the lure went to a different person, the hash of their address does not match the registration. Not verified, flagged as a replay.
3. We compare the content. If the lure went to the same person (the attacker harvested the original), the fingerprint of the lure is far from the fingerprint of the real message. Not verified, flagged as a replay.

Either way the customer hears "no registered communication matches this message", and your fraud team gets a submission marked replay with high priority, carrying the lure's domains, links, and phone numbers as indicators, and the registered template it was imitating.

What the attacker learns

That codes belong to a recipient and to a message, so copying one does not work. The likely adaptations are to make up codes or to drop the footer.

A made up code has to pass the checksum to be extracted at all, and a code that passes the checksum but leads nowhere is treated as no code: the submission falls through to the recipient plus fingerprint rule, which the lure also fails. Dropping the footer removes the thing that made the lure look legitimate in the first place, and a customer who has learned to look for it notices.

What you learn

Every replay tells you which template is being imitated and how quickly. Replay counts show up on your overview, replay events go out as submission.replay_detected webhooks to your SIEM, and the imitated template guess on each Not verified submission tells your analyst which stream to watch.

The one thing to get right

None of this works unless the code belongs to the recipient. A footer with a static per template code proves only that someone once had a real message from that template. We issue one code per message, computed at registration with the recipient hash, and the reserve flow does the same for ESPs that cannot give us the body. The static code is a stopgap for journal fed vendor streams, and we document it as one.

Definitions for replay attack and footer replay are in the glossary. The full rule table is on how it works.