Can a genuine WeTransfer email still be dangerous?

This guide reflects common WeTransfer behaviour and public security guidance available in July 2026. File sharing services, security controls and reporting options can change, so business procedures should be reviewed periodically.

When a WeTransfer email arrives, the first question many people ask is whether the message genuinely came from WeTransfer. That is a useful check, but it answers only one part of the problem.

A genuine notification means that the WeTransfer service generated an email because someone created a transfer. It does not prove that the person uploading the file works for the organisation they claim to represent, that the business enquiry is genuine or that the file is safe to open.

There are therefore three separate questions:

1. 1. Did the notification genuinely come through WeTransfer?
   2. Is the person who arranged the transfer really who they claim to be?
   3. Is the file appropriate and safe to open?

A positive answer to the first question does not automatically answer the other two.

The practical decision is not whether malicious intent can be proved beyond doubt. The decision is whether sufficient trust has been established before a file is opened on a business device.

This guide explains how a real file sharing service can still be used in an attack, how a convincing sales enquiry can lower suspicion and what can be checked without downloading or opening the file.

Use the links below to jump to the section most relevant to your question.

• What a genuine WeTransfer email actually proves
• How a real transfer can still be used in an attack
• How a convincing sales enquiry can lower suspicion
• Why the domain, company details and file need separate checks
• How to check a transfer without opening the file
• Should businesses block WeTransfer?
• What to do with a suspicious transfer
• What protection layers help
• What this guide does not mean
• Frequently asked questions
• Related guides
• Supporting references
• Further Guidance and Support

A legitimate WeTransfer notification confirms that the WeTransfer system was used to create and announce a transfer. It helps distinguish a genuine service notification from a message that only imitates WeTransfer branding.

That confirmation is useful, but limited.

The transfer service is moving information supplied by another person. It is not carrying out a full business identity check, confirming employment or deciding whether the commercial request is genuine.

Even where an email address has been verified by the service, verification normally establishes control of that address. It does not establish that the address belongs to the organisation being represented or that the person has authority to place an order, request information or send files on its behalf.

It is helpful to think of the process as three separate layers:

• • The platform: Did WeTransfer genuinely send the notification?
  • The person: Has the identity and claimed organisation been independently verified?
  • The file: Does the filename, type, size and purpose make sense, and is it safe to open?

The platform can be genuine while the person or file is not.

The same principle applies to OneDrive, SharePoint, Dropbox, Google Drive and other recognised services. A familiar platform provides useful context, but its reputation should not automatically be transferred to every person or file using it.

For the broader principle, see Why trusted services can still be used in cyber attacks.

A file sharing service is designed to move files between people. An attacker can therefore create a real transfer in the same way as an ordinary user.

The notification may come from the correct service address, use genuine branding and open the real file sharing website. The unsafe part may be the uploaded file, the identity of the uploader or the action requested after the file is opened.

A transferred item could be used in several ways:

• • A file may contain malicious code.
  • An HTML file may open in a browser and display a false sign in page.
  • A document may contain a link leading to another website.
  • A ZIP archive may contain an executable file, script or misleading shortcut.
  • A file may ask the recipient to enable content, sign in again or install software.
  • The initial item may only be the first stage of a later download.
  • A legitimate sender account may have been compromised and used without the account owner’s knowledge.

An HTML file is not automatically malicious. HTML is the normal language used to build webpages. The important question is why an unfamiliar person is sending an HTML file and whether that file type reasonably matches the claimed business purpose.

A small HTML file may contain little more than instructions that open another page or load content from an external system. This means the initial file does not need to contain the complete attack.

Password protection does not prove that a transfer is safe. A password controls who can access the content, but it does not verify what the content is or why it was sent.

Encrypted or password protected archives may also reduce the ability of some email and security systems to inspect the files before delivery. Entering a password does not itself execute malware, but opening or running unsafe content afterwards may place the device or account at risk.

Security scanning remains useful, but it should not be treated as identity verification or proof that every file is safe. New, disguised, remotely loaded or password protected content may not be recognised in the same way as a known malicious file.

People working in sales, procurement, recruitment and accounts regularly receive files from contacts they have not met before. Opening proposals, specifications, orders, application documents and invoices is part of normal work.

That ordinary workflow can be used to make an unsafe file appear expected.

In a recent sales related incident, someone claiming to represent a large international organisation first submitted an enquiry through a genuine company website. A member of the sales team replied, creating a real email conversation.

A WeTransfer notification then arrived containing supposed order details and technical specifications.

Several details initially appeared reassuring:

