Domain Spoofing Checker

How domain spoofing works

Email spoofing happens when an attacker sends a message that appears to come from your domain. The visible From address may show your CEO, finance team, HR team, support mailbox, or invoice address, even though the message was not sent by your infrastructure. SPF, DKIM, and DMARC work together to reduce this risk, but DMARC enforcement is the key control that tells receivers to quarantine or reject unauthenticated mail.

This checker does not send spoofed email and does not provide SMTP commands. It safely reads public DNS records and public policy files. The verdict is based mainly on the effective DMARC policy after tree walk discovery. If no enforcing DMARC policy applies, the domain is considered spoofable. If quarantine applies, the domain is partially protected. If reject applies, the domain is protected by policy, with the important caveat that inbox behavior can still depend on receiver policy and forwarded mail flows.

Subdomains matter. Attackers often use names such as payroll.example.com, secure.example.com, verification.example.com, or a non-existent subdomain that looks believable. Current DMARC logic uses p, sp, and np to decide which policy applies to the exact domain, existing subdomains, and non-existent subdomains. This scanner evaluates that fallback chain so it does not falsely mark a domain as safe when subdomain policy is open.

A good anti-spoofing posture normally includes SPF for sender authorization, DKIM for cryptographic signing, DMARC p=reject for enforcement, np=reject for non-existent subdomains, TLS-RPT for mail transport reporting, and MTA-STS where suitable. Automated checks are useful, but a manual assessment is still valuable because it confirms real sending sources, alignment, third-party services, forwarding behavior, and report data.

Signs your domain may be spoofable

• No DMARC record exists at the domain or inherited parent policy.
• DMARC exists but uses p=none.
• DMARC is in testing mode and the effective policy is downgraded.
• Subdomain or non-existent subdomain policy falls back to none.
• SPF uses +all or multiple SPF records.
• DKIM selectors are missing, weak, or not aligned with the From domain.

How to reduce domain spoofing risk

Domain spoofing risk is mainly controlled by DMARC enforcement. SPF and DKIM provide authentication signals, but DMARC tells receivers what to do when mail using your visible From domain does not authenticate and align. A domain with SPF and DKIM but no enforcing DMARC policy can still be abused in many spoofing scenarios. This scanner therefore places the spoofability verdict at the top instead of hiding it inside raw DNS output.

Subdomains matter. Attackers often use lookalike or non-existent subdomains because employees and customers may not notice the difference between billing.example.com and secure.billing.example.com. Modern DMARC has an np policy for non-existent subdomains. If the domain has strong main-domain enforcement but weak non-existent subdomain policy, the scanner marks this as a remaining spoofing gap.

A scanner cannot prove inbox placement. Mailbox providers apply reputation, forwarding exceptions, local policy, ARC, spam filtering, and user-specific rules. The correct interpretation is that an enforcing DMARC policy reduces direct spoofing risk at receivers that honor DMARC. For high-value domains, VAPT Experts recommends manual validation using controlled test flows, report review, and business sender inventory.

Business risks of email spoofing

Domain spoofing is not only a technical problem. It can lead to invoice fraud, executive impersonation, fake password reset messages, vendor payment changes, recruitment scams, and customer trust damage. A single convincing email that appears to come from a trusted domain can bypass normal suspicion, especially when the message references real staff names, ongoing projects, or urgent finance activity.

The most useful control is a clear domain inventory. Know which services send mail for your domain, confirm whether they sign with DKIM, check whether their Return-Path or DKIM domain aligns with the visible From domain, and then move DMARC from monitoring to enforcement. This scanner helps by showing the public policy state, but report review and sender inventory are still required before changing a high-value production domain to reject.

For businesses with many subdomains, review both existing and non-existent subdomain policy. Attackers often register no infrastructure at all. They simply place a believable non-existent subdomain in the From address and rely on weak inherited policy. A strong setup normally uses p=reject, appropriate sp policy, and np=reject when rollout testing confirms legitimate mail is aligned.