Category: Uncategorized

Quishing is QR-code phishing. It hides a malicious link inside a QR code image. According to the Canadian Anti-Fraud Centre, fraudsters are increasingly using QR codes in various scams to steal personal information and money.

If you've opened an email lately that asks you to scan a code to reset a password, review a bill, or track a package, you've already seen why this works. The message looks tidy. The QR code looks normal. Your phone makes scanning feel routine, so you move faster than you would with a plain text link.

That small shift matters. With ordinary phishing, people often hover over a link and pause. With quishing, the dangerous part sits inside an image, and the scan usually happens on a phone where the full web address may be harder to inspect.

Many business owners understand phishing in general, but quishing creates a new blind spot. If you'd like a refresher on the broader problem first, our guide to what email phishing looks like in practice covers the older pattern that quishing builds on.

What Is Quishing

A common situation looks like this. You get an email that says your Microsoft 365 session expired, or that a courier couldn't deliver a parcel. Instead of a button, the email tells you to scan a QR code to fix the issue on your phone.

That is quishing, short for QR-code phishing. Attackers place a malicious link inside a QR code so you scan it, open a fake site, and hand over login details or trigger a malware download.

Why the scam feels normal

QR codes are everywhere now. Restaurants use them for menus. Offices use them for guest Wi-Fi, forms, and sign-ins. Shipping notices, event check-ins, and support portals often include them too.

Attackers rely on that familiarity. They don't need to invent a strange behaviour. They only need to copy a behaviour you already trust.

Practical rule: A QR code is not proof that a message is legitimate. It's only another way to deliver a link.

Why security teams pay attention to it

Quishing isn't a niche trick. Malwarebytes describes it as a rapidly evolving cyber threat that bypasses traditional email security filters by embedding malicious links within QR codes, and notes that the Federal Trade Commission has reported a rising trend in these schemes (Malwarebytes on what quishing is).

That warning matters because the attack changes where your attention goes. Instead of checking a visible link on your computer, you scan an image and jump to a site on your phone. The handoff feels smooth, which lowers your guard.

For a small business owner, the risk is practical, not abstract. One employee scans a fake payroll code, enters credentials on a spoofed page, and the attacker may gain access to email, invoices, or internal messages. The QR code itself isn't dangerous. The hidden destination is.

How QR-Code Phishing Works

Most quishing attacks follow a simple chain. The criminal creates a fake login page, turns its address into a QR code, wraps that code in a convincing message, and waits for someone to scan it.

What the attacker does first

The first step is usually a fake destination. It might copy a Microsoft 365 login, a bank sign-in page, or a document-sharing screen. The page often looks polished because criminals know the QR code already did the hard part, which is getting you to visit.

Then they convert that web address into a QR code. According to IBM's security research, quishing differs from ordinary phishing because it uses a two-dimensional barcode, which stores data horizontally and vertically, to redirect people to spoofed login pages or malware.

What you experience when you scan

From your side, the process feels harmless. You open your phone camera, scan the code, and tap the prompt. On mobile, you may only see a shortened preview or a quick browser handoff, not a careful desktop-style inspection of the full address.

That is one reason these attacks work so well. People scan in the middle of the day, often while moving between tasks. A rushed employee handling invoices or account alerts may treat the code as a shortcut instead of a risk.

A few common paths look like this:

1. Account reset
   An email says your password expired and asks you to scan a code to re-authenticate.

2. Document review
   A message claims a secure file must be opened on mobile for compliance reasons.

3. Payment or delivery
   A code promises to fix a failed delivery, confirm banking details, or release an invoice.

The QR code is only the lure. The real theft happens on the page that opens after the scan.

Proofpoint also notes that security teams now use QR code analysis engines with computer vision and machine learning to decode embedded URLs and assess risk. That tells us two things. First, defenders know this is a serious problem. Second, the basic email stack still needs extra help to inspect image-based threats well.

Why Quishing Slips Past Email Filters

A business owner gets an email that looks routine. It asks them to review a secure document or confirm an account detail, and instead of a blue link, it shows a QR code. The email gateway lets it through. The phone scan opens the risky page later.

The blind spot in many inboxes

