Can I stop someone from putting my address in the From field?

No. The message is written on a machine you do not control, so nothing you configure prevents it being composed. What you control is what receivers do with it: a DMARC policy of reject tells them to refuse mail that claims your domain and cannot prove it. Gmail Help makes the same point about messages created outside Gmail.

Does DMARC stop someone using my name with a different email address?

No. RFC 9989 puts display name attacks out of scope, because DMARC checks the domain in the From header and not the human-readable name next to it. A lookalike domain is the same story: the attacker owns it, so it passes its own authentication. Those two cases are handled by inbound filtering, not by your DNS.

How do I know whether my account was hacked or my domain was spoofed?

Read the headers of a message a recipient actually received, then check your own delivery logs. If the mail authenticated from your provider and appears in Email Log Search, treat it as a compromised account and suspend it first, which resets sign-in cookies and OAuth tokens. If it never appears in your logs, nothing was sent from your account.

How to stop email spoofing: what DMARC can and cannot do

The call arrives in one of two shapes. Either a client forwards a message their own customers received, signed with the company name and politely asking for a change of bank details, or they send over a pile of bounce notices for mail nobody in the office ever wrote. The question is the same both times: how is someone sending mail as us, and how do we stop it.

The honest answer is that "someone is sending email as us" is three different problems wearing the same costume, and telling them apart is the whole first hour of the job. Get it wrong and you spend a week tightening DNS records while an intruder is still signed in to a mailbox.

Three problems, one complaint

A mailbox is compromised. The mail really did leave your organisation, sent by whoever holds the password or a stolen session. Sometimes the evidence is sitting in the Sent folder. Sometimes it is not, because whoever got in deleted it and left a filter behind.
Your domain is being spoofed. The messages are written somewhere else entirely, with your domain typed into the From header. Nothing of yours was broken into. Gmail Help is blunt about the limit: because those messages are created outside Gmail, Gmail cannot stop a spammer putting your address in the From field, and the symptoms are what clients describe, bounce reports for mail you never sent and replies to messages you never wrote.
Your name is being used, but not your domain. The address belongs to the sender: a free webmail account, or a domain registered last week that reads like yours if you do not look twice. Only the display name says your company.

The first is an incident. The second is a DNS and policy job. The third cannot be fixed with DNS at all, which is the part most articles skip.

Start with one real message, not with your DNS

Before anyone opens a DNS panel, we want the full headers of one message the recipient actually received. Not a screenshot, not a forward, the raw headers. In Gmail a question mark next to the sender name means the message was not authenticated, and expanding the sender line shows whether there is a Mailed by or Signed by domain behind it. That single indicator separates two of our three cases in about four seconds.

Then we read the headers in a fixed order:

Is the domain in the From header actually yours, or only similar to yours?
Does Authentication-Results show an SPF or DKIM pass, and does the domain that passed line up with the From domain? A pass for some other domain is not a pass for you.
Does the Received chain start inside your mail provider, or somewhere you have never heard of?

If the From domain is yours and nothing authenticated it, you are looking at spoofing. If it is yours and authenticated cleanly from your own provider, treat it as a compromised account until proven otherwise. If it is not yours at all, no change to your records will touch it. Our header analyzer prints the same three answers without you having to parse the chain by hand, and there is a longer walkthrough in how to read email headers.

Rule out a compromised account before you touch a record

When the headers point inside your own tenant, DNS work can wait. Google's guidance for Workspace admins puts the order plainly: suspend the account first, because suspending a user resets that user's sign-in cookies and OAuth tokens, then investigate, then reset the password and revoke the OAuth 2.0 tokens, then restore access.

The investigation has two halves in the Admin console. User log events hold successful and unsuccessful web sign-ins across your domain going back up to six months, which is where a sign-in from a country nobody travelled to shows up. Email Log Search holds the delivery logs for your domains, and it answers the question that decides everything else: did these messages pass through your organisation? If the messages your recipients are complaining about never appear in your own delivery logs, nothing was sent from your account and you are back to the spoofing track.

Before you hand the mailbox back, look for what was left behind rather than only what was taken. Filters and forwarding rules are the usual residue, because they keep working after a password change. One takeover we wrote up in detail, phishing that bypasses two-factor authentication, began with a shared file and a stolen session rather than a guessed password, which is why a password reset on its own is not containment.

If your domain is being spoofed, DMARC is the lever

