QR code phishing (quishing)

28 March 2026 · 14 min read

Quishing is phishing that hides its payload inside a QR code. Instead of a clickable link in the message body, the attacker sends an image of a square matrix of black and white modules, and asks the recipient to point their phone camera at it. The phone decodes the embedded URL and opens it, often in the mobile browser, away from every control the corporate mail gateway and endpoint protection are watching. The lure is the same as classic phishing: a fake login, a fake invoice, a fake multi-factor prompt. The delivery mechanism is what makes quishing slippery, and it is specifically the delivery mechanism that interacts with email authentication in ways worth understanding.

This article is not a generic phishing explainer. It is about the precise reason QR codes get past content filters that would have caught the same URL as text, why the move from desktop to a personal phone is the entire point of the attack, and where DMARC, SPF and DKIM actually help and where they categorically do not. If you have just taken your domain to p=reject and assume image-based phishing is now somebody else's problem, the honest answer is: partly yes, partly no, and the distinction is the difference between blocking an attack and merely watching it land.

Why a QR code defeats filters that catch the same link as text

A traditional phishing email carries its hostile URL as text or as an href inside an anchor tag. Every secure email gateway in the world knows this. They extract URLs from the body, the headers and the HTML, then check them against reputation feeds, detonate them in a sandbox, rewrite them through a click-time proxy, or simply block the message if the destination is known-bad. URL extraction and rewriting is one of the most mature parts of email security.

A QR code breaks that pipeline at the very first step. The URL is not text in the message. It is a picture. The decoded payload, the actual https://... string the victim will visit, exists only as a pattern of light and dark squares inside a JPEG, PNG or, increasingly, an embedded SVG or an attached PDF. To recover it, the filter has to:

1. Notice that an inline image or attachment might contain a QR code at all.
2. Run optical decoding on every candidate image to extract the embedded data.
3. Parse that data as a URL.
4. Submit the recovered URL to the same reputation and sandbox checks it would have run on a text link.

Many gateways historically did none of this, and even those that do it now do it imperfectly. Attackers respond to each defensive step:

• They degrade the image. Adding noise, lowering contrast, distorting the matrix slightly or overlaying a logo in the centre can defeat a decoder while remaining perfectly scannable by a phone camera, which is engineered to be forgiving.
• They embed the code in a PDF or an Office document. Now the filter must open the attachment, render it, locate the image inside the rendered page, then decode it. Each layer is another place to fail.
• They render the QR code in HTML or SVG. A QR matrix drawn with hundreds of tiny <rect> elements or table cells is never an image file the decoder looks at, yet it renders as a scannable code in the mail client.
• They use a benign redirector. The decoded URL points at a reputable open-redirect, a legitimate URL-shortener, or a trusted cloud-document host, so even a recovered-and-checked URL passes reputation, then bounces the victim onwards to the real payload.

The result is an email whose dangerous component is invisible to the part of the stack that is best at catching dangerous components. The text of the message is usually clean: a short, plausible note about a voicemail, a payslip, a shared document, a mandatory security update or a docusign-style signature request, plus an instruction to scan the code.

The device pivot is the attack, not a side effect

The single most important thing to understand about quishing is that asking the victim to use their phone is not incidental. It is the strategic heart of the technique.

When a link is clicked on a managed corporate laptop, it opens in a managed browser on a managed network. That environment may have endpoint detection, a web proxy that inspects and categorises the destination, browser extensions that warn on known phishing, conditional-access policies, and DNS filtering that blocks newly registered or low-reputation domains. The click happens inside a fortified perimeter.

A QR code moves the click onto a personal mobile phone, and almost everything in that list evaporates:

• The phone is usually on mobile data or home Wi-Fi, not the corporate network, so the web proxy and DNS filtering never see the request.
• Mobile browsers show a truncated address bar. On a small screen a long, deceptive URL like login.microsoft.com.account-verify.example/... shows only the leading, reassuring part.
• Phishing pages are frequently tuned to look right on mobile, where users are more habituated to logging in quickly and less likely to scrutinise.
• Personal phones often lack the endpoint agent, so there is no local detection of the credential-harvesting page or of any follow-on malware.