Traditional filters are built to inspect what they can read quickly. They check sender reputation, headers, attachment types, known phishing wording, and visible URLs. A QR code interrupts that process because the destination is tucked inside an image instead of written out in text.

A simple comparison helps here. A normal phishing email is like a parcel with the address printed on the label, so scanners can read it right away. A quishing email hides that address inside a photo of the label. The message may still be suspicious, but the main clue is harder for basic filtering tools to parse.

IBM describes quishing as a threat that hides in plain sight because attackers replace clickable links with QR codes that many email scanners do not inspect well (IBM on why scanners miss quishing).

That is why an email can pass security checks and still lead to a phishing page later.

If you want a plain-language explanation of how inbox protections usually inspect messages, our guide to spam filtering and email security basics explains what filters look for and where image-based threats can slip through.

Why QR codes create a second layer of risk

Quishing also shifts the attack onto a mobile device. That matters because the scan often happens outside the protected business environment. An employee may use a personal phone, open the page in a mobile browser, and never see the same warnings, URL previews, or security controls they would notice on a desktop.

For Canadian businesses, that gap is especially important. Attackers have used QR-driven phishing in banking and payment scams, including cases reported in Canada that target mobile users with fake account prompts and phone-based credential theft. Generic guides often stop at "QR codes hide links." The more practical point is that the handoff to mobile can bypass both the email filter and the user's usual verification habits.

The compliance side matters too. If a staff member scans a fake code and exposes customer or employee information, the problem extends beyond a password reset. Under PIPEDA, organisations must notify the Privacy Commissioner and affected individuals about breaches that pose a "real risk of significant harm," and they must document all breaches and retain those records for at least 24 months.

This is especially critical for Canadian businesses. Email security isn't just about preventing the initial scan—it's about ensuring that if a breach occurs, your email infrastructure is designed to minimise exposure. Typewire was built with this in mind: by hosting email and audit data in Canada under Canadian jurisdiction, it ensures that if a quishing incident happens, the full record of that breach stays under your control and PIPEDA jurisdiction, rather than routing through US-based servers where retrieval for incident response becomes more complicated.

A short explainer can help if you'd like to see the attack flow visually.

Why this matters

Quishing succeeds because many email defences were designed to judge written links, while the actual destination now sits inside a scannable image and opens on a phone. For a small business, the practical lesson is straightforward. Treat a QR code in email with the same caution you would give any unexpected login link, invoice update, or banking request.

Real Quishing Examples

The easiest way to spot quishing is to see how it shows up in everyday work. These aren't exotic attacks. They often arrive in ordinary business situations.

The fake IT reset

A staff member receives an email that says multi-factor authentication needs to be reconfigured. The message avoids a visible button and instead says, "For security, scan this code on your mobile device." The destination opens a sign-in page that looks like a normal Microsoft or Google login.

This catches people because the format feels more secure than a clickable link. In reality, the QR code only hides the same kind of phishing destination.

The delivery problem that isn't real

A small retailer gets a shipping notice saying a parcel is held at a depot. The message includes a QR code to reschedule delivery. The owner scans it between customer calls, lands on a payment page, and enters business contact details or card information.

The trap works because it creates a small, believable inconvenience. People want the parcel released, so they act before they verify.

The mobile banking and fake IVR trap

A more worrying pattern involves banking. Malwarebytes notes that quishing can redirect people to fake IVR systems, and a CBC report cited in FuseCS says that in early 2025 31% of quishing victims in Vancouver lost money through fraudulent IVR calls after scanning malicious QR codes (FuseCS summary of quishing and fake IVR losses).

This attack can unfold in a few steps:

Scenario	What the victim sees	What the attacker wants
Banking alert	A QR code to "verify unusual account activity"	Login details or phone-based verification data
SMS or email follow-up	A prompt to call a support number after scanning	Trust and urgency
Fake IVR system	Automated prompts that sound bank-like	PINs, account details, or one-time codes

If a QR code leads you into a phone tree, treat it with the same suspicion as a surprise login page.

How to Protect Yourself and Your Business

The best defence is not to stop using QR codes entirely. It's to treat them like links, because that's what they are. Once you make that mental switch, your habits improve fast.

