Does email spoofing mean my account has been hacked?

Almost never. Spoofing only forges the From header on a message sent from somewhere else; the attacker does not need access to your mailbox. Check your sent folder and recent-activity page to rule out a real compromise, change the password if anything looks wrong, and otherwise treat the spoofing as something happening to your address rather than inside your account.

Can I stop someone from spoofing my email address?

Not directly, because any server can write any address into a header. What you can do is make the spoof fail: if you own the domain, publish SPF, DKIM and a DMARC record with a reject policy, so receivers that check it discard the forgeries. If your address is at a free provider, that protection is already in place at receivers that enforce DMARC.

Why do spoofed emails still get through if DMARC exists?

Because DMARC only works when the spoofed domain publishes a policy stronger than none and the receiving server enforces it. It also only covers the exact address: a message with a fake display name on a real address, or one sent from a lookalike domain the attacker registered, passes every authentication check and has to be caught by other means.

How can I tell whether a message was really sent from the address shown?

Open the full headers and read the Authentication-Results line your provider added. A dmarc=pass naming the From domain means the sender controls that domain; a fail or no DMARC result on mail from a major company is a strong warning. Then compare From with Return-Path and Reply-To, and read the Received chain from the bottom to see which server actually delivered it.

Email Spoofing Explained: How Mail Is Sent 'From' Your Address

Email spoofing is the practice of sending a message whose From line shows an address the sender does not own — yours, your bank's, your boss's. It works because the protocol that moves mail never checked that line. The sending server writes whatever it likes, the same way anyone can write any return address on an envelope. SPF, DKIM and DMARC were added later to close the gap, and they do, but only for domains that publish them and receivers that enforce them.

If your address is being spoofed, your account has almost certainly not been hacked, and in most cases you cannot stop it. You can, however, make it fail at any well-run receiver.

Here is why the gap exists, the tricks that exploit it, what the authentication standards do and do not catch, and how to tell a spoof from the real thing.

Why is the From header not authenticated?

A message has two senders. The first is the envelope sender, given in the SMTP conversation between servers and recorded as Return-Path. The second is the From: header inside the message, which is what your mail client displays. The format for that header is defined in RFC 5322 as a plain text field. Nothing in the original design ties it to the server that connected, to the envelope sender, or to anyone who can prove they own the address.

That was a reasonable choice for a network of trusted universities in the early 1980s. It means that any machine able to speak SMTP can set From: you@yourdomain.com and hand the message to a receiving server. The receiver then has to decide for itself whether to believe it. Every anti-spoofing measure since has been a way of giving that receiver evidence.

The three tricks spoofers use

The exact-address spoof. The From header carries your real address, character for character. This is the classic form, and it is the one SPF, DKIM and DMARC are designed to catch.
The display-name trick. The header reads "Your Bank" <random@freemail-provider.com>. The address is genuine and belongs to the attacker; only the friendly name is a lie. Mobile clients often show just the name, so this works without forging anything.
The lookalike domain. The attacker registers yourbank-secure.com, or yourbamk.com, or a version with a Cyrillic letter in place of a Latin one, and sends from it legitimately. Every authentication check passes, because the domain is theirs.

A fourth, quieter move is a mismatched Reply-To. The From header looks right, but your reply goes to an address you never saw. It is often paired with the display-name trick.

What do SPF, DKIM and DMARC actually stop?

Each one answers a different question, and none of them answers all three. We walk through them in plain language in SPF, DKIM and DMARC explained for normal people; the short version follows.

SPF is a DNS record listing the servers allowed to send mail for a domain. The receiver checks the connecting server against the list for the envelope sender's domain. It says nothing about the From: header, so an exact-address spoof with a different envelope domain passes SPF cleanly. It also breaks when mail is forwarded.

DKIM is a cryptographic signature over selected headers and the body, verified against a public key in the signing domain's DNS. It proves the message was signed by that domain and has not been altered since. It does not require the signing domain to match the From header, so a spoof signed by the attacker's own domain still carries a valid signature.

DMARC ties the two together. It requires the domain that passed SPF or DKIM to align with the domain in the From header, and it lets the domain owner publish a policy: do nothing, quarantine, or reject. A domain with a reject policy, checked by a receiver that enforces it, makes the exact-address spoof fail. That is the only one of the three tricks the standards defeat.

What none of them stop

The display-name trick, because the actual address is genuine.
Lookalike domains, because the attacker authenticates their own domain perfectly.
Mail from a genuinely compromised account, which passes every check.
Spoofs of a domain whose owner never published DMARC, or published it with a policy of none.
Spoofs delivered to a receiver that does not check DMARC at all.

What to do if your address is being spoofed

The usual sign is a wave of bounce messages for mail you never sent, or a contact asking why you emailed them a strange link. Nearly always, this means your address was harvested from someone else's leaked contact list and is being used as a disguise. It does not mean your account was broken into. Still, rule that out first:

Check your sent folder and your provider's recent-activity page for anything you do not recognise.
Change the password and switch on an authenticator app or passkey, if you have not already. If the account was genuinely compromised, that is what stops it.
If you own the domain, publish SPF and DKIM, then a DMARC record. Start at p=none with reporting switched on, confirm your own mail aligns, and move to p=quarantine and then p=reject.
If your address is at a free provider, there is nothing to publish — the provider already does this, and a spoof of its domain fails DMARC at any receiver that checks. The damage is limited to receivers that do not.
Warn the contacts you can reach, by a channel other than email if possible, that messages from your address asking them to click or pay are not from you.
Report the message to the receiving provider, using the headers rather than a forward.

Beyond that, accept that you cannot stop the sending. Nobody can prevent a stranger's server from typing your address into a header. Bounces usually stop within days as the campaign moves on.

How to check a suspicious message's headers

The headers are the only part of a message the attacker cannot fully control, because the receiving servers add their own. Open the full source — most clients call it something like "Show original" — and look for four things. The step-by-step reading is in how to read email headers, and the email header analyser will parse the block for you and highlight the results.

Authentication-Results — written by your provider. Look for spf=pass, dkim=pass and, decisively, dmarc=pass with the From domain named. A fail or a missing DMARC result on mail claiming to be from a major company is a strong signal.
From versus Return-Path — if the envelope sender's domain has nothing to do with the From domain, ask why.
Reply-To — any value that differs from From deserves a second look.
The Received chain — read from the bottom up; the first hop shows which server actually handed the message over.

Headers tell you whether the sender is who they claim. They do not tell you whether the content is safe, so the usual checks on links and urgency still apply. We list those in how to spot a phishing email.

In short

The From line is unverified text, and always was. SPF and DKIM give receivers evidence about the sending server and the signing domain. DMARC is the piece that connects that evidence to the address you actually see, and it only bites when the domain owner publishes a policy and the receiver enforces it. If your own address is spoofed, check that you were not actually compromised, publish DMARC if the domain is yours, warn your contacts, and wait it out. For any message that worries you, read the headers before you read the message.

Sources

RFC 5322, Internet Message Format — defines the From header as a text field.
RFC 7208, Sender Policy Framework (SPF), RFC 6376, DomainKeys Identified Mail (DKIM) and RFC 7489, DMARC — the three authentication standards.
Microsoft Learn: anti-spoofing protection in Microsoft 365 — a large receiver's description of how spoofed mail is detected and handled.
Gmail Help: trace an email with its full headers — how to open and read the full headers in a major client.