What Is Phishing? How to Recognize Fraudulent Emails

An email saying "Your domain expires today" is not proof that you owe a payment. Phishing impersonates a trusted organization to steal your password, money, or account access. To spot fraudulent messages, inspect the sender address and the link's actual domain, then verify renewal independently through your known customer panel.

The Message Claiming Your Domain Expires Today

Hypothetical scenario: An email reaches yonetici@example.com with the subject “Your domain will be shut down today.” It demands immediate renewal payment, threatening to take your website offline and block customer-panel access. Its display name impersonates your domain provider. Between other tasks, keeping the site running can feel more pressing than checking authenticity. Pause. That pressure is meant to hurry you past verification and into payment.

What is phishing? It is an attack that impersonates a trusted person or organization to obtain information, payment, or account access. CISA explains that phishing messages can trick you into opening harmful links, downloading attachments, or sharing personal information. Here, the renewal pretext makes a questionable payment seem routine because you think your provider requested it. The attacker need not have accessed your provider’s systems.

The legitimate sender here is yenileme@example.com; the known customer panel is https://panel.example.com. The suspicious message’s actual From address is yenileme@example.net, and its payment link is https://panel.example.com.example.net/yenileme. These details belong to one fictional training scenario, not a customer incident. example.net represents the suspicious party only in this scenario; no actual abuse is alleged.

“Today” squeezes your thinking time. Threatened account closure raises the stakes, while payment becomes the apparent escape route. CISA identifies urgent or emotional language, suspicious sender addresses, and requests for personal or financial information as warning signs. Correct Turkish, a familiar logo, or a professional signature does not erase them.

Genuine renewal notices can include deadlines and payment details too. I would not judge by the subject alone: consider the sender and requested action together. The message cannot prove its own claims; a stated shutdown time does not establish that your provider has scheduled one.

Receiving a suspicious email does not prove your account is compromised. Receiving it, submitting information, and paying are different situations. Rather than letting its deadline dictate your response, check renewal status through the customer panel you already know-not the email’s button.

A Sender Name Is Not an Email Address

Your inbox may show “Example Domain Provider” while hiding a different address. Names are not proof. I read the sender-chosen label and address separately; expand the details, especially on mobile, where the full address may be hidden.

This hypothetical domain-renewal scenario contains no real personal data. The raw excerpt shows headers and body for the synthetic /home/analist/phishing-lab/supheli.eml file on Ubuntu Server 24.04 LTS. Here, example.net represents the suspicious party only; it implies no actual abuse.

From: "Example Domain Saglayicisi" <yenileme@example.net>
To: yonetici@example.com
Reply-To: yenileme@example.net
Return-Path: <yenileme@example.net>
Subject: Domain yenileme icin hesap dogrulamasi
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8

Bu, analiz amacli varsayimsal bir iletidir.
Domain yenilemeniz icin hesabinizi dogrulayin:
https://panel.example.com.example.net/yenileme

This is data, not a command. Expected client display: “Example Domain Saglayicisi,” with yenileme@example.net in the details; presentation varies. That differs from the known legitimate sender, yenileme@example.com. The three matching address fields do not establish legitimacy.

• Display name: A sender-line label; anyone can copy a brand name.
• From: Identifies the claimed author, not an independently verified identity.
• Reply-To: Specifies where replies should go, potentially somewhere unexpected.
• Return-Path: Records the envelope return address during delivery, used for delivery-failure notifications rather than ordinary replies.

RFC 7208 explains that SPF checks identities including SMTP’s envelope MAIL FROM, recorded in Return-Path upon delivery. RFC 7489 addresses alignment between the visible From domain and authenticated domains. These are distinct roles, not interchangeable “sender addresses.”

Legitimate bulk-mail services may use a provider’s envelope return address and a support-team Reply-To. Differences alone do not prove phishing; matching addresses do not guarantee safety. I would weigh known sending practices, authentication results from trusted receiving infrastructure, and the request together.