Safer scanning habits for individuals

Start with a pause. If a message is unsolicited and asks you to scan a code to fix a problem, slow down. Use a separate path to verify the request, such as typing the known website address yourself or calling the sender through a trusted number you already have.

These habits help most:

• Preview before opening. If your phone shows the destination, inspect it before tapping. If the address looks unfamiliar, misspelled, or unrelated to the organisation, stop.

• Avoid urgency traps. Messages about account lockouts, invoices, and package issues often try to rush you.

• Use the official app or site. If your bank or software provider needs action, open the app or website directly rather than entering through a QR code.

• Keep work and personal caution aligned. A personal phone can still expose business accounts if you use it for email or sign-ins.

Practical controls for businesses

Staff training matters, but policy matters too. Teams need a simple rule they can follow under pressure: no one should scan a QR code from email to handle credentials, payroll, banking, or password resets unless the request is verified through a separate channel.

The Canadian Centre for Cyber Security says quishing can circumvent DMARC (Domain-based Message Authentication, Reporting, and Conformance) compliance policies, and recommends DMARC-aligned anti-phishing software plus CIRA's Canadian Shield DNS resolver as defensive benchmarks (Canadian Centre guidance on phishing and quishing defences).

A sensible business checklist looks like this:

1. Train for the format, not just the concept
   Many teams train for suspicious links but not suspicious QR codes. Show employees examples from invoices, courier messages, and IT notices.

2. Set a verification rule
   If a code asks for credentials, payment, or identity confirmation, employees should verify through another channel first.

3. Review mobile exposure
   Quishing often succeeds on phones. Check whether your team uses personal devices for work sign-ins and whether your mobile browser habits are part of security training.

4. Prepare for incident handling
   If someone scanned a malicious code, respond as you would to any phishing event. Reset passwords, review account activity, and document the incident.

Key takeaway: The safest QR code is the one you don't scan until the context makes sense.

The privacy and compliance side

Security and privacy connect quickly here. If your organisation handles personal information, you remain responsible for it even when third-party vendors process it under PIPEDA, according to the practical summary linked earlier. That means your provider choices, staff practices, and incident records all matter.

Data location matters too. A Canadian data sovereignty overview notes that organisations must obtain explicit consent before collecting, using, or disclosing personal information, and that individuals retain rights to access and correct their data under PIPEDA's fair information principles (overview of Canadian data sovereignty and PIPEDA duties).

For businesses using outside providers, jurisdiction should be part of the discussion. OpsGuru's overview explains that data residency is not the same as data sovereignty, and that contractual safeguards and Transfer Impact Assessments can matter when foreign providers are involved (data sovereignty versus residency in Canada).

If you want practical next steps for employee habits, our guide to avoiding phishing emails at work pairs well with a quishing policy.

Staying Vigilant in a QR-Code World

Quishing works because it hides an old scam inside a familiar format. The QR code isn't the problem on its own. The problem is an unverified destination combined with a moment of trust.

The safest mindset is calm scepticism. If a code arrives unexpectedly, asks for credentials, or pushes you toward urgent action, stop and verify through a separate channel. That one habit will prevent many of the most common attacks.

We should also be honest about limits. No filter catches everything, and no user spots every trick. Good protection comes from layers: better filtering, stronger policies, clearer training, careful mobile habits, and a provider that treats privacy and security seriously.

Last updated: July 2026.

---

If you want an email provider that keeps quishing incident data and email metadata under Canadian jurisdiction for compliance and incident response, Typewire is built for this. We run our own infrastructure in Vancouver, keep all data in Canada, and focus on straightforward, ad-free email designed around privacy and PIPEDA compliance.

An email header is the hidden technical data attached to every email, and it acts like a digital passport that shows where the email came from, the path it took, and whether it's authentic. It also includes the checks mail systems use to decide whether to trust a message, and over 90% spam reduction is tied to DMARC-based handling when authentication fails or passes correctly, according to the source cited below.

You're usually looking for this stuff when something feels off. Maybe you got an invoice from a supplier that uses the right logo but a strange tone. Maybe a password reset email arrived when you didn't ask for one. The header is where you stop guessing and start checking.

