An email attachment is a file sent inside an email message. Three checks decide the risk: expectation, file type, and provider checks. Expected ordinary files from known senders carry low risk; unexpected files, and files that can run code, carry high risk.
Scope here is webmail and desktop mail clients. Mail apps on phones vary by app, so their preview, download, and macro behaviour falls outside this piece. Reading a message and opening its attachment are different acts. The first shows text and images in the mail client. The second passes a file to a separate application, which may execute code contained in it. A separate AliasFleet piece covers opening the message itself, and another covers files that should not be sent by email in any case.
Expected and unexpected attachments
Expectation asks whether the reader had reason to anticipate the file before it arrived. An anticipated file arrives after advance notice. A friend may have mentioned photos from the weekend, a shop may have confirmed that an invoice would follow, or a colleague may have said that a report was on its way.
Pressure to open quickly marks the opposite case, as does a file that does not fit anything that sender normally sends, an unknown sender, or a complete absence of advance mention. An invoice, a delivery problem, or an account warning used as a reason for haste belongs in the same category.
Email was the top method scammers used to contact people in 2024, according to the US Federal Trade Commission. That page advises readers against clicking links or downloading attachments in unexpected messages. Instead, the company or bank is contacted through a phone number, email, or website already known to be real.
Internet service providers and software vendors do not send patches or software in email, according to the Cybersecurity and Infrastructure Security Agency. An attachment claiming to be either therefore fails the expectation test outright. The same page warns against unsolicited attachments even from people the reader knows, because return addresses can be spoofed, and because a genuine sender account can forward an infected file without knowing it.
The UK National Cyber Security Centre applies an equivalent rule to mail in its own name. Official NCSC emails never send unsolicited emails with attached files, especially .zip or Microsoft Office files.
A usable verification route sits outside the control of the message. The company app, a number printed on a card or a statement, or an address typed directly into a fresh browser tab all qualify. A reply returns to the address under suspicion, and a phone number printed inside the message belongs to whoever wrote the message, so neither route verifies the sender. Sender and link checks that sit alongside this check are covered in the AliasFleet phishing check guide.
File types and risk
Risk follows the last part of the filename, after the final full stop. A file called invoice.pdf.exe therefore counts as an executable, despite the .pdf in the middle of its name. The grouping below follows the blocked-type lists of Gmail and Outlook and the macro rules of Microsoft.
| Risk level | File types | Reason |
|---|---|---|
| High | .exe, .msi, .bat, .cmd, .vbs, .js, .ps1, .scr, .lnk, .iso, .dmg | Code can execute, or software can install, from these files. |
| Medium | .docm, .xlsm, .pptm, .zip, .rar | Programs sit inside these documents, or contents stay hidden inside these containers. |
| Lower | .pdf, .docx, .xlsx, .pptx, .jpg, .png, .txt | No code runs by itself from these files, although flaws in readers remain and links inside documents can lead to harmful pages. |
The Gmail block extends to files in compressed form, files inside archives, documents with malicious macros, and password-protected archives with archived content. Gmail blocks messages that may spread viruses, including messages with executable files, and its blocked list runs from .ade and .apk through .exe, .js, .msi, and .vbs to .xll. Outlook blocks the sending and receiving of certain file types on the same basis, with .exe and certain database files given as examples.
A plain .docx or .xlsx file contains no macros to enable. A .docm or .xlsm file, by contrast, is an Office document with macros enabled, and macros are small programs inside the document. Microsoft states that VBA macros are a common way for malicious actors to gain access to deploy malware and ransomware. Office blocks macros in files from the internet by default, and shows a Security Risk banner when such a file is opened.
An unexpected macro-enabled document that asks the reader to enable content is requesting permission to run code. Treat that request as the warning itself.
A password printed in the same message removes the protection that scanning would otherwise have provided, because password-protected archives cannot be scanned. A .zip file is a container, and its contents decide its risk, so an archive arriving with its password in the message combines two warning signs at once.
Preview and download
In Gmail, many attachment types can be viewed inside the webmail page, without saving the file to the device. An Office attachment can instead be opened in Docs, Sheets, or Slides, a route that stores a copy in Drive rather than running the original file on the device.
Preview reduces risk without removing it, because no provider page read for this piece states that previewing eliminates all risk, and a file that looks clean in preview can still cause harm after download. Where preview is available, use it first. A file that only becomes usable after download still requires the expectation and file-type checks.
CISA advises two further habits. Disable any setting that downloads attachments without action from the reader, and save and scan an attachment with up to date antivirus software before opening it where the source cannot first be verified. An automatic download reaches the device before any judgement has happened.
Gmail warnings also belong in this check. Gmail warns about .eml files whose senders cannot be confirmed, about attachments that are encrypted and cannot be scanned, and about attachments that allow unverified scripts. Any of those warnings returns the file to the unexpected category.
Provider checks before delivery
Attachments sent and received through Gmail pass through automatic virus scanning, according to Gmail antivirus scanning guidance. A message addressed to the reader that contains a known virus is rejected, while a virus found in an attachment already stored in the inbox prevents download of that attachment.
Encrypted archives escape scanning entirely, which explains the block on password-protected archives containing content. Signature scanning also misses threats that are too new to have a signature. For that reason, CISA warns against opening a suspicious attachment even after antivirus software reports the message as clean, since attackers release new viruses constantly and installed software may not yet hold the matching signature.
Australia's eSafety guidance takes the same position from the reader side. Delete a suspicious message, on the basis that a genuine sender will probably send it again, and run downloaded attachments through the reader's own antivirus suite before opening them.
Response to a suspicious attachment
When a suspicious file has already been opened, the first steps are to take the device offline and to enter no further credentials at any destination named by the file or its message. A full scan with the device antivirus software follows, the step the NCSC lists for a reader who opened a link or followed instructions to install software. Where the scan finds a threat, the device remains offline until the threat is removed.
Banking details given away call for contact with the bank. Passwords given away call for changes on every account sharing the password. Those are the NCSC rules for the two cases. A work or school device calls for a report to the IT support team as well. Provider report buttons and takedown addresses are covered in the AliasFleet reporting guide, and passkey and second-factor steps after an incident are covered in the account lockdown guide.
Accounts are watched for a few weeks after a clean scan. A result showing nothing does not prove that the file was harmless, a point CISA makes directly. The eSafety guidance puts the same point more softly: a clean scan almost always means the file is safe to open, leaving room for the exception.
Email aliases and attachments
AliasFleet offers email aliases: additional addresses that forward to a real inbox, with one address assigned per site, so a leaked address identifies its source and can be paused without affecting other addresses.
An alias alters the address held by a sender. It performs no scanning, blocking, or neutralising of an attachment. A suspicious attachment arriving on an alias therefore receives the same handling, in the same order: expectation, file type, preview, and provider warning.
The one extra detail an alias supplies is the address in the To line, which shows the site that held that address. That detail can assist judgement about a message claiming bank origin that arrived on an address supplied only to a bookshop. It gives no assurance about the sender, since an attacker already in possession of the address can still send to it, and mail from a compromised genuine account satisfies the address test while failing the remaining tests.
Pausing a single alias halts spread from that leak, and loss from a leak is limited to one address rather than the address used everywhere. That outcome is containment of addresses, not protection of files. Expectation, file type, and preview answer the attachment question, and no change of address answers it.
Top comments (0)