• • The enquiry related to a genuine organisation.
  • The corporate address included in the message was real.
  • The organisation’s official website existed.
  • The transfer notification genuinely came through WeTransfer.
  • The message followed an earlier reply from the sales team.

However, those facts did not verify the sender.

The email domain differed from the genuine organisation’s domain by one repeated letter. The lookalike domain had been registered only a few days before the enquiry.

The transferred item was described as order details and technical specifications, but it was a 2.55 KB HTML file. That file type and size did not reasonably match the description of detailed purchasing and technical information.

The file was not opened or analysed, so it would be inaccurate to claim that its precise contents or purpose were conclusively established. The combination of the lookalike domain, recent registration, copied company details and unexpected HTML file was nevertheless sufficient to decide that the transfer should not be trusted.

This distinction matters. A business does not need to prove that a file is malicious before declining to open it. Trust needs to be established before the risk is accepted.

A potentially valuable sales opportunity can also affect judgement. Once someone wants an enquiry to be genuine, they may give more weight to reassuring details and look for explanations for the warning signs.

That is not a criticism of the recipient. It is one of the mechanisms that makes this type of approach effective.

A safer process should allow a genuine opportunity to continue through independent verification rather than asking an individual employee to decide from the email alone.

A convincing message often combines several pieces of genuine information with one or two important false elements. Each part should therefore be checked separately rather than treated as one overall impression.

Lookalike domains

A lookalike domain is registered to resemble another organisation’s real domain. The difference may be an added letter, a repeated letter, a missing character, an added word or a different domain ending.

Examples of differences worth checking include:

• • companynname.com instead of companyname.com
  • companyname-support.com instead of companyname.com
  • companyname.example.com, which belongs to example.com
  • A different ending such as .net, .org or another country domain where the organisation normally uses .com

Check the complete address after the @ symbol. Do not rely on the sender’s display name.

A newly registered domain is not automatically malicious. New organisations and genuine projects also register domains. Domain age becomes more meaningful when it appears alongside impersonation, copied company details, an unexpected file and an unverified business request.

The use of a recognised registrar, Microsoft name servers or another established provider does not prove that the domain belongs to the organisation being represented. Attackers can purchase ordinary commercial services in the same way as legitimate customers.

Copied company details

A genuine office address, logo, company name, employee title or link to the real corporate website does not authenticate the sender.

These details are often publicly available through:

• • Corporate websites
  • Business directories
  • LinkedIn
  • Press releases
  • Company filings
  • Recruitment pages
  • Social media profiles
  • Previous email signatures

Copied information can make a false message more convincing without requiring access to the genuine organisation’s systems.

The correct question is not only whether the company exists. It is whether the person and domain being used can be independently connected to that company.

File type and size

The claimed purpose of a file should match the item being delivered.

Technical specifications, product requirements or order details would commonly be expected as a PDF, spreadsheet, Word document, drawing or a collection of supporting files.

A very small HTML file is different. It may simply contain instructions that open a webpage, redirect the browser, display a false sign in screen or start another stage of the process.

A mismatch does not prove the file is malicious, but it provides a reason not to open it until the request has been verified.

Before opening a transferred item, review:

• • The full filename
  • The visible file extension
  • The file size
  • Whether the file type matches the claimed content
  • Whether the sender explained why that format was used
  • Whether the file was expected
  • Whether the business relationship has been verified

File extensions should remain visible in Windows and other operating systems where possible. A name such as specifications.pdf.html may otherwise appear to be a PDF when it is actually an HTML file.

Password protected and encrypted files

Password protection can be appropriate when genuine sensitive information needs to be shared. However, a password only restricts access to the content. It does not establish that the sender or file is trustworthy.

An attacker can send a password separately and present the extra step as evidence of security.

Where a new or unverified contact sends an encrypted archive:

• • Do not treat the password as authentication.
  • Verify the sender independently.
  • Confirm why encryption was required.
  • Ask for a description of the contained files.
  • Use an approved business upload method where possible.
  • Do not open the archive on a production device merely to discover what it contains.

Most of the important checks can be completed without downloading or opening the transferred item.

The aim is to verify the business relationship and expected content through a separate route.