CISA flags suspicious sender addresses, unexpected attachments, and requests for personal information. Treat unexpected links cautiously too. Does this account-verification request fit your expected renewal? This example has no attachment; do not open or execute one accompanying such a suspicious request. Fluent Turkish and a familiar logo are not evidence of trustworthiness. Before replying, check renewal status at the known https://panel.example.com address.

Which Domain Does the Link Actually Lead To?

I start with the hostname, not the familiar name at the front. In this hypothetical domain-renewal email, your known panel is https://panel.example.com; the suspicious link is https://panel.example.com.example.net/yenileme. Different destinations. CISA lists suspicious links among phishing warning signs; displayed link text can also differ from the actual target.

The domain vs URL distinction helps here: https is the scheme, the server name after :// in these examples is the hostname, and /yenileme is the path. Compare panel.example.com with panel.example.com.example.net. The second belongs under example.net, not example.com; those familiar opening labels form a subdomain chain. Here, example.net represents only the scenario’s suspicious party.

Read right to left: net is the top-level domain, preceded by example, giving example.net. But taking the last two labels fails with multi-label public suffixes such as co.uk. Automated registrable-domain identification needs an up-to-date public suffix list. Counting dots is not a security check.

On Ubuntu Server 24.04 LTS, save this as /home/analist/phishing-lab/incele.py. Python 3.12’s standard-library urllib.parse parses both fixed addresses locally, without DNS queries, opening links, sending messages, executing attachments, or requiring root.

from urllib.parse import urlsplit

adresler = (
    "https://panel.example.com",
    "https://panel.example.com.example.net/yenileme",
)

for adres in adresler:
    parcalar = urlsplit(adres)
    print(f"şema={parcalar.scheme}")
    print(f"hostname={parcalar.hostname}")
    print(f"yol={parcalar.path!r}")
    print()

Run the file with:

python3 /home/analist/phishing-lab/incele.py

This expected output is illustrative, derived from the code-not a recorded test. The labels şema and yol mean scheme and path. !r displays the path in quotes; the empty path appears as ''. A browser normally requests / there.

şema=https
hostname=panel.example.com
yol=''

şema=https
hostname=panel.example.com.example.net
yol='/yenileme'

urlsplit neither judges trustworthiness nor identifies registrable-domain boundaries. HTTPS does not prove the owner’s honesty. With successful certificate validation, it encrypts transport and authenticates the server for the hostname; a suspicious party can obtain a certificate for its own domain. Both URLs using https does not erase their domain difference. Before opening the link, compare its full hostname with your known panel address-not the renewal button’s wording or a padlock.

What Do SPF, DKIM, and DMARC Verify?

I would not trust a renewal request just because it passes all three checks. Authentication is narrower. In this hypothetical scenario, the message to yonetici@example.com impersonates the provider’s display name but uses From address yenileme@example.net. Here, example.net represents only the suspicious party; authenticating it proves no relationship with your organization’s example.com.

SPF: RFC 7208 checks whether the connecting IP is authorized to send for the SMTP envelope sender’s domain: MAIL FROM, or HELO when the envelope sender is empty. It does not verify the visible From address, display name, or payment request.

DKIM: RFC 6376 defines signatures that verify the integrity of covered headers and body content; d= identifies the signing domain. A valid signature does not establish safety. Don’t assume every header is signed: verification covers only signed data.

DMARC: RFC 7489 requires the visible From domain to align with either the domain passing SPF or a domain with a valid DKIM signature. One aligned pass suffices. Relaxed alignment requires the same organizational domain; strict alignment requires an exact match. Policy requests treatment of failures, not trust in content.

The hypothetical attacker could pass using example.net. The link https://panel.example.com.example.net/yenileme still isn’t your known panel, https://panel.example.com. A compromised legitimate yenileme@example.com account sending through authorized infrastructure could also pass.

On Ubuntu Server 24.04 LTS, these BIND 9.18-family dig commands demonstrate query syntax only; security patch levels vary by installation:

dig example.com TXT +noall +answer
dig _dmarc.example.com TXT +noall +answer

Neither requires root, sends email, opens message links, nor executes attachments. Output would show answer-section TXT records, if present. Look for SPF’s v=spf1 and DMARC’s v=DMARC1; neither is assumed to exist on these reserved domains. Empty output doesn’t establish absence without checking query status. These queries don’t request DKIM keys.

