The FedEx Email That Salesforce Authenticated and Qualtrics Delivered: Data Harvesting Through Three Layers of Trust

The email came from FedEx. Salesforce delivered it. Qualtrics hosted the forms. SPF passed. DKIM passed. DMARC passed. Every link scanned clean. Three layers of legitimate infrastructure, stacked on top of each other, and not a single red indicator for a gateway to act on.

The message was requesting non-public shipment data, physical addresses, and manufacturer names. The delivery mechanism was a survey form.

Salesforce MTA Delivers a Fully Authenticated FedEx Email

The message originated from smtp06-ia7-sp4.mta.salesforce[.]com at IP 13.110.246[.]181. DKIM was signed with selector cedprod2026 under d=fedex[.]com. SPF passed because FedEx authorizes Salesforce infrastructure in its DNS records. DMARC aligned on both mechanisms. The Return-Path pointed to a Salesforce-managed bounce address, standard for any brand using Salesforce to send transactional or marketing email.

From the perspective of any receiving mail server, this was FedEx sending through an authorized platform. That assessment was technically correct. It was also irrelevant to the question of whether the content was safe.

Clean Links to a Data Collection Endpoint

The body contained four links. Two pointed to fedex[.]com pages, including the Italian homepage at fedex[.]com/en-it/home.html. Both scanned clean. The other two pointed to Qualtrics survey forms hosted at fedex.eu.qualtrics[.]com/jfe/form/. Those also scanned clean, because they are real Qualtrics forms on Qualtrics infrastructure.

Qualtrics forms can collect any data the creator specifies. In this case, the form requested physical addresses, contact names, and shipment details that would not normally be shared outside a verified business relationship. A URL scanner evaluates the destination domain and the HTTP response. It does not evaluate what data the form is designed to extract.

The Behavioral Tells the Gateway Could Not See

The email was written in Italian, which aligned with the targeted recipient. But several details did not hold up under scrutiny. The body referenced italy@fedex[.]com and paperwork@fedex[.]com as contact addresses. Neither appears on FedEx public-facing contact pages for Italy. The message contained minor grammar issues inconsistent with enterprise localization standards. A hard deadline created urgency to respond quickly rather than verify the request through internal channels.

These are social engineering signals. They do not trigger authentication failures, link scan alerts, or attachment detonation. They require a detection model that evaluates the behavioral context of the request, not just the infrastructure that delivered it. Themis, the IRONSCALES Adaptive AI engine, evaluates exactly these patterns: unverifiable contact references, urgency framing, and data requests that exceed normal business communication norms.

No attachments. No malware. No malicious URLs. Just a form asking for information it should not have been asking for, delivered through infrastructure that made the question invisible.

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

Indicators of Compromise

MITRE ATT&CK Mapping