1. 1. Stop before clicking the download link.
      Do not use the file itself to investigate whether the request is genuine.
   2. Check the complete sender domain.
      Compare it character by character with the domain shown on the organisation’s official website.
   3. Find the organisation independently.
      Type the known web address yourself or use a trusted existing record. Do not use a link supplied in the suspicious message as the source of verification.
   4. Use independently obtained contact details.
      Contact the organisation through its published switchboard, procurement team, contact form or a telephone number already held in your records.
   5. Ask whether the named person works there.
      Confirm whether the organisation recognises the enquiry and whether the person has authority to send the documents.
   6. Ask for a summary in the body of the email.
      A genuine buyer should normally be able to describe the products, quantities, requirements, timescale and reason for contact without requiring an unknown file to be opened first.
   7. Arrange a short telephone or video call.
      This can confirm the business context and provide an opportunity to ask questions that are difficult to answer through a copied message.
   8. Review the file information without opening it.
      Check the name, extension and size shown in the transfer notification.
   9. Ask the verified contact to use an approved upload method.
      Once the person has been confirmed, provide a company controlled location for receiving the documents where available.
   10. Report the original message.
       Use the organisation’s email reporting controls and inform IT support so that related messages, links and domains can be reviewed.

A WHOIS search can provide additional context about when a domain was registered and which provider it uses. It should support the wider decision rather than being treated as a complete test by itself.

Where a message remains suspicious, stop communicating through that email thread. Begin any verification through contact details obtained independently.

WeTransfer is a legitimate file transfer service and many genuine organisations use it. A transfer from WeTransfer should therefore not be described as malicious simply because of the platform used.

However, a business may decide that public file sharing links are not an acceptable way to receive documents from new or unverified contacts.

A practical policy would be:

Documents from new or unverified contacts must not be opened through WeTransfer or another public file sharing service until the sender’s identity and the business purpose have been independently verified. After verification, the contact should use an approved company upload method where one is available.

This approach does not automatically reject a genuine sales opportunity. It changes the order of the process:

1. 1. Verify the person.
   2. Confirm the business request.
   3. Agree an approved way to exchange documents.
   4. Review the file information.
   5. Open the content only after those checks are complete.

An organisation may choose to block WeTransfer completely where there is no legitimate business need for it. That is a policy decision based on how the organisation works.

Blocking only WeTransfer is not complete protection. The same method can be attempted through OneDrive, SharePoint, Dropbox, Google Drive or another familiar service.

The wider policy should therefore cover unapproved public file sharing services rather than relying only on one blocked domain.

A suspicious transfer should be reported and preserved for review without encouraging more people to interact with the live link.

Recommended actions include:

• • Use the phishing or suspicious message reporting option in the email system.
  • Report the message through the organisation’s email security platform where one is provided.
  • Inform IT support or the person responsible for security.
  • Use WeTransfer’s Report this transfer option.
  • Report suspicious emails to the National Cyber Security Centre where appropriate.
  • Avoid forwarding a live suspicious message widely inside the organisation.
  • Use a screenshot when colleagues only need to see the visible content.
  • Preserve the original message for technical review through the approved reporting process.
  • Do not continue corresponding with a lookalike domain.

If the link was selected but no information was entered and no file was opened, report what happened and provide the approximate time, device and browser used.

If a password or verification code was entered into a page reached through the transfer:

• • Contact IT support.
  • Change the affected password through the known official website.
  • Review active sessions and sign in activity.
  • Remove sessions or devices that are not recognised.
  • Review whether the same password was used elsewhere.
  • Check whether additional account recovery details were supplied.

If a file was opened or software was run, stop testing the item and contact IT support. Explain exactly what was opened, what appeared on screen and whether any sign in details, permissions or installation requests were accepted.

Early reporting gives the organisation more information to review. It should not be treated as an admission of fault.

No single product or check can carry the whole responsibility for this type of risk.

Different controls address different parts of the process:

• • Email security can identify unusual senders, suspicious links and known malicious content.
  • Anti malware protection can detect known harmful files and behaviours.
  • Browser and web protection can block some unsafe destinations.
  • DNS and web filtering can restrict access to known malicious domains.
  • Multifactor authentication can reduce the value of a stolen password, although some phishing methods also attempt to steal sessions or approval codes.
  • File extension visibility can make misleading filenames easier to recognise.
  • Approved upload methods can reduce dependence on public transfer links.
  • Least privilege can limit what a malicious file can change.
  • Device monitoring can help identify unusual activity after a file is opened.
  • Clear reporting procedures can help suspicious messages reach the right people quickly.
  • Independent verification can confirm the person and business request before technical controls are asked to judge the file.

The human part of the process should not rely on memory alone. A short verification procedure is easier to apply consistently than expecting each person to recognise every possible warning sign.

For a wider explanation of common starting points, see How do cyber attacks usually start in small businesses?

Where document handling, email security, identity protection and reporting procedures affect several users, the issue belongs within wider security and resilience planning rather than being treated only as a decision about one message.

This guide does not mean that every WeTransfer notification or transferred file is dangerous.

It also does not mean that one warning sign provides conclusive proof by itself.

