Gift card scams over email

8 April 2026 · 13 min read

Of all the fraud that arrives by email, the gift card scam is the one that feels too silly to work, right up until it works. Someone gets a short, slightly breathless message from a name they recognise, usually a manager, a chief executive or a senior partner, asking them to nip out and buy a few hundred pounds of gift cards for a client gift or a staff reward, then send back the codes. No malware, no dodgy attachment, no login page. Just a request, a deadline and a name. By the time anyone scratches the surface codes off and reads the numbers aloud over the phone, the money is gone and it is not coming back.

This article is not a general explainer about phishing or about DMARC. It is specifically about the gift card variant of business email compromise: why criminals choose gift cards as the cash-out, the precise email mechanics that get the message in front of a victim, why so many of these campaigns lean on look-alike domains and display-name tricks rather than forging your real domain, and what you can actually do at the DNS and authentication layer to shrink your exposure. Email authentication does not solve this on its own, and pretending otherwise would be dishonest. But it removes the cheapest attack path, and that matters more than it first appears.

Why gift cards, specifically

Gift cards are the cash-out method of choice for low-sophistication, high-volume fraud for a few very practical reasons, and understanding them tells you why the email is shaped the way it is.

• They are irreversible. A bank transfer can sometimes be recalled, a card payment can be charged back, but a gift card code, once redeemed or sold on, is gone. There is no clearing window, no dispute mechanism, no intermediary you can call.
• They need no banking infrastructure. A money-mule bank account can be frozen and traces back to a person. A gift card needs none of that. The attacker never has to launder funds through an account in anyone's name.
• They are liquid on secondary markets. Codes for popular retailers and platforms sell quickly at a discount on resale and cryptocurrency-adjacent marketplaces, converting to clean money fast.
• They feel mundane to the victim. A wire transfer to an unfamiliar account triggers caution and often a second approver. Buying a few shop gift cards feels like a small errand, not a financial transaction, so it slips past the instincts that would catch a payment.

That last point shapes the whole email. The attacker is not trying to look like a bank or a software vendor. They are trying to look like a busy colleague making a small, slightly awkward request. The ask is deliberately low-value enough to stay under the threshold where someone would stop and verify, and the urgency is engineered so the victim acts before reflecting.

The anatomy of a gift card BEC message

These messages are remarkably consistent because the formula works. Recognising the shape is half the defence.

A typical opener:

From: Jane Okafor <jane.okafor.ceo@gmail.com>
Subject: Quick favour
Are you at your desk? I need you to handle something for a client,
I'm in back-to-back meetings and can't talk. Let me know.

Notice what is and is not there. There is no link, no attachment, no obvious payload, which is exactly why content filters that hunt for malicious URLs and files often wave it straight through. The only thing the attacker is investing in this first message is the establishment of identity and urgency. If the victim replies, the conversation escalates:

Thanks. I need to send some gift cards to a client as a thank-you.
Can you pick up 5 x £100 Amazon gift cards from the shop? I'll
reimburse you on Friday's expenses. Once you have them, scratch the
back and send me photos of the codes. This is time-sensitive so
please treat it as priority. Keep it between us for now, it's a
surprise.

Every sentence is doing a job. "I'll reimburse you" removes the financial objection. "Time-sensitive" and "priority" suppress reflection. "Keep it between us" prevents the single most effective control, which is the victim turning to a colleague and asking "is this real?". "It's a surprise" gives an innocent reason for the secrecy.

The whole campaign is cheap to run at scale. The attacker scrapes a target organisation's structure from a corporate website, a professional network, or a press release, identifies who reports to whom, and pairs the most plausible authority figure with the most likely person to comply: often someone in finance, an executive assistant, or a new starter who does not yet know it is unusual. None of this requires technical skill. It requires a name, a context and a sending address that looks close enough.

The address is where email authentication enters the picture

Here is the crucial question for anyone responsible for a domain: where does that From address come from, and could authentication have stopped it? The answer depends entirely on which of three address strategies the attacker uses, and they are not equally affected by your DMARC posture.

Strategy one: free webmail with a spoofed display name

The most common gift card BEC does not touch your domain at all. The attacker registers a free mailbox and sets the display name to your executive's real name:

From: "Jane Okafor (CEO)" <jane.okafor.work2026@gmail.com>

On a phone, most mail apps show only the display name, "Jane Okafor (CEO)", and hide the actual address behind a tap. The recipient sees a familiar name and a plausible request. This is display-name spoofing, and it is worth being blunt about a limitation people find uncomfortable: your DMARC policy cannot stop this. The message is genuinely from gmail.com. It passes SPF, DKIM and DMARC for gmail.com, because it really is Gmail's mail. Your domain is never claimed in the From header, so your p=reject is never consulted. Authentication proves a message came from the domain it claims; here the domain it claims is the attacker's free mailbox, and that claim is true.

