I7.2 Sender Identity, Domains, and Email Authentication
Learn how defenders compare fictional display names, addresses, domains, reply paths, envelope senders, SPF, DKIM, DMARC, alignment, routing, business relationships, and independent verification without treating authentication as a complete verdict.
Lesson Progress
Sender Identity, Domains, and Email Authentication
High School Intermediate • I7: Email Security and Phishing Defense • Lesson 2 of 8
Readiness Check
Before You Start
0/5 ready
Professional Hook
An Email Can Authenticate Perfectly and Still Be an Impersonation
A fictional lookalike domain can publish SPF, sign mail with DKIM, and pass DMARC for itself. Those results show that the domain authorized and signed its own message. They do not show that the domain belongs to the organization the recipient expected, that the mailbox is uncompromised, or that the requested action is approved.
Weak response
“SPF, DKIM, and DMARC passed, so the sender and request must be legitimate.”
Strong response
“Identify which domain authenticated, compare it with the expected sender, review the business relationship, and verify the request independently.”
Objective 1
Explain the difference between fictional display names, mailbox addresses, domains, envelope senders, reply paths, return paths, and message identifiers.
Objective 2
Interpret fictional SPF, DKIM, DMARC, alignment, and authentication-result evidence without overstating what a pass or fail proves.
Objective 3
Recognize lookalike domains, subdomain confusion, newly observed domains, compromised legitimate accounts, forwarding, mailing services, and vendor exceptions.
Objective 4
Compare sender identity, domain evidence, message routing, authentication, business relationships, and independent verification.
Objective 5
Create a professional fictional Sender Identity and Email Authentication Review with confirmed facts, limitations, findings, owners, validation, and residual risk.
Why This Matters
Sender Trust Requires Technical and Business Evidence
Defenders must support legitimate cloud services, vendors, forwarding systems, newsletters, ticketing tools, and shared workflows while identifying direct spoofing, lookalike domains, compromised accounts, and unsafe requests. Authentication helps explain domain relationships, but business verification determines whether the claimed identity and requested action are expected.
Sender Identity Layers
Eight Identities Hidden Inside One Message
Display name
What it shows
The fictional human-readable sender label shown in the inbox.
Defensive use
Compare the claimed person or organization with the actual address, known relationship, request, and prior communication.
Limitation
Display names can be copied, changed, or automatically generated.
Visible From address
What it shows
The fictional mailbox address displayed as the message sender.
Defensive use
Check the local part, domain, spelling, expected organization, and relationship to the request.
Limitation
A valid-looking address can belong to a lookalike domain or a compromised legitimate account.
Reply-To address
What it shows
The fictional address that will receive replies if it differs from the visible From address.
Defensive use
Identify unexpected reply redirection, external domains, or unrelated mailboxes.
Limitation
Different reply addresses can be legitimate for support, ticketing, mailing lists, and shared workflows.
Envelope sender
What it shows
The fictional transport identity used for bounce handling and SPF evaluation.
Defensive use
Compare the transport sender with the visible From domain and the expected sending service.
Limitation
Cloud services, vendors, forwarding systems, and bulk mail can use different transport domains.
Return path
What it shows
The fictional finalized transport return address recorded after message delivery.
Defensive use
Trace the bounce path and compare it with the sender infrastructure.
Limitation
The return path may legitimately differ from the visible sender.
Sending infrastructure
What it shows
The fictional servers, cloud providers, gateways, applications, and relays that sent or forwarded the message.
Defensive use
Determine whether the path matches the domain’s expected service and known business relationship.
Limitation
Shared cloud infrastructure can serve both legitimate and unwanted senders.
Authentication identity
What it shows
The fictional domain evaluated through SPF, DKIM, and DMARC.
Defensive use
Determine which domain authorized or signed the message and whether it aligns with the visible From domain.
Limitation
A domain can authenticate its own deceptive message or a compromised account can send authenticated mail.
Business identity
What it shows
The fictional real-world person, department, vendor, service, or organization the message claims to represent.
Defensive use
Verify the relationship, request, timing, process, and owner through an independent trusted path.
Limitation
Technical authentication does not automatically confirm the business identity or legitimacy of the request.
Domain Analysis
Eight Domain Patterns Defenders Must Distinguish
Misspelled lookalike
Fictional example
northstar-learnlng.example uses a lowercase l where the trusted domain uses i.
Concern
The fictional domain visually resembles the expected organization while being technically different.
Verification
Compare the exact domain character by character and use a known trusted directory or website independently.
Added business word
Fictional example
northstar-learning-payments.example adds a relevant word to appear connected to finance.
Concern
The fictional domain can sound believable even though it is not the trusted parent domain.
Verification
Confirm whether the organization actually owns or uses the domain for that business process.
Misleading subdomain
Fictional example
northstar-learning.example.login-support.example has the real registered domain login-support.example.
Concern
The trusted name appears in the left side of the hostname while the controlling domain appears later.
Verification
Identify the registrable parent domain and avoid relying on the first visible words.
Different top-level domain
Fictional example
northstar-learning.co.example is presented where northstar-learning.example is expected.
Concern
A small suffix change can be easy to miss in a long address.
Verification
Compare the full trusted domain and known communication history.
Hyphen and punctuation variation
Fictional example
north-star-learning.example differs from northstar-learning.example.
Concern
Punctuation changes can create a visually similar but separate domain.
Verification
Check the exact domain and independently confirm whether it is an approved alternate.
Newly observed vendor domain
Fictional example
billing.vendor-new.example sends a payment notice for a known fictional vendor.
Concern
The domain may be legitimate, newly adopted, misconfigured, or deceptive.
Verification
Use the known vendor contact and approved procurement records rather than the message.
Compromised legitimate domain
Fictional example
A real fictional vendor domain sends an unusual bank-change request from a valid mailbox.
Concern
The domain and authentication may be correct while the account or workflow is compromised.
Verification
Verify the request through a separate trusted contact and established approval process.
Third-party sending service
Fictional example
A fictional school newsletter is sent through mail.campaign-service.example.
Concern
The sending infrastructure differs from the organization’s primary domain.
Verification
Confirm the service relationship, alignment, signing domain, message purpose, and prior approved use.
Core Concept
Ask Three Separate Questions
Which domain authenticated?
Identify the fictional envelope-sender domain, DKIM signing domain, visible From domain, and alignment result.
Is that the expected sender?
Compare the exact domain, mailbox, service relationship, routing history, vendor record, and known communication.
Is the request approved?
Verify the fictional business purpose, timing, owner, transaction, document, account, and normal workflow independently.
SPF Interpretation
Eight SPF Results and Their Limits
SPF pass
Direct meaning
The fictional sending system is authorized by the SPF policy for the evaluated envelope-sender domain.
Does not prove
The visible From identity, business request, domain trustworthiness, physical sender, or message safety.
SPF fail
Direct meaning
The fictional sending system is not authorized by the evaluated SPF policy.
Does not prove
That the message is definitely malicious; forwarding, misconfiguration, stale policy, or service changes may explain the result.
SPF soft fail
Direct meaning
The fictional policy indicates the sender is probably unauthorized but does not request the strongest failure treatment.
Does not prove
That the recipient must always block the message without considering policy and context.
SPF neutral
Direct meaning
The fictional domain policy does not make a strong authorization statement about the sending system.
Does not prove
That the message is safe or unsafe.
SPF none
Direct meaning
No usable fictional SPF policy was found for the evaluated domain.
Does not prove
That the message is automatically phishing.
SPF temperror
Direct meaning
A temporary fictional error prevented reliable SPF evaluation.
Does not prove
That the domain policy failed or the message is malicious.
SPF permerror
Direct meaning
A permanent fictional policy problem prevented correct evaluation.
Does not prove
The sender’s intent, but it does indicate an authentication configuration issue.
SPF pass without alignment
Direct meaning
The fictional envelope-sender domain authorizes the sending system, but it does not align with the visible From domain.
Does not prove
DMARC success unless DKIM provides aligned authentication.
DKIM Interpretation
Eight DKIM Concepts and Their Limits
DKIM signature
A fictional domain signs selected message headers and content using a private key.
Defensive value
The recipient can verify the signature with the domain’s published key.
Limitation
A valid signature does not prove the message is legitimate, expected, or harmless.
Signing domain
The fictional domain recorded in the DKIM signature.
Defensive value
Shows which domain accepted responsibility for the signature.
Limitation
The signing domain may differ from the visible From domain.
Selector
A fictional label used to locate the correct public key for a DKIM signature.
Defensive value
Supports key rotation and multiple sending services.
Limitation
A selector name alone has little meaning without the verified signature and domain.
DKIM pass
The fictional signature verifies under the published key and the signed content matches.
Defensive value
Supports message integrity for the signed fields and domain identity.
Limitation
A compromised account or deceptive domain can still produce valid DKIM signatures.
DKIM fail
The fictional signature does not verify.
Defensive value
Indicates changed content, invalid signature, missing key, configuration problem, or unsupported transformation.
Limitation
Forwarding or mailing-list changes can sometimes break a legitimate signature.
Aligned DKIM
The fictional signing domain aligns with the visible From domain under DMARC rules.
Defensive value
Can satisfy the DKIM path for DMARC.
Limitation
Alignment does not confirm the real-world sender or business request.
Unaligned DKIM
The fictional signature verifies, but the signing domain does not align with the visible From domain.
Defensive value
Shows a valid third-party or unrelated signature.
Limitation
It does not satisfy DMARC through DKIM by itself.
Unsigned content
Some fictional message fields or body portions may not be covered by the signature.
Defensive value
Encourages reviewers to understand which content was protected.
Limitation
A DKIM pass should not be described as proof that every visible element was unchanged.
DMARC Interpretation
Eight DMARC Concepts and Their Limits
DMARC pass
The fictional visible From domain aligns with a passing SPF or DKIM identity.
Defensive value
Supports domain-level authentication for the visible sender domain.
Limitation
It does not prove the mailbox owner, physical sender, message intent, or business request.
DMARC fail
Neither the fictional SPF nor DKIM path both passes and aligns with the visible From domain.
Defensive value
Identifies an authentication and alignment problem relevant to sender trust.
Limitation
Forwarding, mailing services, or misconfiguration can cause legitimate failure.
Policy none
The fictional domain requests monitoring rather than quarantine or rejection.
Defensive value
Allows reporting and observation during deployment.
Limitation
A monitoring policy does not instruct the receiver to block failed messages.
Policy quarantine
The fictional domain requests suspicious handling for messages that fail DMARC.
Defensive value
Can support spam-folder or quarantine treatment.
Limitation
The recipient still applies local policy and may use additional evidence.
Policy reject
The fictional domain requests rejection of messages that fail DMARC.
Defensive value
Reduces direct spoofing of the protected visible From domain.
Limitation
It does not stop lookalike domains, compromised accounts, or authenticated malicious mail.
Relaxed alignment
The fictional authenticated domain and visible From domain may align at the organizational-domain level.
Defensive value
Supports legitimate use of related subdomains.
Limitation
It is less exact than strict alignment.
Strict alignment
The fictional authenticated domain must exactly match the visible From domain.
Defensive value
Provides a tighter identity relationship.
Limitation
It may be harder to use with some legitimate sending architectures.
DMARC reporting
The fictional domain owner receives aggregate or failure information about authentication results.
Defensive value
Supports visibility into legitimate senders, misconfiguration, and spoofing patterns.
Limitation
Reports do not automatically remediate every issue or identify physical senders.
Evidence Matrix
What Sender and Authentication Evidence Can Prove
Evidence source
Visible From address
Can support
The fictional mailbox and domain presented to the recipient as the sender.
Limitation
The address can belong to a lookalike domain or a compromised legitimate account.
Evidence source
Reply-To
Can support
The fictional destination configured for replies.
Limitation
A different address can be either suspicious or legitimate depending on the workflow.
Evidence source
SPF result
Can support
Whether the fictional sending system is authorized for the evaluated envelope-sender domain.
Limitation
SPF does not authenticate the visible From domain unless alignment requirements are met.
Evidence source
DKIM result
Can support
Whether a fictional signature verifies for the signing domain and selected content.
Limitation
DKIM does not prove that the signing domain or message request is trustworthy.
Evidence source
DMARC result
Can support
Whether the fictional visible From domain aligns with a passing SPF or DKIM identity.
Limitation
DMARC pass does not prove mailbox ownership, safe intent, or expected business context.
Evidence source
Message routing
Can support
The fictional sending infrastructure, relays, timestamps, gateways, and delivery path.
Limitation
Shared cloud services and forwarding can make the path complex.
Evidence source
Historical relationship
Can support
Whether the fictional domain, sender, service, and request match previous approved communication.
Limitation
Past legitimacy does not guarantee a current account is uncompromised.
Evidence source
Independent verification
Can support
Whether a fictional known owner, vendor, colleague, teacher, or process confirms the message and request.
Limitation
Verification must use a trusted path not controlled by the suspicious message.
Sender Classification
Eight Outcomes with Different Evidence Requirements
Expected authenticated sender
The fictional visible From domain, aligned authentication, sending infrastructure, business relationship, request, and independent verification all match.
Required documentation
Record the trusted relationship, exact domain, authentication path, business owner, expected workflow, and any remaining limitation.
Legitimate third-party sender
A fictional approved service sends on behalf of an organization using different transport or signing infrastructure.
Required documentation
Record the service owner, approved sending relationship, aligned identity, message purpose, prior use, and validation.
Authentication misconfiguration
A fictional legitimate sender fails or partially fails authentication because of missing, stale, incorrect, or incompatible configuration.
Required documentation
Preserve the message and results, confirm the sender independently, assign the domain owner, correct the configuration, and validate future mail.
Direct domain spoofing
A fictional message claims a protected visible From domain but fails the required aligned authentication and is not independently verified.
Required documentation
Record the claimed domain, authentication failure, delivery action, affected recipients, related-message search, and containment.
Lookalike-domain impersonation
A fictional message uses a separate domain designed to resemble a trusted organization.
Required documentation
Record the exact spelling difference, authentication for the lookalike domain, claimed identity, request, business mismatch, and verification.
Compromised legitimate account possible
A fictional message authenticates correctly for an expected domain but contains an unusual or unauthorized request.
Required documentation
Preserve the message, verify through a separate trusted path, review account and session evidence, and avoid assuming authentication proves safe intent.
Forwarding or mailing exception
A fictional message has altered authentication or routing because of an approved forwarding, mailing-list, ticketing, or distribution process.
Required documentation
Confirm the forwarding or service relationship, original sender evidence, expected transformations, owner, and monitoring impact.
Evidence incomplete
The fictional sender, domain, authentication, routing, history, ownership, or business evidence is insufficient for a reliable conclusion.
Required documentation
State the missing evidence, confidence, investigation owner, temporary handling, due date, and decision criteria.
Defensive Workflow
Review Sender Identity in Six Steps
Record every sender identity
Capture the fictional display name, visible From address, domain, Reply-To, envelope sender, return path, and message ID.
Identify the real domain relationships
Separate local parts, subdomains, parent domains, lookalike domains, sending services, and expected organization domains.
Interpret authentication
Review fictional SPF, DKIM, DMARC, alignment, policy, and authentication-result fields without treating them as a final verdict.
Compare routing and history
Check fictional sending infrastructure, message path, prior communication, vendor records, service relationships, and recent changes.
Verify the business identity
Use a known fictional contact, trusted portal, approved directory, contract record, or established workflow.
Classify and document
Separate expected sender, legitimate third-party service, misconfiguration, spoofing, lookalike domain, compromised account, and evidence gap.
Correlated Sender Timeline
Follow an Authenticated Lookalike Domain from Delivery to Closure
10:14:02
Message creation
A fictional message is created with display name “Northstar Benefits Team” and visible From address benefits@northstar-benefits.example.
Establishes the sender claim and the external domain presented to the recipient.
10:14:05
Envelope
The fictional envelope sender is bounce@mailer.northstar-benefits.example.
Identifies the transport identity used for SPF evaluation.
10:14:08
SPF
SPF passes for mailer.northstar-benefits.example.
The sending service is authorized for the envelope-sender domain.
10:14:09
DKIM
DKIM passes with signing domain northstar-benefits.example.
The message verifies under the lookalike domain’s signing identity.
10:14:10
DMARC
DMARC passes because the visible From domain aligns with the DKIM signing domain.
The lookalike domain authenticated its own message correctly.
10:14:12
Security gateway
The message is marked external and receives a medium-risk score for a newly observed domain and credential-update language.
The tool recognizes context concerns even though domain authentication passes.
10:14:15
Mailbox
The fictional message is delivered to three employees with an external-sender banner.
Confirms recipient scope and delivery, not user interaction.
10:18:20
User report
One recipient reports the message without using its benefits-login button.
Supports safe handling and preserves the message for investigation.
10:21:00
Domain comparison
The approved benefits provider uses northstar-employee-benefits.example, not northstar-benefits.example.
Confirms the authenticated sender domain is separate from the expected provider domain.
10:24:00
Independent verification
The fictional Human Resources owner confirms no benefits credential update was scheduled.
Provides business-owner evidence that the request is unauthorized.
10:28:00
Related-message search
The fictional environment identifies nine messages using the same sender domain and subject pattern.
Expands the recipient and message scope.
10:31:00
Containment
The related messages are quarantined under approved defensive policy.
Reduces further interaction while preserving evidence.
10:36:00
Account review
No fictional recipient account shows a related sign-in, recovery, factor, or session event.
Supports no confirmed credential or account impact in the reviewed scope.
Day 2
Validation
Legitimate benefits-provider messages continue to deliver, and the lookalike-domain pattern remains blocked.
Confirms narrow containment and preservation of required communication.
Key Vocabulary
Sender Identity and Authentication Terms
Display name
The fictional sender label shown prominently in an inbox, which can be changed independently from the actual mailbox address.
Mailbox address
The fictional email address associated with the visible sender or recipient, usually containing a local part and domain.
Local part
The fictional portion of an email address before the @ symbol.
Domain
The fictional name after the @ symbol that identifies the sending or receiving email domain.
Subdomain
A fictional label placed before a parent domain, such as billing.vendor.example.
Envelope sender
The fictional transport address used by mail systems for delivery and bounce handling.
Reply-To
A fictional header that tells the mail client where replies should be sent instead of using the visible From address.
SPF
A fictional domain policy that identifies which sending systems are authorized to send on behalf of the envelope-sender domain.
DKIM
A fictional cryptographic signature that allows a recipient to verify that selected message content was signed by a domain and was not changed in certain ways.
DMARC
A fictional policy and reporting layer that checks alignment between the visible From domain and SPF or DKIM identities.
Alignment
The fictional relationship between the visible From domain and the domain authenticated through SPF or DKIM.
Lookalike domain
A fictional domain designed to resemble a trusted domain through spelling, punctuation, extra words, or visual similarity.
Fake Dashboard
Fake Sender Identity and Authentication Dashboard
Training dashboard for the fictional Northstar Learning Services email environment.
Sender reviews
36
Expected senders, approved third-party services, misconfiguration, spoofing, lookalike domains, forwarding exceptions, and incomplete cases.
Authentication paths
3
SPF, DKIM, and DMARC are reviewed with alignment, routing, sender history, and business verification.
Domain findings
7
Two lookalike domains, one direct spoof, two vendor configuration issues, one forwarding exception, and one compromised-account concern.
Fake SOC Alert
Benefits Credential Message Passes Authentication for a Lookalike Domain
Source: Fake Sender Authentication Review Console • Time: 10:14 AM
Fake Log Panel
Fake Sender Authentication Timeline
10:14:02 FROM display_name='Northstar Benefits Team' address='benefits@northstar-benefits.example' 10:14:05 ENVELOPE sender='bounce@mailer.northstar-benefits.example' 10:14:08 SPF domain='mailer.northstar-benefits.example' result='pass' 10:14:09 DKIM domain='northstar-benefits.example' result='pass' 10:14:10 DMARC from_domain='northstar-benefits.example' result='pass' path='aligned_dkim' 10:14:12 FILTER risk='medium' reasons='new_domain,credential_update' 10:14:15 DELIVERY recipients='3' banner='external_sender' 10:18:20 USER_REPORT link_clicked='false' 10:21:00 DOMAIN_COMPARE expected='northstar-employee-benefits.example' observed='northstar-benefits.example' 10:24:00 OWNER_VERIFY request='not_authorized' 10:28:00 SEARCH related_messages='9' 10:31:00 CONTAIN action='quarantine_related' 10:36:00 ACCOUNT_REVIEW related_signins='0' recovery_events='0' DAY2 VALIDATION legitimate_provider_mail='working' lookalike_pattern='blocked'
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Which Sender-Authentication Conclusion Is Best Supported?
Which conclusion is strongest?
Common Mistakes
Mistakes That Weaken Sender Analysis
Safe Practice Lab
Complete a Fictional Sender Identity and Authentication Review
Fictional Evidence Set
Meadowbrook Sender Review
Review thirty-two supplied fictional records covering display names, visible addresses, Reply-To, envelope senders, return paths, message IDs, parent domains, subdomains, SPF, DKIM, DMARC, alignment, routing, vendors, forwarding, user reports, account activity, business verification, containment, and validation.
Required Analysis
- Record each fictional sender identity and explain how the layers differ.
- Identify the exact local part, subdomain, parent domain, sending service, and expected organization domain.
- Interpret SPF, DKIM, DMARC, alignment, policy, and routing without overstating the result.
- Distinguish lookalike domain, direct spoof, approved third party, forwarding exception, misconfiguration, and compromised-account possibility.
- Verify the sender relationship and request through a trusted independent path.
- State confirmed facts, reasonable conclusions, alternatives, confidence, and evidence gaps.
- Recommend narrow containment, account review, configuration correction, monitoring, validation, and closure.
Scenario Decision Lab
A Lookalike Domain Passes SPF, DKIM, and DMARC
A fictional benefits message passes all three authentication checks for northstar-benefits.example, but the approved provider uses northstar-employee-benefits.example.
Scenario Decision Lab
A Known Vendor Passes Authentication but Requests a New Bank Account
A fictional message comes from the real vendor domain and passes aligned authentication. The message asks for an urgent bank-account change outside the established approval process.
Defender Habits
Sender Identity, Domains, and Email Authentication Checklist
Check Your Understanding
I7.2 Mini Quiz: Sender Identity, Domains, and Email Authentication
Choose your answers first. Explanations appear only after submission.
1. What is the main weakness of a display name?
2. What does SPF primarily evaluate?
3. What does a DKIM pass directly support?
4. What does DMARC alignment compare?
5. A fictional lookalike domain passes SPF, DKIM, and DMARC for itself. What is the strongest conclusion?
6. Why can a correctly authenticated legitimate-domain message still be dangerous?
7. What is the safest way to verify a suspicious sender or request?
Portfolio Prompt
Portfolio Prompt
Create a fictional Sender Identity and Email Authentication Review using at least thirty-two display-name, visible-address, Reply-To, envelope-sender, return-path, message-ID, domain, subdomain, routing, SPF, DKIM, DMARC, alignment, policy, vendor, forwarding, user-report, account, business-verification, containment, validation, and closure records. Include exact domain comparison, sender-identity layers, authentication interpretation, classifications, confirmed facts, conclusions, alternatives, evidence gaps, owners, monitoring, residual risk, and closure criteria.
Key Takeaways
What You Should Remember
Navigation