DMARC ties the domain a human reads, the one in the From header, to a domain that passed SPF or DKIM. That link is called alignment, and it is why DMARC can do what SPF and DKIM cannot on their own: let you publish an instruction about mail that claims your name and proves nothing. The current specification is RFC 9989, published in May 2026, which replaced RFC 7489. It keeps the three policy values admins already know, none, quarantine and reject, and it keeps the honest caveat that a published policy is a requested disposition: the receiving system still makes the final call.

A first record looks like this, with reports going to a mailbox someone will actually read:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1"

Starting at p=none is not timidity, it is sequencing. The reports tell you which of your own senders are failing alignment before a policy starts rejecting them: the invoicing system, the CRM, the store platform, the copier in the corridor. Two weeks of reports, then quarantine, then reject. We walk the whole ramp in moving DMARC from p=none to p=reject, and the XML itself in how to read a DMARC aggregate report. If you already have reports sitting in a mailbox, the DMARC report analyzer will sort the senders for you.

Enforcement is what ends the second kind of complaint. Until the policy says reject, a receiver that honours DMARC has been told to deliver the spoofed mail anyway.

The domains you own and never send from

Almost every client has them: the misspelling bought defensively, the old brand, the country variant nobody renewed. An unused domain with no records is a free, reputation-clean identity for anyone who finds it. Those domains get an SPF record that authorises nothing and a policy of reject:

example-old.com.         TXT  "v=spf1 -all"
_dmarc.example-old.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

The same reasoning applies one level down, to subdomains you do not send from, which behave differently from the root domain and are a common gap after a clean root is locked. That is its own piece of work: see DMARC subdomains, the sp tag and delegation.

What DMARC does not stop, and nobody should pretend otherwise

This is where the first two fixes run out. RFC 9989 lists display name attacks as out of scope, in its section on security considerations, and the description matches what lands in your staff's inbox: an arbitrary address carrying a well-known name in the display name, so the reader believes the name is used legitimately. Your policy is irrelevant, because the attacker never claimed your domain.

Three variants we see constantly:

Display name only. The name reads like your director; the address is a free webmail account. Phone and tablet clients often show the name and hide the address, which is why it works.
A lookalike domain. A swapped letter, a hyphen, a different ending. It passes its own SPF, DKIM and DMARC, because the attacker owns it.
A clean From with a hostile Reply-To. The conversation looks right and the answers go elsewhere.

So half of this job is inbound filtering, protecting the people who read mail, not only the domain that sends it.

The inbound side: what we turn on in Google Workspace

In the Admin console, under Apps then Google Workspace then Gmail then Safety, the Spoofing and authentication settings cover the gaps above directly. There is protection against domains that look visually similar to yours or your aliases; against messages whose sender name matches a name in your Workspace directory although the mail did not come from your domain; against inbound mail claiming your own domain without an SPF or DKIM pass, the business email compromise pattern; and against unauthenticated mail generally. For each, you choose: keep it in the inbox with a warning banner, move it to spam, or quarantine it for an admin.

Which of these you get depends on your edition, so check the console rather than assuming. Quarantining everything unauthenticated on a Monday morning is how a finance team misses a real supplier. We start with warning banners, watch for a week, then quarantine the categories that produced no false positives.

If some of your users are on Microsoft 365, the equivalent machinery has a different shape. Microsoft folds SPF, DKIM and DMARC into a single composite authentication verdict, weighs it against spoof intelligence built from mail-flow and sender-infrastructure history, then lets the anti-phishing policy decide the action. A composite authentication failure alone does not block a message, deliberately, so senders with imperfect authentication are not cut off. For the sending side of a Microsoft tenant, see DMARC for Office 365.

The month after

Spoofing is not a job you finish on a Thursday. For the next thirty days we watch three things: new sending sources in the aggregate reports, which is how you catch both a forgotten internal tool and a fresh abuser; the quarantine queue, which tells you whether the inbound rules are calibrated or just loud; and the bounce pattern that started the conversation, which should thin out as receivers begin honouring the policy. Lookalike domains deserve a standing search, because the only remedy is seeing them early.

How Guanacos Tech helps

We do this in one pass: read the headers, decide which of the three problems you have, contain an account if that is what it turns out to be, publish the records in an order that does not break your own invoices, and set the inbound protections at a level your staff can live with. Then we stay on the reports for the first month, when the surprises happen. That work sits inside our email deliverability consulting for small business, and how an engagement is scoped and priced is set out in how we work. If mail claiming your domain is going out today, a 30-minute call is enough for us to tell you which of the three problems it is and what the first move should be.

Someone is sending email as your company: spoofing, a hacked account, or a fake name