@Mail Domain Check

Web3 · transactional email · anti-spoofing

Web3 email security check

Check whether wallet alerts, governance notices, launch emails, and newsletters can authenticate as your domain before recipients treat them as spoofed or unauthenticated.

Why authentication matters more for financial messages

A wallet alert or governance notice asks the recipient to trust a financially sensitive action. When SPF, DKIM, or DMARC fails, a legitimate message can look indistinguishable from a phishing attempt. When DMARC is missing or remains unenforced without monitoring, attackers may also have more room to impersonate the visible From domain.

Web3 teams often send through several systems: a transactional provider, a newsletter platform, a support desk, and an incident tool. Each system can authenticate correctly on its own while still failing DMARC alignment with the domain a recipient actually sees.

Match each message path to evidence

Wallet and login alerts
Verify the visible From domain, the DKIM signing domain, the SPF MAIL FROM domain, and DMARC alignment using a real delivered message header.
Newsletters
Check SPF, DKIM, DMARC, PTR, and TLS, then separately test one-click unsubscribe, consent, complaint rate, and current provider-specific bulk-sender rules.
Vendors and subdomains
Inventory every sender before tightening policy. Confirm whether subdomains inherit the organizational-domain policy or publish an intentional record of their own.
Dedicated sending IPs
Use the actual outbound IP to verify PTR and forward-confirmed A or AAAA records. A domain-only scan cannot prove reverse DNS.
Receiving mail
Validate the MTA-STS DNS announcement, fixed HTTPS policy, MX patterns, mode, max_age, and companion TLS-RPT publication.

What the free check verifies

The scanner reads public MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT, CAA, and optional sending-IP DNS. It reports current publication and structural risks without asking for a mailbox login, wallet key, DNS credential, or message body.

Public DNS cannot prove inbox placement, sender reputation, user consent, complaint rate, message-body safety, or whether a recipient should trust a transaction link. Use a real message header and provider logs for those decisions.

A safer remediation sequence

  1. List every system that sends as the visible From domain, including incident, support, CRM, newsletter, and authentication services.
  2. Send one controlled message through each path and preserve its complete header.
  3. Confirm SPF or DKIM passes and that at least one passing identity aligns with the visible From domain.
  4. Remove duplicate SPF records, broken include chains, stale DKIM selectors, and unintended DMARC conflicts.
  5. Monitor aggregate DMARC evidence before increasing enforcement, and keep emergency senders in the inventory.
  6. Recheck PTR, TLS, unsubscribe behavior, and provider rejection codes independently of DNS authentication.

Complete evidence, paid in Base USDC

The free result shows the current risk summary. A complete report costs 5 native USDC on Base Mainnet and includes full evidence, prioritized remediation actions, and a printable delivery view. Each checkout receives a dedicated address; the report unlocks automatically after the payment reaches two confirmations.

Only the exact network, USDC contract, recipient, and amount shown in the active checkout can unlock a report. A wallet also needs a small amount of Base ETH for gas.

Focused diagnostic tools

Primary references