A practical guide to spotting a fake email at work

Cyber Attacks are particularly sneaky in workplace settings, where the lines between legitimate and fake communications can blur. Unlike our personal lives, where we often expect to hear from friends and family, workplace emails can catch us off guard. Professionally, however, a substantial amount of information about us is publicly accessible. An attacker can easily analyze our business website or gather intel from LinkedIn to impersonate a legitimate vendor or by simply crafting a business proposal tailored to your specific field; and then they can easily coax you to click a link or open an attachment. This guide covers what actually distinguishes a real message from a well-made fake, starting with the email client you read it in and the files that move through it, then the technical checks running quietly in the background, and ending with the one habit that catches nearly everything else: reading a domain slowly before you trust it.

Two habits that do more than any spam filter

The email client you choose matters more than most users realize. Every safeguard discussed in this article, such as the pass or fail block in the headers or a browser-style warning on a mismatched domain, only helps you if the software you are using actually implements it and keeps it updated. Established, actively maintained clients such as Outlook (and I must clarify that I personally still prefer the Classic version) or Thunderbird tend to do this reliably. A newer client with an appealing interface and glowing screenshots is not automatically worse, but it has had far less time to be tested against the malicious tricks, and that gap is exactly where the tricks work. Furthermore, the danger extends beyond mere immaturity; an unfamiliar, unverified email client could actually be disguised malware itself, designed to harvest your credentials or intercept your communications the moment you grant it access.

The same caution applies to how you share files, not just how you read them. Google Drive links offer convenience, but the default setting is often more open than people realise: “anyone with the link” can mean anyone who ever receives, forwards, or finds that link, indefinitely. Set sharing to specific people whenever the content is sensitive, and get in the habit of reviewing old shared files every so often to revoke access nobody needs anymore. A permission you forgot to remove is still a door left open.

For the file itself, most email providers accept attachments up to around 50MB, which covers the overwhelming majority of ordinary office documents. If you genuinely need to send something larger, a simple, well-known transfer service such as WeTransfer or SwissTransfer is a reasonable fallback for non-sensitive files. Treat any request that pushes you toward an unfamiliar file-sharing tool, or that asks you to install something just to open one document, as worth a second look before you comply.

What the domain actually tells you

The name in the “From” line is the least trustworthy thing in an email. Anyone can type “Your Bank” or your CEO’s name into that field, the same way anyone can write a fake return address on an envelope.

The parts that are genuinely hard to fake live one layer down, in the email’s domain and in three small records that domain publishes about itself. You do not need to be technical to use them.

The three checks that do the heavy lifting
Every legitimate sending domain can set up three things. Think of them as a guest list, a tamper seal, and a house rule.

• SPF is the guest list: The domain publishes which mail servers are allowed to send on its behalf. If a message claiming to be from yourbank.com was actually sent from a server that is not on that list, SPF fails.
• DKIM is the tamper seal: The sending domain adds an invisible cryptographic signature to the message. If the content was altered in transit, or the message was forged by someone who does not hold the domain’s key, the seal does not match.
• DMARC is the house rule: and it is the one that actually stops impersonation. It tells receiving mail servers what to do when SPF or DKIM fail, and it insists that the visible “From” address line up with the domain that passed authentication. A domain with a strict DMARC policy is very hard to spoof. A domain with no DMARC at all is an open door.

When all three pass, you have real evidence the message came from the domain it claims. When they fail, or the domain never set them up, you have a reason to slow down.

How to check, without being technical

You do not have to read any of this by hand. Two easy ways:

1. Ask your own inbox. Most email programs show you the verdict they already calculated. In Gmail, open the message, click the three-dot menu, and choose “Show original.” In Outlook, open the message and look at its properties or internet headers. You are looking for a short block near the top called Authentication-Results with three words in it: spf=pass, dkim=pass, and dmarc=pass. Three passes is a good sign. Any fail, especially dmarc=fail, is worth treating the message as suspect.
2. Check the sending domain directly. If you want to know whether the domain even bothers to protect itself, paste it into a lookup tool such as DomainIntel.app and look at its SPF, DKIM, and DMARC records. A real organisation that handles sensitive mail will usually have all three, with a strict DMARC policy. A domain that has none of them, or a DMARC policy set to “do nothing,” is exactly the kind of domain a scammer registers for a one-off campaign.

Two lines in the headers worth a glance
If you do open the original message, you only need to notice two things beyond the pass/fail block:

• The real sending domain. Look at the actual address after the display name, and at the Return-Path. If the email says it is from your bank but the real domain is secure-bank-alerts.co, the display name was just decoration.
• When the domain was born. A domain registered three days ago is not your bank. The same lookup that shows the SPF and DMARC records will show the domain’s registration date and its reputation or blocklist status. A brand-new domain, with no email authentication, that already appears on a spam blocklist, is about as clear a warning as you will get. You can run that check at DomainIntel.app.

None of this requires trusting how an email looks. It moves the decision onto things that are genuinely hard to fake: the domain, its published records, and its history.

Reading the invisible clues in the sender’s setup

First, it is highly useful to check whether you are actually listed in the recipient field. Receiving an email where the “To” field is empty or contains a different address usually indicates it was sent via BCC (blind carbon copy). This is a cheap and fast way to send bulk emails using free providers and general email servers intended for legitimate mass mailings (like newsletters). Providers handling legitimate bulk emails incur their own operational costs and enforce specific security safeguards and protection policies; for example, a user must reveal their identity and provide explanations regarding how they acquired their mailing list.

