@Mail Domain Check

Wallet alerts · exchange notices · DAO messages

Crypto phishing email header check

Inspect who authenticated a suspicious message and how it reached your mailbox before you click a link, connect a wallet, approve a transaction, or enter a recovery phrase.

First, stop the requested action

Do not use the message link to sign in, connect a wallet, approve a token, sign a typed message, or reveal a password, two-factor code, seed phrase, or private key. Open the claimed service through its official app or a known bookmark and check whether the alert exists there.

A passing SPF, DKIM, or DMARC result does not make a link, contract, attachment, or transaction safe. It only describes message authentication evidence reported by a receiving system.

Copy the complete message header

  1. In desktop Gmail, open the message, choose More next to Reply, select Show original, and copy the full header.
  2. In new Outlook, open More actions, then View and View message details. In classic Outlook, use File and Properties.
  3. Paste the header into the local analyzer. Text after the first blank line is ignored, and the header is not uploaded.

Read five separate evidence layers

Visible From
The address shown to the recipient is only one claimed identity. Compare its domain with the authenticated SPF and DKIM identities.
SPF
A pass applies to the SMTP MAIL FROM or HELO identity and sending IP. It does not automatically authenticate the visible From address.
DKIM
A pass validates a signature made by the d= domain. Record the s= selector so the current public key can be checked independently.
DMARC
A pass means the receiver found a passing SPF or DKIM identity that aligned with the visible From domain under the applicable policy.
Received route
Received fields are normally newest first. Hops below your receiving system's trust boundary may be forged, so routing is an investigation clue rather than proof of origin.

Interpret the result without overclaiming

  • DMARC fail with SPF or DKIM pass: authentication may have succeeded for a vendor domain that does not align with the visible sender.
  • SPF and DKIM fail: the selected receiver results show no passing authentication path, but the message still needs provider-side investigation.
  • DMARC pass: the message authenticated as the visible domain at that receiver. A compromised legitimate account or malicious link can still be dangerous.
  • Multiple Authentication-Results fields: trust only the authserv-id and fields your mailbox provider says belong to its receiving boundary.
  • Out-of-order route times: clock skew or an untrusted Received field may be involved; do not infer geography or authorship from one timestamp.

Verify the claimed service independently

Compare the visible sender and authenticated domains with the service's own published support information. Coinbase, for example, publishes its email domains and asks phishing reports to include full headers. MetaMask advises checking suspicious sites and transactions through its own trust signals and official channels rather than relying on a message alone.

If you operate the claimed sending domain, run a live public-DNS check after analyzing the message. Historical headers show what one receiver reported at one time; they do not prove what SPF, DKIM, DMARC, PTR, or MTA-STS publishes now.

For teams responsible for the sending domain

The free checks expose the current risk summary. A complete report costs 5 native USDC on Base Mainnet and includes the full public evidence, prioritized remediation actions, and a printable delivery view. Payment verification and delivery are automatic after two confirmations; the report assesses domain publication, not whether a specific email link or transaction is safe.

Primary references