Current DNS alone cannot reconstruct past authentication results. This scenario assumes the receiving service adds Authentication-Results. In real investigations, verify that header’s origin in trusted receiving infrastructure; a sender-added namesake is not evidence.

Inspecting Technical Clues Without Rendering the Message

I would keep the sender’s renewal screen out of this inspection. Disable previews. CISA recommends avoiding links and attachments in suspected phishing messages. This explicitly hypothetical domain-renewal scenario needs only headers and MIME types, not rendered HTML.

Use Ubuntu Server 24.04 LTS and Python 3.12’s standard library; security patch levels vary by installation. Assume the synthetic message exists at /home/analist/phishing-lab/supheli.eml. For real investigations, download the original from your mail client: forwarding or copying can alter headers. Preserve it in a restricted-access directory. These commands create /home/analist/phishing-lab/incele.py without modifying the .eml:

umask 077
cat > /home/analist/phishing-lab/incele.py <<'PY'
from email import policy
from email.parser import BytesParser
from pathlib import Path

kaynak = Path('/home/analist/phishing-lab/supheli.eml')
with kaynak.open('rb') as dosya:
    ileti = BytesParser(policy=policy.default).parse(dosya)

basliklar = (
    'From', 'To', 'Subject', 'Date', 'Message-ID',
    'Reply-To', 'Return-Path', 'Received',
    'Authentication-Results', 'DKIM-Signature',
)
for ad in basliklar:
    degerler = ileti.get_all(ad, [])
    if not degerler:
        print(f'{ad}: [yok]')
    for deger in degerler:
        print(f'{ad}: {ascii(str(deger))}')

print('\nMIME parcalari:')
for sira, parca in enumerate(ileti.walk(), start=1):
    print(
        sira,
        'tur=', ascii(parca.get_content_type()),
        'sunum=', ascii(parca.get_content_disposition()),
    )
    for kusur in parca.defects:
        print('  ayristirma_kusuru=', type(kusur).__name__)
PY
python3 /home/analist/phishing-lab/incele.py

BytesParser parses the binary-opened file; walk() traverses MIME parts, including containers. The script neither prints bodies, extracts or executes attachments, sends mail, nor downloads remote content. No root required. ascii() escapes control characters instead of emitting them directly to your terminal; Turkish characters are escaped too. umask 077 restricts newly created script permissions, not existing files.

Output depends on the file; no test output is claimed here. Expect From to contain the provider-impersonating name and yenileme@example.net, and To to contain yonetici@example.com. The legitimate sender is yenileme@example.com; example.net represents only this scenario’s suspicious party. Missing headers show [yok] (absent).

A text/html entry does not mean HTML was rendered. attachment is a declared disposition, not a safety verdict. An absence of parsing defects proves no trustworthiness either.

Assume the receiving service adds Authentication-Results; verify that header’s trusted receiving-infrastructure origin in real investigations. The script lists values without validating them. RFC 6376 describes DKIM’s verifiable association between a signing domain and a message-not proof that a renewal request is honest.

Local parsing cannot guarantee harmlessness: large or malformed files can consume resources, and parsers can have vulnerabilities. Use an updated, restricted-privilege environment. Never upload real messages to public analysis services; they may contain personal information or access tokens. If support needs the message, preserve the original and redact sensitive fields in a separate copy.

Verify the Renewal Request Independently of the Email

A genuine renewal deadline does not make an emailed payment link trustworthy. In this hypothetical scenario, I would treat the message to yonetici@example.com as a warning to check, not a payment channel. CISA recommends contacting organizations independently of suspicious messages. Slow down. A shutdown threat does not justify skipping verification.

In a new tab, type https://panel.example.com or use your verified bookmark, never https://panel.example.com.example.net/yenileme. Here, example.net represents only the hypothetical suspicious party. Replies, supplied phone numbers, and suggested support addresses are not independent channels. A search advertisement cannot replace your saved panel address either.

