Email Domain Spoofing Checker

Server assisted New Internet Security & Privacy

Enter the domain of a From address and the Mutqan server reads its MX, SPF, DMARC, MTA-STS, TLS-RPT and BIMI records through public DNS resolvers, then rates the spoofing risk — low, medium or high — from the published policies alone, with every rule that decided the level and what to publish to stop forgery. Paste a suspicious message's headers to see, in your browser, the SPF, DKIM and DMARC results the receiving server recorded.

Privacy: The name you look up is sent from the Mutqan server to the public DNS resolvers named in the results. Nothing is stored.

How do SPF, DKIM and DMARC stop someone from sending email in your domain's name?

SPF (RFC 7208) lists the servers allowed to send for a domain and DKIM (RFC 6376) signs messages with a key in DNS, but neither checks the From address people see. DMARC (RFC 7489) does: a message passes only when SPF or DKIM passes for a domain aligned with From, and the domain's p= policy tells receivers to deliver (none), quarantine or reject the rest — so a domain is protected against direct spoofing only once it publishes p=quarantine or p=reject.

Security note: DMARC protects the exact domain only. Look-alike domains and forged display names pass every check, so payment changes and credential requests arriving by e-mail still need confirmation through another channel.

How to use Email Domain Spoofing Checker

  1. Enter the domain from the From address (example.com); an e-mail address or a URL is reduced to the domain.
  2. Optionally paste the headers of a suspicious message (Gmail: Show original; Outlook: View message source). With the domain field empty, the From domain is taken from them.
  3. Press Check domain, read the spoofing risk and the reasons, then the SPF and DMARC details.
  4. Work through What to do next from the top, and run the check again after each DNS change once its TTL has passed.

Email Domain Spoofing Checker features

  • Reads the domain's MX, SPF, DMARC, MTA-STS, TLS-RPT and BIMI records in one run through public DNS-over-HTTPS resolvers
  • Rates how easily mail in the domain's name can be forged — low, medium, high or unknown — from the published SPF and DMARC policies, and lists every rule that decided the level
  • Follows DMARC up to the organizational domain, so a subdomain without its own record is judged by the policy that really applies to it (sp= or p=)
  • Shows the SPF ending (-all, ~all, ?all, +all or a redirect), its DNS-lookup terms and duplicate records, and the DMARC policy, percentage, alignment modes and report addresses
  • Optionally reads a pasted message's headers in your browser: the SPF, DKIM and DMARC results the receiving server recorded, alignment with the From domain, and a Reply-To on another domain
  • Gives the next steps in order: publish SPF, publish DMARC, tighten p=none to quarantine and reject, lock down domains that send no mail

Inputs and outputs

Inputs

  • Sender domain — the domain of the From address; an address such as billing@example.com or a URL is reduced to the domain. IP addresses are refused.
  • Message headers (optional) — the full header block of one message, read in your browser only. When the domain field is empty, the From domain is checked.

Outputs

  • Summary and Why this level — the spoofing risk, the SPF ending, the DMARC policy that applies, the MX hosts, and every rule that decided the level.
  • SPF and DMARC — the records as published, where DMARC was found, the policy, subdomain policy, percentage, alignment modes and report addresses.
  • Mail servers (MX) and Other mail policies — the MX hosts by priority, and whether MTA-STS, TLS-RPT and BIMI are published.
  • What the receiving server recorded (with headers) and What to do next — the recorded SPF, DKIM and DMARC results and their alignment, and the changes to make, in order.

Email Domain Spoofing Checker example

A domain that sends no mail, locked down

Input:

example.com

Output:

Spoofing risk: Low (from the published policies alone) · SPF -all · DMARC policy reject · MX hosts: Null MX
Why this level: Null MX (RFC 7505): the domain declares that it never receives mail. · SPF "-all" and DMARC p=reject at 100%: receivers reject forged mail.
DMARC: v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s at _dmarc.example.com · Alignment (adkim / aspf) s / s · Aggregate reports (rua) —
MTA-STS: Not published · TLS-RPT: Not published · BIMI: Not published
What to do next: Add a rua= address to receive the aggregate reports that show who sends mail in its name.

How to read the Email Domain Spoofing Checker results

High means a forger can send mail that most receivers deliver as coming from the domain: no enforced DMARC policy, or SPF missing or open to everyone. Medium means forged mail is usually filtered but not always refused. Low means receivers that apply DMARC reject mail that fails alignment.

The level describes the domain's policies, not any message. Mail from a low-risk domain can still be forged where a receiver ignores DMARC, and a look-alike domain needs no access to yours at all.

p=none is a monitoring mode: it collects reports but asks receivers to do nothing, so a domain with p=none is rated high even when SPF and DKIM are perfect.