This is the same fundamental gap described for homograph and IDN look-alike domains: the failure is one of human trust and visual judgement, not of cryptographic integrity. DMARC is doing its job perfectly. The job simply is not this one.

Strategy two: a look-alike domain

The more polished operator registers a domain that resembles yours, because a corporate-looking address is far more convincing than a webmail one, especially to recipients trained to "check the domain, not the display name". If your company is northwind.example, they register something like:

northwind-corp.example
northwinds.example       (added "s")
n0rthwind.example        (zero for "o")
northwind.example.co     (different TLD, real name as a subdomain label)

Then they send jane.okafor@northwind-corp.example. To a hurried reader, that is your company. And critically, the attacker publishes their own valid SPF record and DKIM keys on the look-alike domain and sets its DMARC policy to p=reject. So the message passes every authentication check, because it is authentically from a domain the attacker fully controls. Again, your DMARC record on northwind.example is never consulted, because the message never claims northwind.example. This is why look-alike domains are the natural next step: they buy the credibility of a corporate sender while remaining completely outside the reach of your authentication. The glossary entry on look-alike and cousin domains goes into the registration patterns in more depth.

Strategy three: forging your exact domain

The cheapest attack of all, if it works, is to put your real domain in the From header: jane.okafor@northwind.example, sent from infrastructure that has nothing to do with you. This is classic email spoofing, and it is the one strategy that your DMARC policy directly defeats. If northwind.example publishes a DMARC record at enforcement, a forged message that claims your domain but cannot align an authenticated SPF or DKIM identity is rejected or quarantined by every compliant receiver before it reaches the inbox.

The reason this matters so much for gift card scams specifically: forging your exact domain is free and needs no registration, so it is the path of least resistance. If you leave your domain at p=none, you are handing attackers the cheapest, most convincing version of the scam, an email that genuinely appears to come from jane.okafor@northwind.example with no tell at all. Closing that path is the single highest-leverage thing email authentication does against gift card BEC. You can confirm exactly where your domain stands with the DMARC checker.

Why "look-alike" is the centre of gravity

Put the three strategies together and a clear pattern emerges. The better defended your real domain is, the more attackers are pushed towards look-alikes and webmail, because direct forgery stops being an option. That is not a failure of DMARC; it is DMARC working. Direct domain forgery is the cheapest method, so removing it is the highest-value move even though it does not address the other two paths.

But it changes the threat you are left facing. Once your domain is at p=reject, the residual gift card risk is dominated by:

1. Free webmail with a spoofed display name, which no DNS record can block, and
2. Look-alike domains, which authenticate perfectly because they belong to the attacker.

Both of these live in the rendering layer and in human judgement, not in your authentication. So the honest strategy is two-part: use authentication to slam the cheap door shut, then build the human and monitoring controls that address the doors authentication cannot reach. Anyone who tells you DMARC alone stops gift card fraud is selling you something.

What you can do at the authentication layer

These are the moves that genuinely reduce exposure, in rough order of leverage.

1. Get your real domain to p=reject

This is non-negotiable and it is the foundation. While your domain sits at p=none, an attacker can forge jane.okafor@northwind.example exactly, and the resulting email is the most convincing gift card lure possible because there is literally nothing wrong with the address. Moving to enforcement removes that entire category.

The work is not "flip the policy and hope". It is the staged enforcement journey: publish a monitoring record, read the aggregate reports to discover every legitimate sender, fix SPF and DKIM alignment for each, then tighten from p=none to p=quarantine to p=reject once the reports are clean. Rushing it breaks real mail; skipping it leaves the door open. Verify your current SPF with the SPF checker and your DKIM with the DKIM checker.

2. Set a subdomain policy

Attackers sometimes target a subdomain you do not actively use, betting that it inherits a weaker policy or none. Publish an explicit subdomain policy so that names you do not send mail from are also covered:

_dmarc.northwind.example.  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@northwind.example"

The sp=reject tag tells receivers to reject mail for any subdomain that does not publish its own policy. It closes a quiet gap that a "from accounts@billing.northwind.example" lure might otherwise slip through.

3. Read your reports for reconnaissance and forgery attempts

Your aggregate reports will not contain the look-alike domain or the webmail message, because neither claims your domain. What they will surface is attempts to forge your exact domain, which often precede or accompany a campaign, and the appearance of unfamiliar sending sources. Feed your RUA data into the DMARC report analyzer so the raw XML becomes source-by-source detail, and a spike in forged-domain attempts becomes a visible early warning rather than noise. The aggregate report analysis guide explains how to read what comes back.

4. Build and watch a look-alike list

