Latest / Breach Signals / The Email From You That You Never Sent
Transcript
- An email arrives from your own company address, but you never sent it. The display name agrees. The logo agrees. Even some authentication checks may pass. Somewhere inside the delivery record, however, the message must reveal which identity was actually tested. Which result proves control of a domain, and which conclusion does it never prove about the human story? This is Breach Signals from Scan.now. By the end, SPF, DKIM and DMARC will read like a chain of custody rather than alphabet soup, and you will know when a passing result deserves confidence and when it still demands independent verification. Start with SPF. During mail delivery, one server identifies a return-path domain and connects from an IP address. The receiving server can look up that domain's SPF record and ask whether the connecting address is authorized. This helps detect servers pretending to send for a domain that did not list them. SPF does not sign the message body, and forwarding can complicate the path. It also does not directly validate every word visible in the From line. DKIM approaches the problem differently. A sending service creates a cryptographic signature over selected message headers and body content. The signature names a signing domain and selector. The receiver obtains the public key from DNS and verifies that the signed material has not changed in a way covered by the signature. A valid DKIM result connects the signed message to control of that signing domain. It does not say the message's request is wise or honest. DMARC connects authentication to the identity a person is likely to notice. For DMARC to pass, either SPF or DKIM must pass and its authenticated domain must align with the visible From domain under DMARC's rules. The domain owner can publish a policy and receive reports. This makes direct spoofing of a protected domain harder and gives owners evidence about legitimate and abusive mail streams. The reassuring mistake is to read pass as safe. A criminal can register a lookalike domain, configure SPF, DKIM and DMARC correctly, then send fully authenticated fraud from that domain. A compromised real mailbox may also send authenticated messages. Authentication answers who had authority over particular domain infrastructure. It cannot verify the invoice, the urgency, the sender's judgment or whether the account was under its rightful control. For domain owners, deployment starts with inventory. List the services allowed to send mail using the domain, including marketing, support, billing and cloud platforms. Remove forgotten sources, configure signatures and study DMARC reports before moving from monitoring toward enforcement. Subdomains and organizational-domain alignment need deliberate decisions. Copying a strict record without knowing the mail flow can block legitimate messages. Recipients do not need to memorize the RFCs. They need to know that a provider's pass or fail result is attached to particular identities. Administrators need the deeper detail because forwarding, third-party senders and alignment modes affect delivery. Keeping those roles separate avoids two bad outcomes: users ignoring authentication entirely, or users treating a green result as permission to obey the message. When a message matters, compare layers. Read the complete From address, not only the display name. Check the Reply-To address if a reply is requested. View the authentication results and identify which domains passed. Then compare those domains with the organization the message claims to represent. Small spelling changes, unexpected consumer addresses and unrelated signing domains deserve attention, but no single field should carry the whole decision. Do not reply to the suspicious message to verify itself. If a colleague appears to request money or credentials, start a new conversation through a known address or call a known number. Domain owners should publish SPF carefully, sign legitimate mail with DKIM and deploy DMARC in measured stages while monitoring reports. A policy that blocks real business mail because legitimate senders were never inventoried creates pressure to disable the protection. Forwarding and mailing lists explain why real-world results are not always tidy. Forwarding can change the server that delivers a message and cause SPF to fail even when the original sender was legitimate. A mailing list may modify the subject or body and invalidate a DKIM signature. Modern ecosystems have additional mechanisms to preserve or communicate authentication through some of these transitions, but recipients should not try to solve every edge case by intuition. For an ordinary user, the practical response to an ambiguous result is not to declare the message safe or fraudulent. It is to lower confidence, avoid the requested route and verify separately. For administrators, the response is to inspect the path, legitimate sending services and aggregate reports, then correct configuration without weakening the policy for everyone. The Scan.now Email Security Checker can inspect the public SPF, DKIM-related and DMARC configuration for a domain and explain obvious gaps. The Email Header Analyzer can parse a header you paste, separate visible identity from delivery identity and surface authentication results. Remove message content you do not need to share, because headers can contain addresses, server names and routing details. These checks cannot prove the intent of a sender or establish that a mailbox was not compromised. Public DNS also describes the current configuration, which may differ from the moment an older message was delivered. Use the tools to organize evidence. Then verify consequential requests outside the message. The relevant links appear with this episode at scan dot now slash podcast and in the RSS description. The rule is: authentication validates domain handling, not human honesty. SPF, DKIM and DMARC are strong controls against important forms of spoofing, and every domain owner should understand them. A recipient still needs to compare identity, context and requested action. When an email appears to come from you, open the full header before accepting the display. When it appears to come from someone you trust, verify any unusual request through a route the message did not provide. Next time on Breach Signals, we will follow a familiar invoice thread where only one digit changes, and see why a compromised conversation can be more dangerous than an obvious fake.