With pasted headers, "DMARC result (recorded): Fail" means the receiving server did not authenticate the message for its From domain — a strong sign of forgery when that domain publishes quarantine or reject. "None — no DMARC policy published" means there was no policy to apply, and "Check incomplete" (temperror or permerror) means the receiver could not finish the check; neither is evidence of forgery.

When to use Email Domain Spoofing Checker

  • Checking whether your own domain can be used to send phishing in your name, and what to publish to stop it.
  • Reviewing a supplier's or partner's domain before trusting e-mails from it that ask to change bank details.
  • Investigating a suspicious message: was it authenticated for its From domain, and does that domain enforce DMARC?
  • Locking down parked or retired domains that should never send mail.

Troubleshooting

  • "The resolver answered SERVFAIL for …": the domain's DNS is failing, often because of broken DNSSEC. Fix that first — receivers cannot read the policies either.
  • The level is medium although DMARC is p=reject: SPF ends in ~all or ?all, pct is below 100, sp= is weaker, or SPF is delegated with redirect=. The reasons list says which.
  • A record you just published does not show: resolvers cache DNS answers for the record's TTL. Wait for the TTL to pass and run the check again.
  • "No From address was found in the pasted headers": paste the complete header block including the From: line, or type the domain yourself.

Frequently asked questions about Email Domain Spoofing Checker

What does the spoofing risk level mean?

How easily mail can be sent in the domain's name and still be delivered as coming from it, judged from its published SPF and DMARC policies alone. Low means receivers that apply DMARC reject forged mail; high means there is no enforced DMARC policy, or SPF is missing or open to everyone. It is not a verdict on any particular message.

Our DMARC is p=none. Why is the risk high?

Because p=none only asks for reports; receivers deliver failing mail as usual. It is the right first step to see who sends in your name, but protection starts with p=quarantine and is complete with p=reject.

Does it check DKIM?

Not here: a DKIM key lives at selector._domainkey.domain and the selector cannot be discovered from DNS. Take the s= value from the DKIM-Signature header of one of your messages and use the DKIM Record Checker.

Can I check whether a specific e-mail was spoofed?

Paste its headers. The tool shows the SPF, DKIM and DMARC results the receiving server recorded and whether they align with the From domain. A recorded DMARC failure for a domain with p=reject is a strong sign of forgery; headers below your own server's can be faked, so trust the results your own mail system wrote.

Our domain sends no e-mail. Do we still need SPF and DMARC?

Yes — unused domains are popular for spoofing. Publish "v=spf1 -all", a DMARC record with p=reject, and ideally a null MX ("0 .", RFC 7505), so nobody can send or receive mail in the domain's name.

Technical notes

SPF (RFC 7208) lists the servers allowed to send for a domain in the envelope (MAIL FROM), DKIM (RFC 6376) signs messages with a key published in DNS, and DMARC (RFC 7489) ties both to the visible From domain: a message passes DMARC only when SPF or DKIM passes for a domain aligned with From, and p= tells receivers what to do with the rest — none (monitor), quarantine (spam folder) or reject.

The level follows fixed rules: no SPF, "+all", a broken SPF, no DMARC, an invalid DMARC or an effective policy of none gives high; SPF "-all" with p=reject at pct=100 and no weaker sp= gives low; everything in between — ~all or ?all, quarantine, pct below 100, a weaker subdomain policy, an SPF delegated by redirect= that this overview does not read — gives medium; a failed lookup gives unknown.

The DMARC lookup walks from the domain's own _dmarc name (_dmarc.mail.example.com) up towards the organizational domain (at most three names in this check); when the policy comes from a parent, sp= applies to the subdomain when present and p= otherwise. SPF is read statically: include: and redirect= are counted but not followed, so a "+all" or a lookup overflow behind an include shows up only in the SPF Record Checker.

The Mutqan server sends at most 8 DNS-over-HTTPS queries per check: MX, the domain's TXT records, the DMARC walk, _mta-sts (MTA-STS, RFC 8461), _smtp._tls (TLS-RPT, RFC 8460) and default._bimi. A null MX ("0 .", RFC 7505) declares that the domain receives no mail. Pasted headers are parsed in the browser, and the newest Authentication-Results header that judged each method decides the recorded result, which is shown for what it is — pass, fail, softfail, neutral, none, temperror or permerror; a header whose authserv-id is not the receiving server named in the Received headers is set aside, as RFC 8601 asks.

Limitations and methodology

Only published DNS policies are checked: DKIM keys are not (they need a selector), SPF include: and redirect= are not followed, and no message is sent or received — the level is not a test of how any particular receiver behaves.

Lookups go through public DNS-over-HTTPS resolvers from the Cloudflare edge and show what those resolvers had at that moment.

Pasted headers can be forged below your own mail server's entries. The tool reports the newest recorded results and cannot prove that a header bearing your receiver's name was really written by it.

Security and privacy

The domain is sent to the Mutqan server, which asks public DNS resolvers for its mail records; nothing is stored. Pasted headers are parsed in your browser and never sent.

References