Authentication can succeed for the wrong organization
An attacker does not need to impersonate the exact domain of a trusted organization to send a deceptive message. They can operate a different domain, configure its email correctly and use it to make misleading claims. A receiver may observe successful SPF, DKIM and DMARC for that domain while the message still attempts fraud. The authentication result describes domain use; it does not establish that the domain belongs to the organization the reader has in mind or that the requested action is legitimate.
RFC 9989 explicitly limits DMARC's goals. Content analysis and authentication of entities other than domains are outside its scope, as are display-name attacks. This boundary explains authenticated phishing without suggesting that authentication has failed technically. The appropriate response combines domain identity, message context and independent business verification. This article is defensive guidance and contains no phishing template, delivery instructions or live domain testing.
Distinguish authentication from affiliation
Write down the domain in the actual From address and the domain that the recipient expected. If they differ, do not collapse them because the display name, logo or subject looks familiar. A domain owner can generally arrange authentication for their own mail, but that says nothing about their relationship to another business. Even a real website and a working reply address do not establish that relationship. The question is affiliation and authority, not merely technical consistency.
RFC 5322, section 3.4, separates the display name from the address. A familiar label can sit above an unrelated domain in a mail client. The label may be benign, ambiguous or deceptive depending on context; do not declare intent from the label alone. Compare the address with a trusted organizational record and verify the specific business action through an established channel outside the questionable message.
Inspect the meaning of a passing result
A standalone SPF pass may concern the envelope sender domain, while DKIM identifies a signing domain. DMARC adds an alignment relationship to the visible From domain. Identify which path supports the reported result. If all of those identities belong to the unfamiliar domain, the result can be internally consistent without validating the familiar brand or individual named in the message. That is an important finding, not a contradiction to explain away.
Use trusted receiver evidence rather than accepting a sender-supplied assertion. RFC 8601 describes why Authentication-Results consumers need a trust boundary. A screenshot containing the word pass may not reveal who evaluated the message or which domain passed. Record the source, time and relevant identity fields. Where evidence is insufficient, preserve uncertainty instead of asserting that the message either passed or failed definitively.
Evaluate the requested action separately
Identify what the sender wants the recipient to do. The risk may be a changed payment destination, disclosure of confidential information, installation of software, a sign-in at an unfamiliar location or an alteration to an established workflow. Domain authentication does not approve any of those actions. A technically valid message can still contain a false premise, an unauthorized request or a destination unrelated to the claimed business.
Do not inspect a suspicious link by signing in or entering information. Use the organization's established analysis and reporting process, with qualified personnel and appropriate tooling when deeper inspection is necessary. This draft does not claim that visual inspection of a URL can prove safety, nor that every unfamiliar domain is malicious. A legitimate new vendor and an attacker-owned domain may both be unfamiliar; business verification is what resolves the relationship.
Use receiver defenses without overstating them
Microsoft's email-authentication overview describes composite authentication as part of a broader assessment, rather than a simple replacement for SPF, DKIM and DMARC. This supports a layered approach: receiver systems may combine identity signals with other information when deciding how to handle mail. It does not guarantee detection of every authenticated phishing message or define another provider's current filtering behavior.
A receiver can accept, quarantine, junk or reject messages according to its own controls and policy. Do not infer safety from inbox placement or maliciousness from a single filtering outcome. Similarly, a public blocklist result is not a universal reputation verdict. Use provider diagnostics as evidence with a known scope and time. Preserve the distinction between a machine's classification and the business owner's authority to approve the requested action.
An affiliation-and-action worksheet
Create a worksheet with the claimed organization, expected trusted domain, actual From domain, display name, authenticated domain or domains, trusted receiver result and requested action. Add the evidence source for the expected domain, not just the observed domain. Record whether the business has an established relationship with the sender and whether the particular action fits that relationship. Keep an unresolved option rather than forcing every unfamiliar sender into an attacker category.
The second half of the worksheet records the independent verifier, previously known contact route, question asked, response and decision owner. Avoid using a telephone number or alternative address introduced only by the suspicious message. Redact unnecessary personal information in the shared copy while preserving domain equality and difference. A worksheet that replaces every address with the same placeholder cannot demonstrate why authentication failed to establish affiliation.
Fictional diagnosis: a correctly authenticated new domain
Imagine a fictional operations team receives a request that claims to come from a familiar equipment supplier. The sender uses a different domain that is not in the team's approved supplier record. Trusted receiver evidence hypothetically shows aligned DKIM and a DMARC pass for that different domain. The recipient sees a familiar display name and assumes the authentication result confirms the supplier identity. It does not: the observation concerns the different domain.
The proposed response is to pause the requested change and verify it with the supplier through a previously established contact. If the supplier denies the request, the organization can route the evidence through its approved incident process without adding the unfamiliar domain to an allowlist. If the supplier confirms a legitimate domain change, that confirmation should enter the normal supplier-maintenance workflow rather than silently changing trust based on one email. No real supplier, domain registration, message delivery or verification call was involved in this fictional example.
Preserve useful controls and require original evidence
The IC3 BEC advisory, published in 2020, supports independent verification of unusual business requests and account protections. It is cited for those defensive principles, not for a current attack statistic or a claim about a named organization. Authentication, receiver protections and business-process controls should reinforce each other. Do not remove authentication because it cannot determine intent, and do not grant trust merely because it passes.
The catalogue requires a redacted abuse scenario with identity evidence, control boundary and independent business verification. That original evidence remains open; the fictional scenario is not a substitute. No suspicious endpoint was visited, no credential collected and no third party contacted. Human specialist review, current source applicability, production routes, visual accessibility and owner release also remain open. A publishable version needs authorized evidence demonstrating the exact distinction between authenticating a domain and trusting the organization or action it claims to represent.