The Silent Read: VERP Bounce Sender and a Personal Gmail Read-Receipt Channel in a DMV Impersonation

The attacker did not need the recipient to click anything. They needed the recipient to open the email.

An email claiming to be from a DMV Account Management Unit, carrying invoice urgency language and a fabricated payment reference, was sent through Amazon SES with full SPF, DKIM, and DMARC compliance. The message's authentication record was clean. But two headers in the message routed the most valuable confirmation back to the attacker before any user action occurred: both Disposition-Notification-To and Return-Receipt-To pointed to a personal Gmail address that had no connection to the claimed sender.

Any email client that honors read-receipt requests (a significant proportion of corporate clients in default configurations) sends a notification to that Gmail address the moment the recipient opens the message. The notification contains no payload and requires nothing from the recipient. From the recipient's perspective, nothing happened. From the attacker's, a valid, monitored mailbox was just confirmed.

The VERP Encoding and What the Bounce Address Carries

The From header in this message was not a standard business address:

`` bounces+24148782-6a6c-thevistas.manager=mebmgmt.com@lucadarmento[.]com ``

This is a VERP-encoded address. VERP (Variable Envelope Return Path) embeds the intended recipient's address inside the bounce address using a structured encoding. Legitimate mailing-list systems use VERP to correlate delivery failures to specific recipients automatically: when a bounce arrives at the bounces+ address, the system parses the recipient identifier from the local-part and marks that address as undeliverable.

Attackers use the same mechanism for the opposite purpose: as confirmation that an address is alive. If no bounce returns for a given VERP-encoded send, the address successfully received the message. Combined with the Gmail read-receipt channel, this email has two independent signals that confirm mailbox activity: one passive (no bounce = delivery success), one active (client honors read-receipt header = open confirmed).

MITRE ATT&CK T1598 covers phishing for information, specifically reconnaissance phishing that collects intelligence about targets rather than immediately delivering a payload. T1566.002 applies to the link-based phishing vector referenced in the body. T1656 (impersonation) captures the DMV identity claim.

The sending domain for the VERP address, lucadarmento[.]com, returned no WHOIS data, and the registration record could not be confirmed. Amazon SES was the delivery infrastructure: 54.240.8.33, resolving to a8-33.smtp-out.amazonses.com, is a known SES outbound IP. Any SES account holder can obtain DKIM signing for a registered domain and produce a message that passes all three authentication checks. The absence of WHOIS data for the sending domain and the bounce-formatted address structure are the available signals of malicious intent in the authentication layer.

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

The Read-Receipt Exfiltration Channel

RFC 3798 defines the Message Disposition Notification protocol. An email with a Disposition-Notification-To header requests that the receiving mail client send a brief, automated notification to the specified address when the message is opened. The notification is typically invisible to the recipient: no dialog, no confirmation, no opt-in at the moment of open.

In this message, both Disposition-Notification-To and Return-Receipt-To were set to barnesashely5[@]gmail[.]com, a personal Gmail address with no relationship to the claimed DMV sender or any legitimate business entity. The moment a compliant mail client opened this message and honored the header, the attacker's Gmail account received confirmation that the address was active and the email had been read.

This is social engineering at the infrastructure layer: not persuading a person to act, but manipulating protocol compliance to extract intelligence without human involvement. The Gmail address is the exfiltration destination. The email client is the unwitting sender. The recipient is the subject being confirmed.

DMV Impersonation as a Pretext Layer

The message body claimed origin from a "DMV Account Management Unit" and referenced a named California DMV contact address (requesterportal@dmv[.]ca[.]gov). The payment reference used today's date and a random reference string. The urgency framing was explicit: an eCheck batch had been processed and required review.

The footer contradicted the header entirely. Rather than displaying DMV branding, the signature block referenced a California equipment rental company, a branding mismatch that places two incompatible organizational identities in the same message. This inconsistency is consistent with a template-assembled pretexting operation. The body was configured with DMV impersonation content, but the footer was not updated from a prior template use.

For impersonation campaigns targeting payment functions, government agency pretexts are effective because recipients are conditioned to treat official agency communications as high-priority. A DMV Account Management Unit notice referencing a specific payment and today's date creates cognitive pressure to resolve the issue before it escalates. The branding mismatch is the tell, but recipients who open the message for five seconds and scroll to the CTA may never reach the footer.

The linked content in the body referenced an invoice or report view. The links captured in analysis all resolved to Microsoft support pages, guidance links injected by the mail client's external-sender banner rather than attacker infrastructure. The actual CTA link present in the body HTML was not captured in the recorded link set, leaving the payload destination unconfirmed.

Indicators of Compromise