So the QR code is a teleporter. It lifts the victim out of the monitored, defended desktop environment and drops them onto an unmonitored device, precisely at the moment they are about to type a password or approve a multi-factor request. A growing share of quishing campaigns are after exactly that: the credential plus the MFA approval, captured in real time through an adversary-in-the-middle proxy so the attacker can mint a valid session.

Where email authentication fits, honestly

This is where it pays to be precise, because quishing sits across a line that DMARC draws very sharply. There are two completely different scenarios, and your authentication posture matters enormously in one and not at all in the other.

Scenario one: the attacker spoofs your domain

If the quishing email claims to come from your domain, for example an internal-looking message from it-helpdesk@yourcompany.example telling staff to scan a code to re-validate their account, then email authentication is directly relevant. This is ordinary domain forgery; the only unusual thing is that the payload is a QR image rather than a text link.

Here, DMARC at enforcement does its job. The mechanics are the same as for any spoof:

• SPF checks the sending IP against the authorised senders for the envelope domain. This is the first layer of email-spoofing defence; confirm your record with the SPF checker.
• DKIM verifies a cryptographic signature against the public key in your DNS, which an external attacker cannot produce. Validate yours with the DKIM checker.
• DMARC requires the visible Header-From to be aligned with an authenticated SPF or DKIM domain, then applies your published policy. A forged yourcompany.example with no valid signature and an unauthorised IP fails alignment, and at p=reject it is refused outright.

So a domain at p=reject with healthy SPF and DKIM blocks the entire class of quishing emails that try to wear your domain. The QR code never reaches the inbox because the message carrying it is rejected at the SMTP boundary. Confirm where you stand with the DMARC checker, and read your aggregate data through the DMARC report analyzer so a sudden burst of forgery attempts, often the reconnaissance phase before a campaign, becomes visible rather than buried. The requirements overview walks through what reaching enforcement actually involves.

It is worth stressing why this matters for quishing specifically. An internal-looking IT or HR message is one of the most effective quishing pretexts, because staff expect occasional account-maintenance requests and a QR code feels modern rather than suspicious. If your own domain can be forged, that pretext is free and devastating. Enforcing DMARC removes the most convincing version of the lure from the attacker's toolkit.

Scenario two: the attacker uses a domain that is not yours

Most quishing does not bother forging your exact domain, especially once you enforce. Instead the message comes from:

• A throwaway or compromised third-party domain the attacker fully controls, on which they publish their own perfectly valid SPF, DKIM and DMARC.
• A compromised legitimate account at a real, reputable organisation, where the mail is genuinely authenticated by that organisation's infrastructure.
• A look-alike or cousin domain that resembles a brand the victim trusts, again with its own valid authentication.
• A trusted bulk sender or file-sharing service the attacker has signed up to, sending real, authenticated mail that simply happens to contain a hostile QR code.

In every one of these cases, email authentication passes, because the message really is from the domain it claims to be from. DMARC proves integrity and alignment of a single domain; it does not judge whether that domain is trustworthy or whether the picture in the body is hostile. A QR code sent from an attacker-owned domain at p=reject sails through SPF, DKIM and DMARC exactly as designed, because none of those mechanisms inspects the image, decodes the URL or evaluates the destination.

This is the same structural limitation that makes display-name spoofing and look-alike domains work. Authentication answers "did this really come from the domain in the From header, unmodified?" It does not answer "should I trust the domain in the From header?" or "is the content safe?" Quishing from a foreign domain lives entirely in that gap. Your p=reject policy is not consulted, because the mail never claimed to be you.

So the honest framing is this: enforcing DMARC closes off quishing that impersonates you, which protects both your staff (internal-IT pretexts) and your customers (brand-impersonation pretexts that forge your exact domain). It does nothing about quishing delivered from domains you do not own, which is the larger share. Both statements are true at once, and a vendor who tells you DMARC stops quishing outright is overselling.

