An Employment Verification Request That Passed DMARC REJECT, Then Sent Replies to Someone Else

The email said "Employment Verification Request." The sender was verifications@international.informdata[.]com, a domain belonging to a real background check company. SPF passed. DKIM passed. DMARC passed, with the strictest possible enforcement policy: p=REJECT sp=REJECT. Every authentication signal said this message was legitimate.

It was not. The Reply-To pointed to support@verifying[.]you. The "Review Employment" button linked to verify.zippedscript[.]com. Both were attacker-controlled domains with no connection to InformData.

In June 2026, IRONSCALES flagged this phishing attack targeting an employee at a sports data technology company. A colleague at the same organization reported the email, and one mailbox was quarantined.

Why DMARC REJECT Did Not Help

DMARC at p=REJECT is the gold standard for email authentication enforcement. It instructs receiving mail servers to reject any message that fails alignment checks. In this case, the attacker sent through SendGrid (wfbtrqkw.outbound-mail.sendgrid.net, IP 159[.]183[.]84[.]25), which was configured as an authorized sender for international.informdata[.]com. The DKIM signature used selector s1 under that domain. The Return-Path pointed to a VERP-encoded address at em8327.international.informdata[.]com, a SendGrid subdomain.

Everything aligned. DMARC did exactly what it was designed to do: it verified that the sending infrastructure was authorized for the domain. The problem is that authorization and intent are not the same thing. The attacker either compromised the InformData SendGrid account or configured a new SendGrid identity that could sign for the domain.

The Employment Verification Pretext

Employment verification requests are routine in business operations. Background check companies like InformData send them regularly, and recipients expect to receive them during hiring cycles. The pretext works because ignoring or delaying a verification can slow a colleague's onboarding, creating professional pressure to act quickly.

The CTA linked to verify.zippedscript[.]com/verify/employment/51d4ba99721cdbdbe83cc09a15f3d76b. The long hash in the URL path is a per-recipient tracking token, allowing the attacker to correlate clicks with specific email addresses. WHOIS for zippedscript[.]com shows Cloudflare nameservers and privacy-protected registration, a disposable domain with no legitimate web presence.

The unsubscribe link also pointed to verify.zippedscript[.]com/unsubscribe, confirming that the attacker controlled the entire link infrastructure.

Detection

This was a first-time sender flagged as high risk. Themis, the IRONSCALES Adaptive AI, labeled the recipient as a VIP and flagged the message based on behavioral signals: the Reply-To domain mismatch, the first-time sender pattern, and the disconnect between the legitimate brand identity and the link destinations. The detection did not depend on authentication failure, because there was none.

Defenders reviewing employment verification emails should check whether the Reply-To domain matches the From domain and whether CTA links resolve to the sender's actual infrastructure. When a background check company's email routes replies and clicks to entirely different domains, the verification request is the attack.

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

Indicators of Compromise

MITRE ATT&CK Mapping