Phishing Awareness Game

Read each message, choose phishing or legitimate, then see why - including where the real link goes.

← Back to portfolio
Best score: 0Best streak: 0Runs: 0

Email Security Training

Short plain-language notes on SPF, DKIM, DMARC, CompAuth, ARC, DNSSEC, MX, SMTP ports, STARTTLS, EHLO, SEG, and related email auth basics.

Authentication and Trust

SPF (Sender Policy Framework)

SPF is a DNS list of servers allowed to send mail for a domain.

  1. Receivers check the sending IP against that list and get a pass or fail style result.
  2. SPF does not protect the From name people see. Use it with DMARC.
  3. Keep the record simple. Too many DNS lookups can break the check.

DKIM (DomainKeys Identified Mail)

DKIM is a digital signature that proves a domain signed the message and it was not changed in transit.

  1. The sender signs parts of the mail. The receiver checks the public key in DNS.
  2. A valid signature builds trust in the signing domain. It does not prove the visible From alone is honest.
  3. Rotate keys and sign important headers like From and Subject.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

DMARC checks that SPF or DKIM matches the From domain users see, then says what to do on failure.

  1. Policies can monitor (none), quarantine, or reject failing mail.
  2. Reports help you spot spoofing and setup mistakes.
  3. DMARC is what stops direct domain spoofing used in phishing and BEC.

BIMI (Brand Indicators for Message Identification)

BIMI can show your brand logo in supporting inboxes when DMARC is strong.

  1. You need enforced DMARC plus a BIMI DNS record that points to a logo.
  2. Some providers also want a verified mark certificate.
  3. BIMI is a trust badge. It does not replace SPF, DKIM, or DMARC.

CompAuth (Microsoft composite authentication)

CompAuth is Microsoft's overall authenticity score for a message in Exchange Online.

  1. You will see it in Authentication-Results with SPF, DKIM, and DMARC.
  2. It weighs more than one signal, including reputation and alignment.
  3. When reviewing phishing in Microsoft 365, read CompAuth with the other auth results.

ARC (Authenticated Received Chain)

ARC keeps earlier auth results when mail is forwarded or rewritten by a middle hop.

  1. Lists and gateways often break DKIM when they change a message.
  2. ARC seals what the previous hop already checked.
  3. It helps legitimate forwarded mail. It is not a free pass for spoofing.

DNSSEC (DNS Security Extensions)

DNSSEC signs DNS answers so forged records are harder to slip in.

  1. Fake DNS can redirect mail or fake SPF and DKIM records.
  2. Email auth depends on honest DNS. DNSSEC strengthens that base.
  3. Records must be published and resolvers must validate for it to help.

MTA-STS (SMTP MTA Strict Transport Security)

MTA-STS tells senders to use TLS for your inbound mail and refuse cleartext downgrades.

  1. You publish a DNS marker and a short HTTPS policy file.
  2. Supporting senders enforce TLS to your MX hosts.
  3. Keep MX certificates healthy so enforcement does not cause outages.

DANE / TLSA

DANE ties the expected TLS certificate for SMTP to DNS using TLSA records.

  1. It needs DNSSEC. Without validated DNSSEC, TLSA cannot be trusted.
  2. Where supported, it hardens SMTP TLS beyond normal web certificates alone.
  3. Many teams use MTA-STS as the simpler TLS enforcement option.

SMTP and Transport

SMTP (Simple Mail Transfer Protocol)

SMTP is the protocol servers use to move email across the internet.

  1. Mail usually goes from your client to a submission server, then hop to hop, then into a mailbox.
  2. Today that path is filtered and usually encrypted with TLS.
  3. Knowing the hops helps you read Received headers in phishing reviews.

SMTP Ports (25, 465, 587, 2525)

Different SMTP ports serve different jobs: relay between servers vs user submission.

  1. Port 25 is server-to-server delivery.
  2. Port 587 is the usual authenticated submission port. Port 465 uses TLS from the start.
  3. Port 2525 is a common backup when 587 is blocked. Follow your provider's guidance.

STARTTLS vs Implicit TLS

STARTTLS upgrades a plain SMTP session to encryption. Implicit TLS encrypts as soon as you connect.

  1. STARTTLS starts clear, then switches after EHLO.
  2. Without a policy like MTA-STS or DANE, an attacker may try to strip STARTTLS.
  3. Always check certificates. Encryption alone does not prove you reached the real server.

EHLO and HELO

EHLO and HELO are the SMTP hello commands. EHLO also lists what the server supports.

  1. Modern clients should use EHLO.
  2. After STARTTLS, clients usually send EHLO again.
  3. Odd greetings can be a weak clue. They are easy to fake, so do not trust them alone.

