Email OSINT & Domain Spoofing Analyzer
SPF, DMARC, and DKIM analysis with RBL checking and a spoofing simulator.
The Email Security Auditor evaluates the full email security posture of any domain. It analyzes SPF and DMARC policies, retrieves DKIM keys for specified selectors, checks the domain against multiple real-time blocklists, queries MX record data, and runs a spoofing simulator to show what an attack looks like in practice.
Email Security (DMARC & SPF)
How to Use
Work through these steps in order. Use this tool for educational and ethical purposes only.
| 1 | Select Email Security Auditor from the tool navigation. |
| 2 | Enter the target domain name (e.g., example.com). |
| 3 | Click Audit Email Security. The tool runs all checks in sequence. |
| 4 | Review the SPF Analysis panel: the policy mechanism, lookup count, and final qualifier (-all is recommended). |
| 5 | Check the DMARC Analysis panel: enforcement policy (none, quarantine, or reject), pct= value, and reporting addresses. |
| 6 | Enter a known DKIM selector (e.g., google, default, selector1) to retrieve and analyze the public key. |
| 7 | Review the DKIM Key Analysis for key length (2048-bit minimum) and hash algorithm. |
| 8 | Check the RBL Results panel. A green status means the domain and its sending IPs are not listed on Spamhaus, SORBS, or Barracuda. Review the Spoofing Simulator to see what a spoofed message from this domain would look like to a recipient. |
How Email Authentication Actually Works
Email authentication runs on three layers. Each does a different job, and they only work well together.
SPF (Sender Policy Framework)
SPF is a DNS TXT record listing which mail servers are authorized to send email for a domain. When a receiving server gets a message, it checks whether the sending server’s IP is on that list.
The key is the qualifier at the end of the record. ~all means SoftFail: unapproved senders are flagged but not rejected. -all means HardFail: unapproved senders are rejected outright. Most domains use ~all, which the tool correctly labels Weak (SoftFail) since it offers monitoring without enforcement.
DKIM (DomainKeys Identified Mail)
DKIM adds a cryptographic signature to outgoing emails. The receiving server checks this against a public key in the sender’s DNS. A valid signature confirms the message wasn’t tampered with in transit. This tool focuses on DMARC and SPF, but DMARC alignment with DKIM is part of the full chain.
DMARC (Domain-based Message Authentication, Reporting & Conformance)
DMARC is the enforcement layer. It tells receiving servers what to do when SPF or DKIM checks fail.
Policy | Effect |
|---|---|
p=none | Monitoring only. No action. Spoofed emails are delivered. |
p=quarantine | Suspicious emails go to spam. |
p=reject | Spoofed emails are rejected outright. |
The key point: a domain can have both DMARC and SPF and still be fully spoofable if the policy is p=none. The spoofing simulator makes this concrete; a domain with p=none shows the simulated phishing email as DELIVERED.
How the Layers Interact
SPF checks the sending server. DKIM checks message integrity. DMARC checks whether SPF and/or DKIM pass and align with the From: header, then applies the policy. All three need correct configuration for email authentication to mean anything.
Real-World Attacks Enabled by Weak Authentication
Weak DMARC and SPF are not theoretical risks. They directly enable two of the most costly email attacks in use today.
Business Email Compromise (BEC)
BEC is a social engineering attack where the attacker sends email appearing to come from a trusted executive or vendor, typically to request a wire transfer, steal credentials, or exfiltrate data.
The FBI’s IC3 consistently ranks BEC as the highest-loss cybercrime category globally, with losses running into billions annually.
The technical mechanism is simple: if a domain has p=none, an attacker can send from ceo@targetdomain.com and it lands in the inbox with no warnings. The spoofing simulator replicates exactly this scenario. If the result shows DELIVERED, that attack works against that domain right now.
Brand Impersonation
Brand impersonation targets a domain’s customers, partners, or employees rather than the domain owner directly. Attackers either register lookalike domains or, when authentication is weak, spoof the legitimate domain outright.
Common cases include fake invoices from SaaS vendors, phishing emails appearing to come from banks, and supplier fraud where attackers impersonate a known vendor to redirect payments.
With p=none, the brand has zero technical control over who sends email claiming to be from its domain. Recipients have no way to tell those spoofed emails from real ones.
The SoftFail Problem
Many administrators assume that an SPF record with ~all provides meaningful protection. It does not. SoftFail tells receiving servers to accept the email but note the failure. In practice, most providers still deliver these to the inbox. Combined with p=none DMARC, a SoftFail SPF record offers close to zero spoofing protection.
How to Secure Your Email Domain
Hardening email authentication is a staged process. Jumping straight to p=reject without understanding your mail flows first can break legitimate delivery. Follow these steps in order.
Step 1: Publish an SPF Record
If no SPF record exists, create one:
v=spf1 include:_spf.yourmailprovider.com ~all
List every service authorized to send mail on your behalf: Google Workspace, Mailchimp, Salesforce, and so on. Use -all (HardFail) once the record is complete and tested.
Step 2: Enable DKIM Signing
Generate a DKIM key pair in your email provider and publish the public key as a DNS TXT record at selector._domainkey.yourdomain.com. If you use multiple sending services, each needs its own DKIM selector and key.
Step 3: Start DMARC in Monitoring Mode
Deploy DMARC with p=none first to collect data without affecting delivery:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensics@yourdomain.com; pct=100
The rua tag sends aggregate reports (daily XML with pass/fail counts). The ruf tag sends forensic reports on individual failures. Route these to a dedicated mailbox or DMARC reporting service.
Step 4: Analyze DMARC Reports
After two to four weeks, review aggregate reports and look for legitimate sources failing SPF or DKIM alignment, unauthorized senders using your domain, and missing DKIM configs on third-party services. Fix every legitimate source before moving to enforcement.
Step 5: Move to Quarantine
Once reports show clean alignment, update to p=quarantine:
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com
Start at pct=25 and monitor for false positives, increasing gradually to 100 over two to four weeks.
Step 6: Enforce Rejection
When p=quarantine; pct=100 runs cleanly, move to full enforcement:
v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@yourdomain.com
At this point the tool will show your domain’s spoofing simulation as BLOCKED.
Step 7: Monitor Continuously
Email infrastructure changes. New tools get added, providers update sending IPs, teams configure automations without telling IT. Re-run this tool monthly, review DMARC reports weekly, and audit your SPF record whenever you onboard a new SaaS product.
Technical Details and Use Cases
Email authentication depends on three standards working in coordination. SPF authorizes which servers can send for a domain. DKIM signs messages cryptographically. DMARC sets the enforcement policy and reporting behavior. A domain is fully protected only when all three are correctly configured and aligned.
SPF lookup count is checked against the RFC 7208 limit of 10 DNS mechanisms. Exceeding this causes an SPF PermError, which breaks delivery and disables enforcement. The tool counts include, a, mx, and ptr mechanisms to catch over-limit configurations before they cause problems.
DKIM key retrieval queries the TXT record at selector._domainkey.domain and parses the p= field to extract the RSA public key. Key length is calculated and flagged if it falls below 2048 bits, which NIST considers the minimum for current use.
The spoofing simulator generates a sample email header showing how From: spoofing, reply-to manipulation, and the resulting DMARC disposition would appear. This makes the risk concrete for non-technical stakeholders who need to understand why p=none is not an acceptable long-term policy.
Typical use cases: email deliverability troubleshooting, phishing investigation, business email compromise (BEC) risk assessment, and compliance auditing.
Pros & Cons
| Pros | Cons |
| ✓ Spoofing simulator makes DMARC misconfiguration risk concrete for non-technical audiences | ✗ DKIM lookup requires the selector name, which is not standardized and must be known in advance |
| ✓ Multi-RBL check covers Spamhaus, SORBS, and Barracuda in one lookup | ✗ RBL results reflect the listing state at query time; delisting propagation takes additional time |
| ✓ DKIM key length analysis flags signing keys that fall below current security standards | ✗ The spoofing simulator is for demonstration only and does not send any actual email |
Related Web Security & Privacy Modules
Frequently Asked Questions
What does "Partially Protected" mean?
It means the domain has DMARC and SPF in DNS, but the DMARC policy is p=none or the SPF qualifier is ~all (SoftFail). Neither setting actively blocks spoofed email. You need p=reject to stop domain spoofing.
Can a domain with DMARC still be spoofed?
Yes. A domain with DMARC can be spoofed if the policy is p=none. Only p=reject instructs receiving servers to block unauthenticated messages. Many domains stay in monitoring mode indefinitely and never move to enforcement, leaving them fully exposed despite technically having a DMARC record.
What is the difference between SPF SoftFail (~all) and HardFail (-all)?
~all marks emails from unauthorized senders as suspicious but still allows delivery. -all instructs receiving servers to reject them outright. In practice, SoftFail alone is weak because DMARC policy controls what actually happens to failing messages. If DMARC is p=none, even a HardFail SPF record has minimal protective effect.
Why is my mail server's IP on a blacklist?
A mail server IP gets blacklisted for sending spam, hosting malware, botnet activity, or reported abuse. Shared hosting is particularly prone to this since one tenant’s bad behavior affects all IP neighbors. A listed IP causes legitimate email to be filtered or rejected. If the tool flags your IP as LISTED, contact your mail provider and submit a delisting request to the relevant blacklist operators.
How often should I audit my domain's email security?
At minimum, once per month. Run an immediate audit whenever you add a new sending service, change mail providers, update DNS records, or receive reports of spoofed email from your domain. Configurations drift over time as services get added without updating SPF, DKIM keys expire, or policies get accidentally changed during DNS migrations.
Recosint Intelligence Suite
For Business Inquiries, Sponsorship's & Partnerships
(Response Within 24 hours)