A worked example

Suppose your company is northwind.example and you have reached enforcement: p=reject, aligned SPF and DKIM, reports flowing in.

An attacker wants staff credentials. Their first instinct, an email from security@northwind.example saying "Scan to re-enrol your authenticator before Friday or lose access", is now dead on arrival. They forge your domain, the message fails DMARC alignment, and your enforcement policy rejects it. The most convincing pretext, an internal one, is off the table precisely because you enforce.

So they pivot. They register northw-ind-it.example, or compromise a small supplier's mailbox, and send:

From: IT Service Desk <helpdesk@northw-ind-it.example>
Subject: Action required: re-validate your Microsoft 365 access

Your session expires in 24 hours. Scan the code below with your
phone to confirm your identity and avoid interruption.

[ QR code image ]

On northw-ind-it.example they publish:

v=spf1 include:_spf.attacker-sender.example -all
selector._domainkey.northw-ind-it.example  IN TXT "v=DKIM1; k=rsa; p=MIID..."
_dmarc.northw-ind-it.example  IN TXT "v=DMARC1; p=reject; rua=mailto:..."

The message passes SPF (their IP, their record), passes DKIM (their key, their signature) and passes DMARC (Header-From aligned with their own authenticated domain). It lands. A member of staff scans the code on their personal phone, off the corporate network, and is taken to an adversary-in-the-middle page that proxies the real Microsoft login, harvests the password, relays the MFA prompt and steals the resulting session token.

Your northwind.example DMARC record was never evaluated, because the mail never claimed to be from northwind.example. What would have helped here is not a DNS record on your domain but the layered defences below: a gateway that decodes inline QR images and checks the recovered URL, user training that treats "scan this code with your phone" as the red flag it has become, phishing-resistant authentication that an AiTM proxy cannot replay, and monitoring that flags the newly registered look-alike before the campaign runs.

Technical defences against quishing

Because much of the quishing problem lives outside what DMARC can touch, the defence is layered. Authentication is the foundation, not the whole building.

Get your real domain to enforcement

Start here, because it removes the strongest pretext. A domain stuck at p=none lets attackers forge your exact address for free, and an internal "scan to keep your access" message from your own domain is the most credible quishing lure there is. Take the domain to p=reject with aligned SPF and DKIM so direct forgery stops working. Confirm the posture with the DMARC checker, generate or tighten the record with the DMARC generator, and use continuous monitoring with change alerts so a regression or a new failing source is caught quickly rather than at the next quarterly review.

Make the gateway decode QR images

Ask your secure email gateway vendor a direct, specific question: do you optically decode QR codes in inline images, in attached images, inside PDFs and inside Office documents, and do you then submit the recovered URL to the same reputation and sandbox checks as a text link? The answer separates products that address quishing from those that quietly ignore it. The capability has matured considerably, but it is not universal and it is not always on by default. Where it exists, also confirm it handles low-contrast and logo-overlaid codes, since those are the common evasions.

Treat inbound QR codes as suspicious by policy

Several organisations now strip or flag inbound emails that contain QR codes, or rewrite them with a warning banner, on the reasonable basis that legitimate business email rarely needs the recipient to scan a code with a phone. A blanket "this message contains a QR code, do not scan it unless you were expecting it" banner is crude but effective, because it reintroduces friction at exactly the teleport point the attacker is relying on.

Deploy phishing-resistant authentication

Quishing increasingly targets the credential-plus-MFA pair through real-time proxies. App-prompt and one-time-code MFA can be relayed by an adversary-in-the-middle page; the user approves, and the attacker captures the session. Authentication bound to the origin, such as FIDO2 or passkeys, cannot be replayed against a look-alike domain, because the credential simply will not release to the wrong origin. This is the single most effective control against the credential-theft outcome, and it neutralises the device-pivot advantage: even a successfully scanned, perfectly convincing page cannot complete the login.

Hunt look-alike domains and read your reports