You cannot defend against variants you have never enumerated. Generate the realistic permutations of your domain, the added letters, the digit-for-letter swaps, the alternative top-level domains, the hyphenated "corp"/"group"/"hr" suffixes, and check which already exist in DNS or hold a certificate. For the handful that are both cheap and highly convincing, especially those mapping to finance or executive workflows, defensive registration is rational: register the variant, point it nowhere, and deny it to attackers. You will never register them all, so the real value is in monitoring for new registrations of the rest.

5. Give genuine mail a visual trust signal

If recipients have a reliable cue for real mail from you, a look-alike that lacks it becomes easier to question. BIMI displays your verified logo beside authenticated, DMARC-passing mail from your real domain. A look-alike or webmail sender cannot show your verified logo, because it is bound to your domain's DMARC and, in the strict tiers, to a verified mark certificate. It is not a complete defence, logo support varies by mailbox provider and absence of a logo is a weaker signal than presence of one, but it gives a trained finance team something concrete to look for. The BIMI checker covers verification.

The controls authentication cannot provide

Because the residual risk after p=reject is display-name spoofing and look-alikes, the most effective remaining defences are human and procedural. They are not glamorous, but they are what actually stops the cash leaving the building.

• A no-exceptions gift card rule. The single most effective control is a written policy that the organisation never buys gift cards on the basis of an email request, full stop. If the answer is always no, the scam has nothing to exploit. Say it in onboarding, repeat it, and make sure new starters and executive assistants hear it first, because they are the prime targets.
• An out-of-band verification step. Any unusual financial or purchasing request, especially an urgent one, must be confirmed through a separate channel: a phone call to a known number, a message in a known internal system, never a reply to the email itself. The "keep it between us" instruction exists precisely to block this step, which tells you how important it is.
• Make urgency a red flag, not a trigger. Train people that a manufactured deadline plus secrecy plus an unusual request is the signature of fraud, not the signature of an important task. The combination is the tell.
• External-sender banners. Tag mail from outside your organisation with a visible banner. A message claiming to be from your internal chief executive but carrying an "external sender" warning is immediately suspect, and this catches both webmail and look-alike senders that authentication waves through.
• Report-and-it-is-fine culture. People must feel safe asking "is this real?" without looking foolish. The scam relies on the victim being too embarrassed or too rushed to check. Remove the embarrassment and you remove the attack's main lever.

A worked example

Suppose northwind.example runs finance from accounts@northwind.example and is fully at p=reject with aligned SPF and DKIM.

A direct forgery of cfo@northwind.example is rejected at every compliant receiver, so the attacker cannot use the cheapest method. Instead they register northwind-finance.example, publish their own SPF and DKIM and a p=reject DMARC record on it, and send:

From: "Daniel Mensah, CFO" <daniel.mensah@northwind-finance.example>
Subject: Urgent - client gift cards needed today

The message authenticates perfectly, because the attacker owns northwind-finance.example outright. Your DMARC on northwind.example is never consulted.

What stops it is everything authentication could not: the finance assistant had been told the company never buys gift cards from an email request; the external-sender banner flagged the message as coming from outside; the look-alike northwind-finance.example was already on a monitored watch-list because finance-themed variants had been enumerated; and the assistant phoned Daniel on his known number rather than replying. The request was reported, not actioned, and a registrar abuse complaint went out the same afternoon. The p=reject on the real domain had quietly done its part long before, by forcing the attacker onto a registered look-alike that the watch-list could catch, instead of a free, perfect forgery that nothing could.

The practical takeaway

Gift card scams are business email compromise stripped down to its cheapest, most human form: no payload, no malware, just a name, a deadline and an irreversible cash-out. They succeed because the request feels small and the secrecy is engineered to stop the one thing that would catch it, asking a colleague.

Email authentication is a necessary part of the defence but not a sufficient one. Getting your real domain to p=reject removes the cheapest and most convincing attack, a perfect forgery of your own address, and pushes criminals onto look-alike domains and free webmail that they fully control. That is real progress, but those residual paths authenticate perfectly and your DMARC record never sees them, so they have to be met with human controls: a no-exceptions gift card rule, out-of-band verification, external-sender banners and a culture where checking is normal. Layered on top, look-alike monitoring and a BIMI logo give your people something concrete to trust and something concrete to doubt.

Start by confirming where your domain stands today with the DMARC checker, then read your aggregate data with the DMARC report analyzer to see who is forging you. If you would rather not run the enforcement, reporting and look-alike monitoring by hand, our done-for-you hosting takes your real domain to p=reject without breaking legitimate mail and watches for the changes and new sources that signal a campaign, so the gift card lure your finance team gets next month arrives with the cheapest door already locked, and someone keeping an eye on the rest. You can also turn on emailed monitoring with change alerts to hear about drift the moment it happens.