Mail that appears to come from an address is either forged outside the account or sent from inside it. Forged messages never appear in the account Sent folder, while messages sent through a compromised account do. In sender forgery, the sender writes the address into the From line without access to the account. In account takeover, an intruder signs in to the mailbox and sends mail through the account itself. The forms look identical in a recipient inbox. Confusing the forms wastes the response: a password change does nothing against forgery created on another server, and reporting a message as spam does nothing against an intruder inside the mailbox. The published spoofing guide covers the forgery mechanism; this piece answers which form is happening and what follows from each.
Sender forgery without account access
Sender forgery, commonly called spoofing, is the forgery of the sender information on a message: the sender writes the victim address into the From line, and recipients see that address as the sender. No login happens, no password is needed, and no account setting changes, and the victim mailbox shows no trace of the message, because the message was never in it.
Forgery works because the original mail protocols carry the sender address as a claim. RFC 7208, the SPF specification, states that existing protocols place no restriction on what a sending host can use as the MAIL FROM of a message or the domain in its HELO or EHLO commands. A message also carries two sender addresses that do not have to match: the envelope sender, used for routing and bounce messages, and the From header, the address shown in the inbox. Microsoft email authentication documentation states that SMTP makes no effort to validate the claimed sender, and gives the example of an envelope sender on one domain paired with a From line naming a bank on another, a message that still counts as valid SMTP.
Google spoofed address help describes how the victim usually finds out: bounce messages for mail the holder never sent, or replies to messages the holder never sent. Google states the limit plainly: because these messages are created outside Gmail, Gmail cannot stop spammers from spoofing the address, and the advice is to report the messages as spam.
Spoofing has a second form that skips forgery of the address itself: the display name beside the address can carry a trusted name while the actual address belongs to the attacker. A message with the display name of a bank and an address on an unrelated domain passes every domain check for that domain, because the checks authenticate domains, not display names. Lookalike domains work the same way: a domain differing from the real one by one character passes all checks for itself, and only a character-by-character read of the From domain catches it.
Sender authentication checks
Three later checks narrow the forgery problem. Each examines a different part of the message, and none examines the name the reader sees.
SPF operates on the envelope rather than the displayed sender. Under RFC 7208, a domain holder lists permitted sending servers in a DNS record for the envelope domain, and a receiving server compares the actual sending server with that list. The From header falls outside that comparison entirely. An attacker can therefore register a domain, publish a valid SPF record for it, insert a bank address in the From line, and still pass SPF.
DKIM works through a cryptographic signature rather than an envelope list. Under RFC 6376, the sending domain applies a private-key signature to selected headers and the body, and the receiver checks that signature against the public key held in DNS. Passing DKIM shows only that the signed parts reached the receiver unchanged and identifies the signing domain. That domain need not be the From domain, so the same evasion remains open: a signature from the attacker's own domain alongside a bank address in the From line still results in a DKIM pass.
DMARC connects the two earlier checks to the address shown to the reader. Passage requires an SPF or DKIM result aligned with the From domain, in other words an authenticated domain identical to the From domain. The governing specification is RFC 9989, issued in May 2026 on the Standards Track as the replacement for the original RFC 7489 of March 2015 and for RFC 9091. Failure handling is set by a policy the domain holder publishes in DNS, with three options: none, which means monitoring only; quarantine, which means spam treatment; and reject, which means refusal. Published policy does not bind a receiver, and receivers commonly combine the DMARC result with reputation and content signals before deciding.
The present baseline is visible in Google email sender guidelines, effective from 1 February 2024. Every sender to Gmail accounts must configure SPF or DKIM, while a sender exceeding 5,000 messages per day to Gmail accounts must configure SPF, DKIM and DMARC together, with direct mail carrying a From domain aligned with the SPF or DKIM domain. Bulk senders fall under that rule, yet an ordinary address can still be spoofed, since protection rests on records published by the domain holder and on enforcement by the receiver.
A DMARC pass is evidence about a domain, not a guarantee about a sender: RFC 9989 states that a pass means only that use of the Author Domain was validated as authorised by the domain holder, and that a pass by itself does not guarantee that delivery to the inbox would be safe or desirable. A criminal who owns a domain can pass every check for that domain.
Account takeover through sign-in
Account takeover is the second form: an intruder signs in to the mailbox, through a stolen password, a reused password from another breach, a phishing page, a stolen session, or a compromised recovery channel, and sends mail from inside the account. The messages are genuine mail from the account, appearing in the Sent folder with valid authentication for the account domain, because the account's own provider sent them. No forgery check catches them, because nothing was forged.
Google hacked account guide lists the Gmail warning signs: sent mail the holder did not write, friends reporting spam received from the holder, a changed username, mail deleted from the inbox and absent from Trash, and a stop in incoming mail. The guide response runs through recent security events, the device list, 2-Step Verification, and removal of labels, filters or forwarding rules the holder did not set up.
Microsoft hacked account guide orders the response differently, and the order is the point: a full antivirus scan first, before any password change, because a machine with malware reads the replacement password the moment it is typed; then the password change or reset; then a check of connected accounts, forwarding settings and automatic replies for anything the intruder added.
Evidence separating the two cases
The Sent folder check comes first because it divides the cases most cleanly.
| Check | Spoofing | Account takeover |
|---|---|---|
| Sent folder | Messages absent; the account never sent them | Messages present that the holder did not write |
| Devices and sessions | No unfamiliar devices | Unfamiliar devices or sign-ins present |
| Recovery settings | Unchanged | Recovery email or phone changed or added |
| Mail rules | No new rules | Forwarding rules or filters the holder did not create |
| Message headers | Authentication failures on the forged domain, or a pass for an unrelated domain | Valid authentication from the account's own provider |
Messages absent from the Sent folder point to spoofing, because spoofed messages are created outside the account. Messages present in the Sent folder that the holder did not write point to takeover, because only a signed-in sender can place mail there.
The header check belongs to the spoofing case: the Authentication-Results line in the full header shows the SPF, DKIM and DMARC verdicts for that message. A DMARC failure on a message claiming to be from a bank is strong evidence of forgery, while a DMARC pass on a message from a lookalike domain is weak evidence, because the pass covers the lookalike's own domain. The published header reading guide walks through the same check in detail.
The breach check belongs to the takeover case: when the address appears in a known breach, the inbox password may be among the leaked data, especially when the same password was reused elsewhere. Have I Been Pwned names the breach, its date and the data types exposed, which shows whether a password reset is urgent.
Spoofing containment
When the checks point to spoofing, the response is containment and warning, not account recovery, because the messages were created outside the account and there is nothing to evict from it. Google spoofed-address advice is to report the messages as spam. Contacts who received the forged mail need a warning through a separate channel, telling them the messages did not come from the holder and that links and attachments in them should not be opened.
Takeover recovery sequence
A takeover finding calls for recovery and eviction, with the provider guides differing on sequence rather than substance. Microsoft places a malware scan first, followed by a password change and then a settings audit, whereas Google begins with security events and devices, continues with 2-Step Verification, and ends with removal of unfamiliar labels, filters and forwarding rules. Both guides treat a password change on its own as incomplete, because active sessions, mail rules and altered recovery settings persist beyond it. The password change, the session sign-out and the settings audit therefore belong in a single sitting.
After recovery, accounts sharing the inbox password or using the inbox for resets remain: the Google guide states passwords should also change for apps and sites that use the same password, or that sign in with the Google Account address. Microsoft account safety guide adds that support agents cannot send password reset links or change account details, so self-service recovery forms are the route back in when sign-in is lost.
Per-site alias addresses
AliasFleet provides email aliases: persistent forwarding addresses managed by the holder, one per site or service, all delivering to a single inbox. The mechanism changes what a spoofed or leaked address exposes: a message claiming to be from a bank that arrives on the address given only to a bookshop identifies itself as forged on arrival, because the bank never held that address. When one address leaks from one site, pausing that address stops that channel while the real address and every other alias keep working.
Aliases neither stop spoofing of an address nor prove a sender genuine. A forged message can still reach the correct alias when the attacker already knows it. Aliases also do nothing against takeover of the inbox itself: the recovery and eviction steps above are the response there, covered in the published recovery guide and hardening guide, and the related question of takeover without a password is covered in the published piece on hacking without a password. After eviction, aliases make a harvested address worth less by confining it to one site.
Unresolved cases
The two cases are not always cleanly separable from the outside: a message that fails DMARC might be a forgery, or genuine mail broken in transit by forwarding or by a mailing list rewriting a signed part. A message that passes every check might be genuine, or from a lookalike domain or a compromised legitimate account. Receivers do not publish the exact weight given to a DMARC failure against reputation and content signals, so no ranking of those inputs is offered here. When the checks disagree, the safer reading treats the account as compromised until the device list, recovery settings and mail rules come back clean, because the cost of missing a takeover is higher than the cost of an unnecessary password change.
Top comments (0)