Because Scenario-two quishing often rides on a look-alike domain, enumerate the confusable and cousin variants of your brand and watch for new registrations and certificates with the look-alike domain checker. On the authentication side, feed your aggregate data into the DMARC report analyzer; while the foreign-domain quishing will not appear there, attempts to forge your exact domain will, and a spike often precedes a wider campaign. When reports surface senders you do not recognise, the guidance on DMARC reports that show unknown sources helps you triage them.

Give recipients a trust signal a forger cannot copy

For mail you send to the outside world, a reliable visual marker for genuine messages makes a forgery that lacks it easier to question. BIMI displays your verified logo beside authenticated, DMARC-passing mail from your real domain, and a look-alike or foreign domain cannot reproduce it. It is a partial signal, since logo support varies by mailbox provider and absence is weaker evidence than presence, but it raises the bar. Set it up via the BIMI product page and verify with the BIMI checker.

User defences: what to teach people

Technical controls reduce volume; they do not reach zero. The human at the camera is the last line, so the training has to target the specific shape of quishing rather than generic "do not click links" advice that does not obviously apply to a picture.

• "Scan this code with your phone" is itself the warning sign. Legitimate internal IT, HR and finance processes almost never require staff to scan a QR code out of an email to log in or approve something. Treat the instruction, not just the destination, as suspicious.
• Never authenticate after scanning a code from email. If a scanned code leads to a login page or an MFA approval, stop. Reach the service the normal way: a saved bookmark, the official app, or a typed address. Genuine services do not depend on an emailed QR code to reach their own login.
• Check the full URL before trusting it, knowing the phone hides it. Expand the truncated mobile address bar and read the real registrable domain, the part immediately before the TLD. microsoft.com.verify-login.example is not Microsoft.
• Be most careful with urgency and account-loss framing. "Expires in 24 hours", "avoid interruption", "mandatory re-enrolment" are pressure tactics designed to bypass scrutiny. Urgency plus a QR code is a near-certain combination to report.
• Report, do not just delete. A reported quishing message lets the security team pull the campaign for other recipients, block the destination and check whether anyone scanned it. Make reporting a single, obvious action.
• Posters and printed codes are in scope too. Quishing is not only email. Stickers placed over legitimate QR codes on parking meters, restaurant tables and posters use the same trick in the physical world. The same rule applies: do not authenticate or pay through a scanned code you did not initiate.

The thread tying all of this together is that the QR code's job is to move a person from a defended device to an undefended one at the moment of decision. Good training names that move explicitly, so the habit becomes "I was told to scan a code to log in, therefore I stop", rather than relying on the person to out-analyse a page that has been engineered to look correct.

The practical takeaway

Quishing is a delivery innovation wrapped around an old goal. The QR code smuggles a hostile URL past the URL-aware parts of your mail stack by turning it into a picture, then teleports the victim onto a personal phone where the corporate defences do not reach, right as they are about to hand over a credential and an MFA approval. Understanding it means separating the two cases cleanly: when the lure forges your domain, DMARC at p=reject with aligned SPF and DKIM stops it dead, and that is reason enough to enforce, because the internal-IT pretext is the most dangerous one; when the lure comes from a domain the attacker legitimately controls, authentication passes and your policy is never consulted, so the work moves to the gateway, the device, the credential and the human.

So the strategy is layered, not a single switch. Reach enforcement on your own domain so the impersonation route closes. Make your gateway decode QR images and check what they hide. Treat inbound codes as suspicious by policy and train people that "scan this to log in" is the red flag. Deploy origin-bound, phishing-resistant authentication so a stolen credential cannot be replayed. Hunt the look-alike domains that carry the rest, and give recipients a visual trust signal a forger cannot copy.

Start by confirming where your domain stands today with the DMARC checker, then watch for impersonation attempts and authentication drift with continuous monitoring. If you would rather not run the enforcement, monitoring and look-alike hunting yourself, our done-for-you DMARC service takes your domain to p=reject without breaking legitimate mail and keeps watch, so the quishing campaign that forges your domain is something the policy stops, not something your staff discover after they have scanned.