Email users typically only see the friendly parts of an email, like the sender name and subject line. That view is useful, but it's also easy to fake. The header shows the less glamorous details that matter more for security, such as the route the message took, the systems that handled it, and whether sender checks passed.

That matters for privacy too. If you care where your email metadata lives, header details can reveal server paths and jurisdictions in ways most generic guides ignore. In Canada, that becomes part security question, part data sovereignty question under PIPEDA.

Last updated: 6 July 2026

What Is an Email Header

An email header is a hidden block of code and metadata that travels with every email. It contains required fields like From, To, Date, and Subject, and it records the technical path a message took through the internet. Proton explains that each email includes a header block at the top that records timestamps from every Mail Transfer Agent, or MTA, that handled it, creating a complete audit trail of the message's journey in its guide to email headers.

That sounds technical, but the basic idea is simple. Think of the message body as the letter you wrote, and the header as the envelope plus every postmark stamped on it during delivery. The body tells you what the sender wants you to read. The header tells you whether the trip looks legitimate.

Why headers exist at all

Email wouldn't work without headers. Mail systems need routing information to know where to deliver a message, how to process it, and whether it matches basic trust rules. Without that information, you couldn't reliably tell who sent the message, when it was sent, or which systems touched it along the way.

Headers also help email providers separate real mail from junk. They include information that lets mailbox providers authenticate senders and decide whether a message belongs in your inbox or your spam folder. That's why people in deliverability, IT, and security spend so much time reading them.

Practical rule: If the visible sender name looks trustworthy but the message still feels wrong, the header is usually where the story changes.

What you can and can't see

In a normal inbox view, you only see a tiny slice of the header. You see the sender, recipient, date, and subject because those are the human-friendly fields. The rest is hidden because raw header text is dense and full of technical lines.

Once you open the full header, you'll see entries added by different mail servers over time. That trail can show the actual route of a message, which is useful for troubleshooting and for finding a fake sender. It can also expose where processing happened, which matters if your organization has residency requirements.

Here's a simple explanation:

Part	What it means	Why it matters
Visible fields	From, To, Date, Subject	Basic context for the reader
Routing fields	Received, Return-Path, Message-ID	Shows where the email actually travelled
Authentication fields	SPF, DKIM, DMARC results	Helps confirm whether the sender is genuine

When people ask what is an email header, they're often really asking a more useful question. Can this hidden data help me decide whether an email is real? The answer is yes. Not perfectly, and not always instantly, but often enough that it's one of the most practical anti-phishing habits you can build.

Key Fields in an Email Header Explained

Once you open a full header, it can look like a wall of machine text. Don't try to read every line at once. Start with a few fields that answer the most important questions: who claims to have sent the message, who handled it, and whether authentication checks passed.

The simple fields you already know

From is the address the sender wants you to see. It's the display identity, not always the true sending source. Attackers know recipients often trust this field too quickly.

To shows the intended recipient. If a message was sent to several people, the header can list multiple names and addresses. That can help you spot odd distribution patterns, especially when a message claims to be private but clearly wasn't.

Date records when the message was sent. Subject records the topic line. These sound ordinary, but they're still useful when you're checking whether a message matches the timing and context you'd expect.

The fields that tell the real delivery story

Return-Path is where delivery errors and bounce messages go. In a legitimate email, this often lines up with the sender's domain or an authorised sending service. If the From address says one thing and the Return-Path points somewhere unrelated, slow down.

Message-ID is a unique identifier for a specific email. You don't need to decode it in detail, but it can help show whether a message was generated by a real system or by a rough imitation. A strange-looking or generic ID doesn't prove fraud on its own, but it can add weight to other warning signs.

Received is one of the most useful fields in the whole header. Each mail server that handles the message adds a new Received line, usually with timing and server details. Read it as a chain of handoffs. It helps you trace where the message came from instead of trusting the polished display name in the inbox.

The visible sender can be staged. The Received chain is much harder to fake convincingly across every hop.

The authentication fields that matter most

The key line here is Authentication-Results. This field shows the output of SPF, DKIM, and DMARC checks. Mailtrap notes that a pass means the sender's IP is authorised by the domain, while a fail can trigger rejection or quarantine by email gateways, reducing spam delivery rates by over 90% under DMARC standards in its breakdown of email headers.