Open example.com in the panel. Check its expiration date and renewal period; compare the invoice’s domain, amount, due date, and payment status against the email. Check automatic renewal, payment-method validity, and failed-charge notices. Enabled automatic renewal does not prove payment succeeded; invoice deadlines and domain expiration dates need not match.

Check account notifications for the request. Its absence alone does not prove fraud. Resolve discrepancies through a panel support ticket or previously saved support channel; confirm the domain, deadline, and invoice. Report the actual From address, yenileme@example.net, versus the expected yenileme@example.com. Never share passwords, one-time codes, or card details.

A real renewal requirement does not legitimize a fraudulent payment link. Correct dates or amounts do not prove the provider owns that link. Renew through the known panel’s billing workflow without returning to the email.

Password-manager domain matching adds a warning layer. If expected autofill fails, check the address before pasting your password. Matching depends on the product and settings; autofill’s presence or absence alone cannot establish safety.

If the panel supports them, passkeys provide phishing-resistant login bound to the service’s domain. They do not validate payment requests or, by themselves, prevent session theft or compensate for weak account recovery. Protect alternative login methods too. After paying, check the payment record in that same panel and, once renewal completes, the updated expiration date.

If You Clicked, Your Next Step Depends on What Happened

Stop first. In this hypothetical renewal scenario involving yonetici@example.com, I would start by identifying what happened. Apply every relevant response below: password changes cannot reverse permissions or payments.

Only opened the link? Close https://panel.example.com.example.net/yenileme; do not revisit it. Clicking alone does not prove compromise. Check downloads and site permissions without opening downloaded files; verify browser and operating-system updates. Even without entering information, watch for unexpected login alerts. Check accounts through known addresses, not notification links.

Entered a password? From a trusted device, change it through the known panel address. Replace reused passwords with unique ones, especially for your recovery mailbox. End all sessions; check recovery addresses and MFA methods. Signing out of one browser is insufficient.

Approved MFA? You may have completed an attacker’s login. From a trusted device, change the password, end all sessions, revoke access tokens where supported, and remove unfamiliar authentication methods. If access is lost, request a temporary account lock from the provider. Reject further verification requests.

Granted OAuth permission? Using a trusted device, revoke the suspicious authorization under connected applications. Password changes do not necessarily remove it. Record which data the application could access; revocation cannot retrieve previously copied data.

For password, MFA, or OAuth exposure, inspect mail forwarding, inbox rules, and sent messages. Check panel activity for DNS changes, domain transfers, contact details, and new API keys. Report unfamiliar actions with timestamps to the provider.

Paid or entered card details? Immediately contact your bank or payment provider through its known app or phone number. Provide the amount, time, and transaction reference; ask about card protection and dispute options. Refunds are not guaranteed.

Executed a file? Disconnect the device from the network and get technical support. Recover accounts from another trusted device. Record the filename and execution time; avoid improvised cleanup that could erase evidence.

CISA recommends reporting suspected phishing. Preserve the original message, including headers, plus action timestamps and time zone; contact the provider’s known support channel without sharing passwords or verification codes. Keep the synthetic message at /home/analist/phishing-lab/supheli.eml. Bookmark https://panel.example.com, the known panel address, for your next renewal.

Check Before Paying for a Renewal

• Pause rather than act on urgency; do not open the email's links or attachments.
• Inspect the From, Reply-To, and Return-Path addresses separately from the sender's display name.
• Identify the link's hostname without visiting it and compare it with the domain you expect.
• Assess email authentication results only through headers added by trusted receiving infrastructure.
• Compare the domain expiration date, invoice, automatic renewal status, and account notifications in your previously known customer panel.
• Preserve the original message and receipt time, then report it through your provider's saved support channel.
• Apply the security response appropriate to what you did and bookmark the verified panel address.

Frequently Asked Questions

Sources

• CISA – Recognize and Report Phishing — cisa.gov
• RFC 7208 – Sender Policy Framework for Email Authorization — rfc-editor.org
• RFC 6376 – DomainKeys Identified Mail Signatures — rfc-editor.org
• RFC 7489 – DMARC Domain Alignment and Policies — rfc-editor.org