The Return-Path and Reply-To entries in email headers can provide another tell, especially when the apparent sender depends on a commercial or free provider such as outlook.com or gmail.com. If either address does not match the sender shown in the message, I immediately wonder why an alias is being used. The sender might be using an alias because their primary address is blacklisted or they’re simultaneously running multiple themed attack campaigns.

I realize that email headers are not particularly user-friendly or readable for the average human. However, in the age of AI, this is no longer a problem. Even with a free account on Microsoft Copilot or Google Gemini, anyone can analyze headers by copy-pasting them, instantly receiving clear explanations.

Finally, one method I personally use from time to time is the “SPF Record Checker” tool at DomainIntel.app. It helps me draw conclusions about whether a sender is dangerous, and whether the business is a sophisticated user that respects technology. The thought process is as follows:

Using self-hosted mailboxes on shared hosting servers is a headache for professional communication. To begin with, they lack quality tools for synchronizing calendars and contact agendas across employees’ various devices. Secondly, you’ve got zero control over other users on that server; those “roommates” could get your IP blacklisted in a heartbeat. Even worse, by sending all types of emails (newsletters, holiday wishes, notifications, invoices, and actual correspondence) from the exact same source, your partners’ filters may start categorically classifying every email originating from your business as spam, regardless of the actual content. Soon, everything from your business lands in the spam folder, no matter how important it is.

If someone checks my personal SPF records, they will find that on my root domain I use “v=spf1 include:spf.protection.outlook.com -all“. This is because I host my professional mailbox on Microsoft Exchange Online servers, while I use different subdomains for invoicing, my appointment scheduling application, and my client collaboration cloud. Even if a client chooses to mark an automated notification for an upcoming appointment as spam, I still have excellent odds that they will receive the direct emails I send them personally.

Now let’s consider a particularly annoying seminar business. No matter how many times I have unsubscribed from their mailing list, they continue to email me daily with “super offers” for professional seminars that will supposedly transform my career so much that all of Wall Street will cheer my name instead of the opening bell, while my wife will welcome me home with a heavy medieval British accent, by saying “Oh, my King!“. Their SPF record is: “v=spf1 include:_spf.webador.com include:spf.sendinblue.com ~all“. Such a configuration screams a few things. For example that they rely on a dirt-cheap shared hosting server only supporting a random web builder. The second service is a newsletter platform (again, with a free tier) while clearly lacking proper arrangements for mailboxes for their staff. Lastly, an experienced eye will notice that in my case, the -all mechanism instructs mail servers to strictly reject any email claiming my root domain as the sender if it does not originate from Microsoft’s servers. The second business, by placing ~all at the end, instructs mail servers to accept all emails, even when they do not originate from their shared server or newsletter platform.

A domain that passes every check can still be a fake

None of this protects you from a domain that plays entirely by the rules while still being fake. SPF, DKIM, and DMARC only confirm that a message came from the domain it claims to come from. They say nothing about whether that domain belongs to the person or company you think it does. A scammer who registers yourbnak.com, or who uses a Cyrillic letter that is visually identical to the Latin one in your bank’s name, will sail through every technical check, because those checks were never built to catch that.

The simplest version of this trick is a domain built to be misread rather than miscoded. A missing letter (exmple.com), a swapped pair (exmaple.com), or a hyphenated add-on that sounds official (yourbank-security.com) all pass as ordinary domains to a computer, while still fooling a reader who is moving quickly. None of this needs a single line of illegal code; the whole attack is the name itself, registered for a few euros and left to wait for someone to misread it.

Instead of spelling, there is a more sophisticated approach. Across several alphabets, some letters appear exactly the same on a display; for example, the Cyrillic “а” and the Latin “a” are different characters to a computer but visually indistinguishable to the human eye. Registering a domain with a swapped look-alike character produces a name that reads identically but belongs to a different alphabet. Once browsers detect a mismatch of scripts, they usually fall back to showing the domain’s raw form, a string starting with xn--. Email programs are less consistent than browsers at detecting mixed-script domains, so this technique remains most dependable in your inbox, before you click anything.

Before you click a link, hover over links or press and hold on your phone to see the real address, not the text wrapped around it. Read it slowly, character by character, starting right after the @ sign or the first single slash. If anything feels off, or you want a second opinion, paste the domain into a lookup tool such as DomainIntel.app. Alongside its SPF, DKIM, and DMARC records, it will also show you when the domain was registered and whether it already appears on a spam blocklist. A domain that was created last week, has none of its authentication set up, and is already flagged, is not a coincidence.

Before you click

When a suspicious email lands, the order of operations matters more than any single check.

• Do not click any link or open any attachment yet.
• Check the authentication result described earlier: spf, dkim, and dmarc should all read “pass“.
• Hover over the sender’s address and over any links, and read the actual domain slowly, character by character.
• If something feels off, verify through a channel you already trust, such as calling the person or company on a number you already had, not one taken from the email itself.
• If it still looks wrong, do not forward it around the office to ask; that just spreads the exposure. Delete it, or report it through your provider or IT contact.

None of these steps require technical skill. They only require slowing down for the thirty seconds it takes to look properly.