A recently registered domain may be legitimate. An HTML file may be legitimate. A new sales enquiry may be genuine. A large organisation may use an outside consultant or a new project domain.

The decision should be based on the complete situation and whether the identity, request and file can be verified through an independent route.

It is equally important not to assume that the following details prove safety:

• • The email came from a recognised file sharing service.
  • The website uses HTTPS and shows a padlock.
  • The message contains a genuine company address.
  • The domain uses Microsoft or another recognised provider.
  • The file is password protected.
  • Antivirus did not display a warning.
  • The sender knew the recipient’s name or job role.
  • The enquiry was commercially relevant.
  • The message followed an earlier email conversation.

The checks in this guide are not a permanent or complete security checklist. File sharing services, attack methods, browser behaviour and security controls change over time.

Organisations should review their procedures periodically and use layered security involving technology, business processes and people.

No combination of controls can guarantee that every unsafe message or file will be identified. The purpose of the controls is to reduce exposure, support better decisions and limit the effect of an incident if one occurs.

The questions below address common misunderstandings about genuine transfer notifications, sender identity and file safety.

Is WeTransfer safe to use?

WeTransfer is a legitimate file transfer service used for sending large files. As with other file sharing platforms, its safety depends partly on who created the transfer, what was uploaded and what the recipient is being asked to do.

A genuine service can still be misused by someone sending an unsafe file or pretending to represent another organisation.

Can a real wetransfer.com link lead to malware?

A real WeTransfer link may lead to a genuine transfer that contains an unsafe file. The file may also lead to another website, request a sign in or begin a further download.

The genuine domain confirms the platform being used. It does not confirm the contents or business identity of the uploader.

Does the email address shown in the transfer prove who sent it?

It may show which address was used in connection with the transfer, but it does not prove that the person works for the claimed organisation.

A lookalike domain can be registered and used to create ordinary email accounts. A genuine account can also be compromised.

Verify the person through a separate trusted contact method.

Does a password make a transferred file safe?

No. A password restricts access but does not establish that the content is safe.

Password protected files may also be harder for some security systems to inspect before delivery. The sender and purpose should be verified before the password is used and the contents are opened.

Is it safer to open the file on a phone?

A phone should not be used as a testing environment for a suspicious file.

Phones can also display false sign in pages, download content, expose account sessions or request permissions. Moving the action to another device does not verify the sender or file.

Is a small HTML file always malicious?

No. HTML files have many legitimate uses.

The warning sign is the mismatch between the file and its claimed purpose. A very small HTML file is not what most people would expect when receiving detailed order information, drawings or technical specifications from a new customer.

The mismatch should be investigated through independent verification rather than by opening the file.

Should a sales team reject every file from a new customer?

A sales team does not need to reject every new contact. It needs a safe method for confirming who the person is and receiving their documents.

A genuine contact can provide a written summary, complete an introductory call and use an approved upload method after verification.

This preserves the sales opportunity without requiring the recipient to trust an unknown file first.

Can IT determine whether a file is malicious?

Security specialists may be able to inspect a file in an isolated environment, but that is not always necessary for the immediate business decision.

Where the sender cannot be verified and the request contains several warning signs, the file should not be opened on an ordinary business device merely to obtain proof.

The following guides provide wider context about trusted platforms, documents and common ways attacks begin.

Why trusted services can still be used in cyber attacks?

How do cyber attacks usually start in small businesses?

Can PDF files be dangerous?

What is layered security and why does it matter?

The following sources provide further guidance on recognising suspicious messages, verifying file transfers and reporting potentially malicious content.

• • National Cyber Security Centre: How to spot a scam email, text message or call
    
  • National Cyber Security Centre: Report a scam email
    
  • WeTransfer Support: How to recognise malicious files which are spam
    
  • WeTransfer Support: Phishing attempts and other WeTransfer imitations
    
  • WeTransfer Support: Reporting Abuse
    
  • Microsoft Threat Intelligence: File hosting services misused for identity phishing
    
  • Darktrace: WeTransfer Impersonation Attacks Caught by Darktrace AI
    

External guidance, service behaviour and reporting methods may change after this guide is published.

This guide forms part of a broader layered security approach. For structured guidance on security and resilience planning, see our Security and Resilience page.

For information about practical implementation and ongoing support, you can review our IT services and local IT support coverage across London, Hertfordshire, and Essex.

Return to all guides

Author
Elías Sánchez
IT Support Consultant
Evening Computing
London, United Kingdom

This guide was prepared by Elías Sánchez with research and drafting assistance from AI tools. All technical content has been reviewed and adapted for clarity and accuracy.

Last reviewed
01 July 2026