If those acronyms feel abstract, here's a plain-language version:

• SPF checks whether the sending server is allowed to send on behalf of the domain.

• DKIM adds a cryptographic signature to help prove the message wasn't changed in transit.

• DMARC tells receiving systems what to do when SPF or DKIM doesn't align properly.

A useful analogy is physical ID. SPF is like checking whether the courier works for the company they claim to represent. DKIM is like a tamper seal on the package. DMARC is the company policy that tells the front desk whether to accept, quarantine, or reject the package if anything doesn't line up.

If you want a clearer mental model for signed messages and trust chains, our guide to digital signatures and PKI fills in the background without getting lost in jargon.

A quick field-by-field cheat sheet

Header field	What to check	What it can tell you
From	Does the visible sender match what you expected?	Easy to fake, so treat it as a starting point
Return-Path	Does it broadly align with the sender's domain?	Mismatches can signal spoofing
Received	Does the route make sense?	Helps you find sender IP and trace origin
Message-ID	Does it look tied to a real sending system?	Odd patterns can support suspicion
Authentication-Results	Do SPF, DKIM, and DMARC pass?	One of the strongest trust signals in the header

People often assume email header analysis is only for administrators. It isn't. If you can compare names, domains, and pass or fail results, you can catch a surprising number of scams before they catch you.

How to View Email Headers in Gmail and Outlook

Finding the raw header is easier than you might anticipate. You don't need a special admin panel or a developer tool. In most cases, it takes a few clicks.

Mailjet's instructions are clear on the basic steps. In Gmail, click the three-dot menu beside the reply button and choose Show Original. In Outlook on the web, click the three dots in the upper right and select view message source, as described in Mailjet's email header guide.

Gmail

Open the email first. Then click the three-dot menu near the reply button, not the browser menu, and choose Show Original. Gmail opens a new view that shows the full technical log, including routing and authentication details.

That screen can look intimidating at first. Don't read from top to bottom like a normal message. Scan for the fields covered above, especially From, Return-Path, Received, and Authentication-Results.

Outlook

In Outlook on the web, open the email, click the three dots in the upper right, and select view message source. If you use the Outlook desktop app, the process is a bit clunkier. You open the message in its own window, right-click file, choose properties, and then look for internet headers near the bottom.

One useful habit: when a message feels suspicious, save the full header before you delete anything. It's much easier to review or share later.

What you're looking at

The first time you view headers, it may feel like someone dumped a printer log into your inbox. That's normal. You don't need to understand every field to get value from it.

Start with three checks:

1. Visible identity. Does the From address match what you expected?

2. Delivery path. Do the Received lines look consistent with the claimed sender?

3. Trust checks. Does Authentication-Results show pass or fail for SPF, DKIM, and DMARC?

If you only do those three things, you're already reading headers more effectively than most users.

How to Spot a Spoofed Sender

A spoofed email is a message that pretends to come from someone trusted. The sender name looks familiar, the branding may look right, and the wording might be close enough to trigger a rushed click. Header analysis helps you look past the costume.

A common situation goes like this. You receive an invoice from a supplier you recognise. The display name matches the company, and the message asks you to open an attachment before end of day. If you only judge the message by the visible sender line, you might miss the trap.

Compare what the email says with what the header shows

Start with From and Return-Path. If the email claims to be from your supplier but the Return-Path points to a different domain or a sending pattern that makes no business sense, that's a strong warning sign.

Then check the Received chain. You're looking for whether the delivery path fits the story. If the sender claims to be a normal billing address but the route suggests an unexpected origin or a path that doesn't fit prior legitimate messages, don't trust the invoice.

After that, look at Authentication-Results. A fail doesn't always mean a message is malicious, but it does mean the message failed an important trust check. If it also has a mismatched Return-Path or an odd Received chain, the risk goes up quickly.

Why this matters now

This isn't just a niche problem. According to the 2025 Canadian Anti-Fraud Centre report, 57% of verified email fraud cases in Canada involved forged authentication headers, and 31% of victims were small businesses using ad-free email services, as cited in Campaign Monitor's email header explainer.