MAIL FROM vs From Header

MAIL FROM is the envelope sender used for bounces and SPF. From is what users see.

  1. These two can differ on both real systems and phishing mail.
  2. SPF checks the envelope. DMARC checks alignment with the visible From domain.
  3. Teach people to look past the display name to the real address.

VRFY and EXPN

VRFY asks if an address exists. EXPN expands a mailing list. Both help attackers harvest addresses.

  1. Leave them disabled on internet-facing mail servers.
  2. If VRFY is open to the world, treat it as a hardening issue.

Bounces and NDRs

A bounce or NDR says delivery failed. Attackers also fake failure notices to lure clicks.

  1. Forged envelope senders can flood innocent domains with bounce spam.
  2. SPF and DMARC reduce that noise.
  3. Treat unexpected "delivery failed" mail with links as suspicious.

DNS and Routing

MX (Mail Exchanger)

MX records say which servers receive mail for a domain and in what order.

  1. Senders look up MX, then connect to those hosts.
  2. Backup MX hosts still need filtering or they attract spam.
  3. Fresh domains with weak MX and no auth can be a triage clue, not proof alone.

A and AAAA Records

A and AAAA records map hostnames to IPv4 and IPv6 addresses.

  1. MX names must resolve to addresses before mail can connect.
  2. Address changes need matching firewall, certificate, and SPF updates.
  3. Suspicious sending IPs in Received headers are worth a reputation check.

PTR / Reverse DNS (rDNS)

PTR maps an IP back to a hostname. Many receivers expect clean reverse DNS for SMTP.

  1. Missing or messy rDNS can hurt delivery reputation.
  2. It is hygiene, not a cryptographic control like DKIM.

TXT Records for Email Auth

DNS TXT records hold SPF, DMARC, DKIM keys, BIMI, MTA-STS markers, and similar policies.

  1. DMARC lives at _dmarc.example.com. DKIM keys live under selector._domainkey.
  2. Protect your DNS account. Stale SPF includes often cause sudden auth failures.

Email Security Stack

SEG (Secure Email Gateway)

A SEG filters mail for spam, phishing, malware, and data loss before it reaches inboxes.

  1. It may sit on MX or as a cloud filter in front of Microsoft 365 or Google Workspace.
  2. Common tools include URL rewriting, attachment sandboxing, and AI phishing models.
  3. Training plus a SEG works better than either one alone.

MTA (Mail Transfer Agent)

An MTA is software that relays email between servers.

  1. Examples include Postfix, Exim, Exchange Transport, and cloud mail relays.
  2. Internet-facing MTAs must block open relay abuse and protect submission logins.

MSA (Mail Submission Agent)

An MSA accepts mail from user apps after login, usually on port 587.

  1. Require strong auth, TLS, and rate limits so stolen accounts cannot spam freely.
  2. Keep submission separate from inbound MX when you can.

MDA (Mail Delivery Agent)

An MDA places accepted mail into the final mailbox.

  1. This is the last hop into inbox, quarantine, or archive.
  2. For incidents, match delivery logs with SEG verdicts and auth results.

Journaling and Archiving

Journaling copies mail into a compliance archive for retention and legal search.

  1. Users often never see the journal copy.
  2. Lock archives down. They hold sensitive business mail and phishing evidence.

Phishing vs Spoofing vs BEC

Phishing tricks people. Spoofing fakes identity. BEC steals money through business workflows.

  1. Phishing uses deceptive links, files, or login prompts.
  2. Spoofing forges From or display names. DMARC blocks many direct domain spoofs.
  3. BEC often comes from a real compromised mailbox, so auth can still pass.

Headers and Forensics

Authentication-Results

Authentication-Results records SPF, DKIM, DMARC, ARC, and sometimes CompAuth at a receiving boundary.

  1. Trust results only from your own mail edge or a hop you control.
  2. Attackers can add fake auth headers earlier in the chain.
  3. Check the authserv-id to see who asserted the result.

Received Header Chain

Each server hop adds a Received line. Newest is usually on top.

  1. Start from your trusted edge. Lower lines may be forged.
  2. Note IPs, hostnames, TLS notes, and odd delays.
  3. Compare suspicious IPs with SPF and reputation data.

Reply-To vs From

Reply-To sets where replies go. From is the identity shown in the inbox.

  1. Phishers often impersonate a brand in From and collect replies elsewhere.
  2. A trusted From with an unrelated Reply-To domain deserves a second look.
  3. Some real ticketing systems also use Reply-To. Context matters.

Message-ID

Message-ID is a unique ID for one message. Teams use it to join logs across systems.

  1. Capture it early in an incident.
  2. Odd or missing IDs can be a weak signal. They are not proof by themselves.