An email lands from a name you know. Your board chair, your bank, your executive director. Before you have read a word of it, you have already relaxed a little.
That small moment of trust is what this kind of attack is built on.
The name is just a label
The name you see at the top of an email is a display name. Whoever sends the message types it in, and nothing checks it. Anyone can send an email that shows up as “Board Chair” or “Accounts Payable” or the name of your largest funder.
On a laptop you can usually see the full address next to the name if you look for it. On a phone you often see only the name. That is where most email is read now, usually between other things.
The domain is harder to fake, but close enough usually works
The part after the @ is the domain, and it is much harder to forge outright. Attackers don’t need to. They register one that looks close enough:
- yourorg.org becomes your-org.org
- yourorg.org becomes yourorg.co
- yourorg.org becomes yourorgg.org
Read quickly, on a small screen, by someone who is busy, all three pass. Some messages also set a different reply-to address, so the email appears to come from one place and your answer goes somewhere else.
Why “check the sender” isn’t enough
Most security training ends at “check the sender carefully.” It is good advice, and people should follow it. But a plan that depends on every person catching every fake, every time, on every device, is not much of a plan.
The stronger protections sit on the organization’s side, and most nonprofits either haven’t turned them on or turned them on halfway.
SPF, DKIM and DMARC in plain terms
These three settings live in your domain’s DNS records. Together they let other mail systems check whether a message claiming to be from your domain really is.
- SPF is a published list of the services allowed to send email for your domain.
- DKIM adds a digital signature to your outgoing mail, so the receiving system can confirm it came from an approved sender and wasn’t altered along the way.
- DMARC tells receiving systems what to do when a message fails those checks, and sends you reports about who is sending mail in your name.
DMARC has three policy settings. None means monitor only: failures are reported but still delivered. Quarantine sends failing messages to spam. Reject refuses them outright.
A lot of organizations set DMARC to none when they first configure it and never come back to it. That gives you reports but no protection. Someone could still send email to your donors that appears to come from your exact domain.
One caution before anyone flips the switch. Your newsletter platform, donation system and CRM may all send mail as your domain. If they aren’t listed in SPF and signed with DKIM, moving straight to reject will block your own mail. Read the reports, confirm every legitimate sender is covered, move to quarantine, and then to reject.
What this does and doesn’t cover
DMARC stops people from sending mail as your exact domain. It does nothing about lookalike domains, because those aren’t yours. That is where people still matter, and it is what the rest of this section is about: the requests that come from lookalike addresses, and the habits that catch them.
What to do this week
- Ask whoever manages your domain or email whether DMARC is set up, and which policy it uses: none, quarantine or reject.
- If the answer is none, or nobody knows, ask what it would take to move toward reject, starting with a list of every service that sends email as your domain.
- For everyone on staff: when a message asks for something unusual, look at the full address, not just the name. On a phone, tap the name to reveal it.
Next in this section: the request that sounds like your executive director.