That number matters because many tutorials stop at “check the sender address.” That isn't enough anymore. Modern phishing attempts often mimic the visible parts well and hide the inconsistencies in technical fields that most users never open.

If you want to understand one of the core policies behind those pass or fail results, our article on DMARC and simpler email security is a good follow-up.

A short walkthrough helps:

• The display name looks right. You receive “Accounts Payable” from a known company.

• The urgency feels engineered. The message pushes you to act fast, often before you verify.

• The header tells a different story. Return-Path doesn't line up, Received looks off, or Authentication-Results fails.

Here's a practical checklist you can use when you need to detect spoofed email fast:

Check	What to compare	Red flag
From vs Return-Path	Visible sender and bounce path	Different or unrelated domains
Received chain	Claimed source and actual route	Delivery path doesn't fit sender story
Authentication-Results	SPF, DKIM, DMARC	One or more failures
Message-ID	Format and consistency	Looks generic or unusually odd

Before you look at the example video below, keep one point in mind. A single strange field doesn't always prove fraud. Several small inconsistencies together usually matter more than one dramatic clue.

If the email pressures you to act now, header mismatches deserve extra weight. Attackers rely on speed and distraction.

Tools to Analyse Headers

Raw headers are useful, but they're not pleasant to read. Long chains of fields, odd spacing, and technical labels can make even a simple message look suspicious. That's why header analysis tools are worth using.

A good parser takes the raw header text and turns it into something readable. Instead of hunting through a text wall, you get a cleaner view of routing hops, authentication results, and possible issues. That makes it easier to find sender IP clues, spot alignment problems, and understand whether a message was authenticated.

When a tool helps most

Manual reading is still valuable when you know exactly which fields to check. A tool helps when you need speed, when you're sharing findings with someone less technical, or when the header is especially messy.

Popular options include tools from MXToolbox and Google Admin Toolbox Messageheader. We're mentioning them as examples because they make the same basic job easier. Paste in the header, review the parsed output, and then compare the cleaned-up report with what the message claimed on its face.

Here's the practical benefit:

• Clearer routing view so the Received chain is easier to follow

• Pass or fail summaries for authentication checks

• Faster triage when you need to decide whether to trust a message

• Better communication when you need to show a colleague why an email looks wrong

Best use case: use a parser for speed, then sanity-check the raw header if something important looks off.

Tools don't replace judgement. They make good judgement easier to apply.

How We Protect Your Privacy in Email Headers

Headers don't just reveal delivery details. They can also reveal metadata about where a message was processed and which systems handled it. For privacy-conscious users and organizations, that matters because metadata can cross borders even when the message content is encrypted.

That's one reason data residency comes up in header discussions more often now. Many Canadian organizations remain uncertain about whether email header metadata stored on US servers violates PIPEDA data sovereignty requirements. If you're responsible for business email, that uncertainty isn't abstract. It affects procurement, compliance reviews, and incident response.

The privacy side of header analysis

A lot of US-centric guides treat headers only as a deliverability or anti-phishing tool. That misses part of the story. Header paths can expose where processing happened, which may raise legal and operational questions when your organization wants mail and metadata kept under Canadian jurisdiction. That's also why people compare PIPEDA with foreign access regimes such as the US CLOUD Act. The message body gets most of the attention, but metadata matters too. When you review headers, you're not only checking authenticity. You're also seeing where control may leave your preferred jurisdiction.

Typewire was built around this exact concern. We operate our own infrastructure in Vancouver, Canada, so email and header metadata stay under Canadian jurisdiction rather than moving through third-party cloud platforms. That way, the full audit trail—including routing details, timestamps, and authentication records—remains under Canadian control.

We also block spy pixels, which helps reduce another common source of quiet metadata leakage. That doesn't make email magically private in every sense, and we won't pretend otherwise. Email always involves trade-offs between openness, compatibility, and control.

What we can do is keep those trade-offs honest, visible, and aligned with privacy-first email hosting.

---

If you want an email service that keeps header metadata and message content in Canada under Canadian privacy law, explore Typewire. We host everything in Canada, focus entirely on email, and give individuals and small businesses a simpler way to send and receive mail without data mining or ecosystem bloat.