Why Phishing Emails Sometimes Match the Subject Lines of Real Notifications You Receive

The Scenario That Sends People Into a Panic

You get an email with the subject "New test results from MyChart." You have a child whose medical portal uses MyChart. Then a few days later, another email arrives with the subject "MyChart" -- clearly phishing, obviously suspicious. You start wondering: how do they know what emails I receive? Did someone read my inbox?

Here is the short answer. Matching subject lines almost never mean your inbox has been accessed. The phishing email is not coming from inside your account. It is coming from an external sender who knows something about you that has nothing to do with your email password.

This article explains why this happens, what it actually means, how to investigate using email headers, and what steps are worth taking.

Why Matching Subjects Almost Never Mean Mailbox Compromise

Phishing campaigns are not random. The people running them do research. They buy data. They scrape breach databases. If your email address appears in a healthcare breach, an attacker knows you have a MyChart account -- without ever touching your inbox.

The result: you receive legitimate MyChart notifications and phishing emails that look related, because both use the same publicly-known subject-line templates. The phishing is contextual, not intrusive.

A security analyst responding to a similar case put it plainly: the subject overlap is usually a sign that healthcare notification templates are boilerplate and discoverable. The phishing campaign is casting a wide net using those templates, not reading your inbox to craft a targeted message.

This is a crucial distinction. Mailbox compromise means someone has credentials and direct access to your account. Phishing with contextual subject lines means someone outside your account knows enough about you to make their messages believable -- but has not actually breached your inbox.

The Real Risk: Spoofed Domains, Not Hacked Inboxes

Here is what is actually going on in most of these cases.

The phishing email is not being sent from your account. It is being sent from an external server with your healthcare provider's domain forged in the From address. The attacker hopes your email client will display the friendly name or subject line in a way that makes the message look credible.

This works because many healthcare portal domains publish DMARC records but set the policy to p=none. DMARC at p=none tells receiving mail servers to check authentication but take no action regardless of the result. Anyone can send email claiming to be from that domain and it will still be delivered. The domain looks legitimate because it is legitimate -- it just is not enforcing who can use it.

Epic MyChart, one of the most widely used patient portal platforms in the United States, is a frequent spoofing target for exactly this reason. High-value, widely-used services with weak DMARC enforcement are attractive to attackers because the From domain will pass casual scrutiny from recipients.

This is spoofing, not account compromise. And it is a problem that domain owners can fix.

How to Investigate with Email Headers

If you want to know for certain whether a suspicious email is being sent from a spoofed domain, look at the full email headers.

Gmail:
Open the email. Click the three dots (More). Select "Show original." That page contains the full header block.

Outlook:
Open the email. File > Properties. Look for "Internet headers."

Apple Mail:
Open the email. View > Message > Raw Source.

Once you have the headers, find the Authentication-Results section. You are looking for three things: SPF, DKIM, and DMARC.

SPF tells you whether the sending server is authorized to send email for the From domain. DKIM tells you whether the message was signed with the domain's private key and verified at delivery. DMARC tells you whether SPF and DKIM both aligned correctly with the From domain.

Here is what a DMARC failure looks like in practice. A receiving mail server checks an email with From: noreply@mychart-example.com. SPF might pass for the sending server, DKIM might sign for a subdomain, but DMARC alignment fails because the From domain does not match the SPF or DKIM domain. The Authentication-Results header shows: dmarc=fail header.from=mychart-example.com.

If you see dmarc=fail on an email claiming to be from your healthcare portal, that email was not sent by your portal. It was spoofed.

If you see dmarc=pass, the email authenticated correctly. The issue in that case is either a legitimate send from the portal or a breach at the portal's own systems -- not your inbox.

What to Actually Do

The right response depends on what the headers show.

If DMARC fails on a supposed healthcare notification:

• Do not click any links in the email.


• Report the email to your email provider as phishing.


• Go directly to the portal's website -- not through any link in the email -- and check your account for unusual activity.


• Change your portal password and enable MFA if you have not already.

If DMARC passes:

• The email may actually be from the real organization.


• Forward the suspicious email to the portal's security or support team.


• You still do not need to panic about your own inbox being compromised.

Regardless of what you find in headers:

• Check recent sign-ins and active sessions on your email account. Gmail: Manage your Google Account > Security > Your devices. Outlook: microsoft.com security dashboard. If you see devices or locations you do not recognize, treat that as a real compromise signal.


• Review your email forwarding rules and filters. An attacker with account access often sets up a silent forwarding rule to monitor your inbox without your knowledge.


• Enable MFA on your email account and on any portal that sends you notifications. MFA prevents most account takeover attempts even if your password is exposed in a separate breach.

When It Is More Serious

Most of the time, contextual phishing with matching subjects is opportunistic. Attackers bought a list. They sent a template. It landed in your inbox because your address was on that list.

Targeted spear phishing is different. If an attacker has been reading your actual inbox conversations and references specific things you have sent or received -- not a public template, not a breach database, but private conversation content -- treat it as a real account compromise and respond accordingly.

The distinction matters. Broad phishing campaigns are noisy and generic. Targeted attacks are quiet and specific.

This is also where DMARC aggregate reports add value that individual users cannot get on their own. These reports show domain owners exactly how much email is being sent spoofing their domains, including email that was successfully delivered to recipients. A security team using DMARC monitoring can see the volume and source of spoofing attempts -- and act on them -- even if no recipient ever reports the phishing. Without this visibility, an organization has no way to know how many people are receiving spoofed emails purporting to be from their domain.

The Larger Pattern: Why Healthcare Portals Keep Getting Used for Phishing

MyChart is not unique. The same dynamics apply to pharmacy portals, lab result notification systems, insurance portals, and any service that sends templated email notifications to large user bases. The more widely used a portal is, the more valuable it is as a spoofing target -- because more potential victims will recognize the name.

The core problem is that many of these organizations publish DMARC records but do not enforce them. They go through the motions of email authentication without actually blocking unauthorized sends. This is sometimes called "DMARC decoration." The record exists, but p=none means it changes nothing about what gets delivered.

Organizations that want to protect their users from spoofing need to move to p=quarantine (which sends suspicious mail to spam) or p=reject (which blocks it entirely at the receiving server). Both require preparation: auditing legitimate sending sources, setting up proper SPF and DKIM, and reviewing DMARC aggregate reports to catch gaps before tightening the policy.

For organizations that send transactional or notification email at scale, DMARCFlow makes this easier by aggregating DMARC reports, surfacing authentication failures, and showing which sending infrastructure is causing alignment problems before you move to a stricter policy.

FAQ

Q: If the phishing email has the same subject as a real email I received, does that mean my email was hacked?
Almost never. It usually means the attacker knows you use a particular service from breach data or data broker lists, and is using the same notification template that service uses. Your email account itself is likely fine.

Q: Should I change my email password?
Changing your password is reasonable, but it is not the most important step. Check for unknown devices and active sessions first. Enable MFA. Password change matters most if you have already confirmed unauthorized access.

Q: I use MFA on my email. Am I safe from this?
MFA significantly reduces the risk of account takeover. However, if the healthcare portal sending you notifications has weak DMARC enforcement, attackers can still send spoofed emails to you and others pretending to be that portal. MFA protects your account. It does not protect you from spoofed emails that appear to come from organizations you trust.

Q: Who can actually fix the spoofing problem?
The organization whose domain is being spoofed. If your healthcare portal has DMARC at p=none, they can change it to p=quarantine or p=reject. You can report spoofed emails to the organization, but the fix has to come from their IT or security team.