Final Reminder, Fake Invoice: How a Same-Day Reply-To Domain Silently Rerouted Payments Through a Compromised Sender

The subject line read: "4/12 FINAL REMINDER: Unsettled Invoice." The body threatened collection agency referral, a 15 percent penalty fee, and a deadline of "close of business Friday." It was signed by a named accounts receivable contact at a digital marketing firm persona. There was no invoice amount. There was no attachment, despite the text claiming one.

There was a Reply-To field. It pointed to a domain registered the same day the message was sent.

Any finance staffer who replied to ask about the invoice, dispute the amount, or request the attachment would have sent their response directly to attacker-controlled infrastructure. That is the entire mechanism.

The authenticated from: an aged domain, a fresh motive

The message arrived from a domain that had been operating legitimately since 2011. SendGrid delivered it. SPF passed, DKIM passed, DMARC passed. On authentication signals alone, this is a clean message from an established sender using a known commercial delivery platform.

The analysis indicates the sending domain was compromised or its SendGrid credentials were misused. This pattern characterizes business email compromise at a more sophisticated level than a throwaway account: the attacker is borrowing the age and reputation of a real domain to survive spam filters, while keeping the reply path fully under their control. A domain that has been sending legitimate mail for over a decade carries accumulated reputation that a same-day registration never could.

ESP abuse of platforms like SendGrid amplifies this. Bulk delivery platforms maintain strong infrastructure reputations; messages routed through them arrive with an implicit deliverability endorsement. Content and sender-reputation filters have less to fault when they see a known commercial IP, a valid DKIM signature, and an aged domain in the From field. The attacker assembled exactly that combination.

The Reply-To field as the silent harvest mechanism

Recipients almost never see the Reply-To header. Most mail clients display the From address and hide the Reply-To entirely until the reply window opens, at which point the pre-populated destination usually goes unexamined. The attacker exploits that gap.

The From header displayed the digital marketing firm persona. The Reply-To header pointed to receivables[@]bbcreativesllc[.]com. That domain, bbcreativesllc[.]com, was registered on the same day the message was sent, through a privacy protection service. It was completely fresh: no prior mail history, no web presence, nothing that would survive a reputation lookup.

Registering a domain the day of the send is a deliberate operational choice. The domain exists only for this campaign. It is sacrificial: if it gets flagged, the attacker moves to another. Its youth is not a problem for the attacker because it never appears in the From field where aging matters for delivery.

The detection signal is precisely the mismatch: the From domain is over a decade old; the Reply-To domain is hours old. Legitimate accounts receivable operations do not route replies through a domain created that morning.

A fabricated urgency loop with no verifiable invoice

The body was constructed to generate action before verification. Collection threat, 15 percent penalty, a named contact, a deadline expressed as a day of the week rather than a calendar date. None of the details a finance team would need to verify the invoice were present: no amount, no invoice date, no purchase order reference, no customer billing account number. The only identifier was a fabricated invoice reference.

The attachment claim in the body was false. What the message actually delivered was a SendGrid open-tracking pixel at u5855772.ct.sendgrid[.]net, confirming message delivery and open status back to the attacker's SendGrid account. The pixel is operationally useful: it tells the attacker which targets opened the message and are therefore active, worth following up with a second-stage lure or a direct reply if the initial message did not generate a response.

This is invoice fraud built around the reply path rather than a link or attachment. There is no credential-harvesting form to detonate. There is no malicious file to sandbox. The payload is the pressure to respond before thinking, and the destination of that response.

The detection gap: clean delivery, invisible redirect

The profile of this message as it arrives through standard defenses: authenticated From domain with ten-plus years of legitimate history, known commercial delivery infrastructure, no malicious URLs beyond a benign tracking pixel, no attachment at all. Signature-based and reputation-based controls find little to fault.

The tell is behavioral. The Reply-To domain did not exist until the day of send. The sender is external and the message claims an existing invoice relationship the recipient may have no record of. The body invokes urgency without providing any verifiable transaction details. Those three signals together form a consistent pattern whether or not any individual technical control fires.

Indicators of compromise

What actually caught it

Authentication said the message was clean. The delivery infrastructure was legitimate. The flagging came from the operational fingerprint: a same-day Reply-To domain that could not survive a WHOIS lookup, a body whose urgency was inversely proportional to its verifiable detail, and the absence of any actual invoice.

Verizon's 2026 Data Breach Investigations Report attributes 62 percent of breaches to the human element; FBI IC3 2024 data ranks BEC among the highest-dollar fraud categories. CISA's guidance on phishing centers on verification through known channels. The practical defense here is exactly that: finance teams should never reply to an invoice dispute through the email thread. Verify the vendor's contact information independently, confirm the invoice exists in your accounts payable system, and call the number already on file. The attacker's Reply-To field is invisible until you use it.

See Your Risk: Calculate how many threats your SEG is missing

The invoice did not exist. The attachment did not exist. The collection threat did not exist. What existed was a fresh domain, one day old, waiting for a reply.