Email Spoofing Checker: Is This Email Real or Fake?
Paste an email's header to see what your email provider found when it checked the sender, plus the tricks those checks miss: fake display names, reply-to switches and look-alike domains.
- Header never leaves your browser
- SPF, DKIM and DMARC explained
- No sign-up
What your provider checked
Warning signs
Header details and delivery path
See how well a domain is protected against unauthorized senders using its name. Useful for your own business domain, or before trusting an unfamiliar sender.
How to test it
- Press fake bank email. The result should show Authentication failed with a Reply-To warning.
- Press passing example. It should show an authenticated domain with no warning signs.
- Open a real email you trust, copy its full header and paste it. Then press Check the sender's domain.
Email headers are checked entirely in your browser. Domain checks: 20 per hour.
How this email spoofing checker works
Reads your provider's verdict
When an email arrives, major providers evaluate SPF, DKIM and DMARC and record the result in an Authentication-Results header. We evaluate the primary provider line to prevent lower untrusted headers from misleading the result.
Spots what technical checks miss
Authentication verifies the authorized domain, not the sender's real intentions. We also check for deceptive display names, reply-to rerouting, and domains that visually imitate well-known brands.
Checks any domain's protection
The domain tab inspects public DNS records for SPF, DMARC, DKIM and MTA-STS to show how strictly the domain instructs receivers to enforce authentication policies.
Check it yourself. Open your browser's developer tools (F12) to the Network tab: no outbound requests are made when analyzing a header. The domain tab sends only the domain name you query to look up its public DNS records.
Email problems this tool helps with
Find the situation you're in. Each answer points to the part of the tool that settles it.
| Your situation | What to look at | Action |
|---|---|---|
| A suspicious email | ||
| My "bank" asks me to update KYC or unlock my account | DMARC in What your provider checked, and whether the From domain is genuine. Your bank should never ask for OTPs or PINs by email. | |
| A supplier or executive asks to pay a new bank account | The Reply-To warning. Invoice fraud often sends from a real-looking address but routes your reply to an external inbox. Confirm account changes by phone. | |
| Authentication passes, but something still looks suspicious | The look-alike domain warning. Threat actors can register look-alike domains with their own valid authentication records. | |
| Your own domain | ||
| Unauthorized senders are sending email using my brand | The DMARC row. Transition from p=none to quarantine and reject once legitimate email sources are aligned. | |
| My business emails land in spam | SPF lookup limits (under 10), syntax errors, or missing DKIM keys that cause legitimate email delivery to fail. | |
How the verdict is decided
SPF verifies whether the sending IP address is authorized by the domain owner. DKIM validates an authentic cryptographic signature. DMARC ensures that at least one of these mechanisms passed and aligns with the domain shown in the visible From address.
Authentication failed means the message did not satisfy DMARC policy for the From domain. Authenticated domain means the message passed DMARC or achieved alignment. Not verified indicates that no conclusive authentication data could be validated.
Technical authentication confirms domain authorization, not the trustworthiness of the sender. An authenticated message can still originate from a look-alike domain or a compromised legitimate mailbox.
Sources: RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 (DMARC), RFC 8601 (Authentication-Results).
What each SPF, DKIM and DMARC result means
| Result | Meaning | Assessment |
|---|---|---|
pass | The check succeeded for the specified domain. | Positive technical signal, provided the domain itself is legitimate. |
fail | The domain's policy did not authorize this server or signature. | Suspicious indicator of unauthorized sending or spoofing. |
softfail | The sender is likely not authorized, but the domain owner requested leniency. | Treat with caution. Verify DMARC alignment. |
neutral | The domain owner makes no explicit authorization statement. | Unconfirmed sender identity. |
none | No SPF or DMARC record published. | Unprotected domain; easy to spoof. |
temperror / permerror | A DNS timeout occurred or the published record contains syntax errors. | Technical error. Treat message with extra caution. |
Mistakes that let spoofed emails through
Attackers design deceptive emails around these common shortcuts.
The display name is completely arbitrary. Always inspect the actual email address inside the angle brackets.
Passing checks validates the domain, not the sender's integrity. Look-alike domains and compromised accounts pass authentication too.
Reply-To headers can redirect answers to third-party accounts. Always verify financial updates over an established secondary channel.
Without the receiving provider's Authentication-Results header, security checks cannot be evaluated. Always copy the full original source.
Habits that stop email spoofing
When you receive email
- Inspect the full email address carefully before acting on urgent requests.
- Navigate directly to service portals via bookmarks or known URLs, not email links.
- Confirm payment and account changes through a known telephone contact.
- Use your email provider's native Report Phishing functionality.
- Enforce two-factor authentication (2FA/MFA) on your own email accounts.
For your own domain
- Publish an SPF record that stays well under the 10 DNS lookup limit.
- Enable DKIM cryptographic signing across all sending services.
- Enforce DMARC (quarantine or reject) with reporting enabled (rua).
- Secure non-sending domains with "v=spf1 -all" and a DMARC reject policy.
- Audit records whenever onboarding third-party marketing or transactional senders.
Frequently asked questions
Short answers about privacy, results and what to do next.
Is my email header sent to your server?
No. The header check runs entirely in your browser, so the header never leaves your device. Only the Check a domain tab contacts our server, and it sends just the domain name you type.
The email passed SPF, DKIM and DMARC. Is it safe?
It proves the email passed technical authentication for the domain in the From address. It does not prove that the domain or sender is trustworthy: scammers can register look-alike domains with valid records, or use compromised authentic accounts. Always verify the domain letter-by-letter and confirm unexpected payment or credential requests.
Why does the tool read the top Authentication-Results line?
Your email provider adds its own Authentication-Results line at the top when the email arrives. Lower authentication lines may have been added by earlier mail servers or intermediaries, so the top line provides the most reliable provider verdict.
What do softfail, neutral and none mean?
Softfail means the sending server isn't on the domain's approved list, but the owner asked receivers to be lenient. Neutral means the owner makes no statement. None means no record was published, so nothing could be checked. None of these confirm the sender.
Where do I find the full email header?
In Gmail, open the email, press the three-dot menu and choose Show original. In Outlook on the web, press the three-dot menu, then View, then View message source. The 'How to copy the header' box on this page has steps for other apps.
Why can't the domain check find a DKIM key?
DKIM keys are stored under a name called a selector that only the sender chooses. We try common selectors, but many companies use their own. Paste an email header first, and the tool fills in the right selector from its DKIM signature.
What should I do with a spoofed email?
Don't click links, open attachments or reply. Use your email app's Report phishing button, forward it to the real company's phishing address if it has one, and in India report fraud at cybercrime.gov.in or by calling 1930.