Is Your Domain Being Spoofed? Here's How to Find Out

The frustrating answer is: probably yes, and you don't know about it.

If your domain has a p=none DMARC policy, or no DMARC record at all, anyone can send email that appears to come from your domain. Receiving mail servers accept it, it lands in inboxes, and you have no visibility unless someone tells you or you're reading aggregate reports you almost certainly aren't reading.

Here's how to check, what you're looking for, and what to do about it.

How domain spoofing actually works

A spoofed email doesn't come from your mail server. It comes from a server the attacker controls, with the from: header set to you@yourdomain.com. SMTP doesn't verify this by default, the from: header is just a string.

What stops it: DMARC policy enforcement. If your DMARC is at p=reject, receiving servers check whether the email was sent from an authorized source. If not, they reject it. If your DMARC is at p=none, they still check but accept the email anyway and just send you a report. If you have no DMARC, they accept it and send nothing.

Most indie developers are in one of these situations:

• No DMARC record: completely blind, spoofing is undetected
• p=none with no monitoring: reports are being generated but going unread
• p=none with monitoring: you can see if it's happening, but haven't stopped it yet

Step 1: Check whether you have a DMARC record

Use the DMARC record checker. Enter your domain. Either you have a DMARC record or you don't.

No DMARC record: You're completely invisible to spoofing activity. Mail servers that receive spoofed email from your domain have no way to tell you about it. Publish a p=none record with a monitoring address first, then you can see what's happening.

p=none: You're collecting reports (if your rua= address is set and something is processing them). Check whether you're actually reading them.

p=quarantine or p=reject: Your domain is reasonably protected. Spoofed emails will be quarantined or rejected. You can still see if attempts are being made.

Step 2: Read your aggregate reports

DMARC aggregate reports are XML files that receiving mail servers send to your rua= address. They contain every email that claimed to be from your domain: source IP, whether it passed or failed authentication, and the volume.

What you're looking for: IP addresses you don't recognize, sending email from your domain, failing authentication. These are spoofing attempts.

The problem: the reports are gzipped XML. They look like this:

<record>
  <row>
    <source_ip>185.220.101.47</source_ip>
    <count>143</count>
    <policy_evaluated>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
</record>

An IP you don't own, 143 messages, both authentication checks failing. That's spoofing. You'll miss it if you're not parsing the reports.

Use the DMARC analyzer to upload a report and see it in readable form, or use a monitoring tool that processes reports automatically.

Step 3: Identify suspicious sources

In your aggregate reports or monitoring dashboard, look for:

• IPs not in your sending infrastructure: you know what services send email for you (your ESP, your product, maybe a CRM). Everything else is suspicious.
• Sources with high failure rates: 100% DMARC fail from a source you don't recognize is a strong signal.
• Geographic anomalies: IP blocks from regions you don't operate in.
• Volume spikes: a sudden jump in report volume, especially failing traffic.

A single IP sending 2 or 3 test emails that both fail is often a misconfigured server or spam probe. Sustained volume from unfamiliar IPs is likely active spoofing.

Step 4: Tell real spoofing apart from your own broken senders

This is where most people get it wrong, and where moving too fast does real damage. Not every DMARC failure is an attacker. The single most common cause of failures in a new DMARC deployment is a legitimate service you set up months ago and forgot to authenticate. Before you treat a source as hostile, read the signals in the report and classify it.

The aggregate report gives you four things per source: the source_ip, the count, the raw SPF and DKIM auth results, and the DMARC-evaluated result after alignment. The combination of those tells you which bucket a source belongs in.

Bucket 1: Failed SPF and failed DKIM from an IP you don't recognize. Both mechanisms produce no valid signature and no authorized envelope. The sending IP belongs to a network you have no relationship with, often a residential block, a bulletproof host, or a Tor exit. This is the classic spoofing fingerprint. An attacker can't produce a valid DKIM signature for your domain, because they don't have your private key, and they can't pass SPF, because they're not sending from your authorized IP ranges. When you see sustained volume here, treat it as spoofing.

Bucket 2: Failed alignment from a real ESP you forgot to authenticate. This is the trap. The report shows the message passed SPF or passed DKIM on its own, but DMARC still records a failure because the authenticated domain doesn't align with the From: domain. A transactional provider sends on your behalf, signs with its own domain (d=sendgrid.net), and passes its own SPF, but you never added the provider's SPF include or set up a custom signing domain. The auth mechanisms pass, alignment fails, DMARC fails. The IP belongs to a known provider, the volume tracks your actual sending, and the failures are consistent rather than bursty. This is not an attacker. It's your own legitimate mail, broken.

Here's the practical tell. Look at whether SPF or DKIM passed at the mechanism level even when the DMARC result is fail:

<record>
  <row>
    <source_ip>198.61.254.20</source_ip>
    <count>89</count>
    <policy_evaluated>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <auth_results>
    <spf>
      <domain>sendgrid.net</domain>
      <result>pass</result>
    </spf>
    <dkim>
      <domain>sendgrid.net</domain>
      <result>pass</result>
    </dkim>
  </auth_results>
</record>

SPF and DKIM both pass in auth_results, but they authenticate sendgrid.net, not your domain, so policy_evaluated records a DMARC fail on alignment. A real attacker's record shows failures all the way down, with no passing mechanism for any domain. A forgotten-but-legitimate sender shows a passing mechanism for a recognizable provider domain. Reverse-DNS the IP and check it against the provider's published ranges to confirm.

Bucket 3: A forwarder. Mailing lists and forwarding services break SPF (the forwarding hop isn't in your SPF record) but often preserve DKIM. You'll see SPF fail, DKIM pass and align, DMARC pass. These are usually fine and are exactly why you authenticate with DKIM, not SPF alone, before enforcement.

The rule: a passing, recognizable mechanism means investigate before you block. Failures all the way down from an unfamiliar network means spoofing. Get this classification right and the rest of remediation is safe. Get it wrong and you either block your own invoices or wave through an attacker.

Step 5: Authenticate every legitimate sender first

Once you've separated the real spoofing from your own misconfigured senders, do not jump straight to a strict policy. If you tighten enforcement while legitimate sources are failing alignment, receiving servers will quarantine or reject your own mail. Password resets stop arriving. Invoices land in spam. The fix is to authenticate everything legitimate first, then tighten.

Build a complete inventory of every service that sends as your domain. Your aggregate reports are the source of truth here, because they show you senders you forgot about. Typical list for an indie product:

• Your transactional ESP (Resend, Postmark, SendGrid, SES)
• Your marketing or newsletter platform
• Your support desk or CRM
• Google Workspace or Microsoft 365 for human mail
• Anything that sends from your app server directly

For each one, set up alignment. There are two paths and you want both where you can:

SPF alignment. Add the provider's include: to your SPF record so their sending IPs are authorized under your domain. A combined record looks like v=spf1 include:_spf.google.com include:sendgrid.net include:amazonses.com -all. Watch the 10-DNS-lookup limit. SPF caps the number of nested lookups, and chaining several providers blows past it, which silently breaks SPF entirely. If you're near the limit, flatten or drop the providers you no longer use.

DKIM alignment. Have each provider sign with a key on a subdomain of your domain rather than theirs, so the signing domain aligns with your From:. Every serious ESP gives you CNAME records to publish (for example s1._domainkey.yourdomain.com) that point at their key infrastructure. Publish them, verify the provider reports the key as active, and confirm in your next aggregate reports that the source now passes DMARC.

DKIM alignment is the more durable of the two, because it survives forwarding and isn't subject to SPF's lookup limit. Aim to have DKIM aligned for every important sender, with SPF as a backstop.

Then watch your reports until legitimate mail is clean. The target before you move the policy up: at least 95% of your legitimate volume passing DMARC. The remaining few percent will mostly be forwarders and one-off oddities you can account for.

Step 6: Tighten the policy from none to quarantine to reject

Only after legitimate senders pass do you raise enforcement. Do it in stages so you can catch any sender you missed before it causes real damage.

1. Confirm p=none is clean. Your reports should show known sources passing and only the unfamiliar, all-failing sources failing. That residual failing volume is your spoofing, and it's exactly what enforcement will start blocking.
2. Move to p=quarantine. Set p=quarantine so spoofed mail goes to spam folders rather than the inbox. Older guides suggest easing in with the pct tag, but RFC 9989 removed pct= from DMARC, so treat the move as all-or-nothing and lean on close report-watching instead. Watch reports the entire time.
3. Watch for at least one full reporting cycle. Give it a week minimum. Aggregate reports arrive daily from most providers, so a week shows you weekday and weekend traffic, batch jobs, and any monthly or weekly automated sender. If a legitimate source surfaces failing, fix its alignment before going further.
4. Move to p=reject. This is the goal state. Spoofed mail is now refused at the receiving server and never reaches the inbox. The policy now applies to all failing mail.

A final, complete record at enforcement looks like:

v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com; fo=1; adkim=s; aspf=s

adkim=s and aspf=s request strict alignment; relax to r only if a legitimate subdomain sender needs it. See /blog/p-reject-vs-quarantine for the full enforcement guide and the trade-offs between the two policies.

Step 7: Keep monitoring after you reach reject

Reaching p=reject is not the finish line. Your sending infrastructure changes: you add a new ESP, a teammate spins up a new tool, a provider rotates its keys. Any of those can start failing DMARC, and at p=reject a failing legitimate sender means that mail is rejected, not just reported. Monitoring is what turns that from a silent outage into an alert.

Keep your rua= reporting on permanently and keep something processing the reports. What you're watching for after enforcement:

• New sending sources appearing. A source you've never seen passing DMARC is either a new legitimate tool to authenticate or a new spoofing attempt. Either way you want to know the day it shows up.
• An existing source starting to fail. Usually a key rotation, an expired DKIM record, or an SPF change that pushed you over the lookup limit.
• Volume changes that suggest a spoofing campaign ramping up against your brand.

This is exactly the continuous watch that's tedious to do by hand and easy to automate. DMARCdrift processes your reports daily and alerts you when a new unauthorized source appears or a known good source starts failing, so enforcement stays safe instead of silently breaking your mail.

Step 8: Consider BIMI once you're at enforcement

Once your domain is at p=quarantine or p=reject, you've unlocked BIMI (Brand Indicators for Message Identification). BIMI lets you publish your logo so it displays next to your authenticated mail in supporting inboxes like Gmail, Apple Mail, and Yahoo. It's both a brand signal and a trust signal: recipients learn to expect your logo, which makes a spoof that lacks it more obviously suspect.

BIMI requires DMARC at enforcement first (p=quarantine or p=reject, with most providers wanting full coverage across all your mail). It also typically requires a Verified Mark Certificate (VMC) from a certificate authority, which involves a trademark check on your logo, so it's a paid, multi-week process rather than a DNS quick win. Treat it as the reward for finishing the authentication work, not a step you do early.

What spoofing protection can and cannot do

Set your expectations correctly, because DMARC is powerful but narrow. It stops one specific, very common attack and does nothing about several others. Knowing the boundary keeps you from a false sense of security.

What p=reject stops: exact-domain spoofing. Mail with From: you@yourdomain.com sent from anywhere you haven't authorized is refused. This is the bulk of phishing that impersonates a domain, and it's the attack DMARC was built for. Shutting it down is a real, measurable win.

What DMARC does not stop:

• Lookalike and cousin domains. An attacker registers yourdomaln.com (an L swapped for an i) or yourdomain-support.com and sends from that. It's a domain they control, so they can pass DMARC on it. Your DMARC record protects your exact domain and nothing else. Defenses here are different: monitor for newly registered lookalikes, register the obvious typos yourself, and educate users.
• Display-name spoofing. The visible name says "Your Company Support" but the actual address is attacker@gmail.com. DMARC authenticates the domain in the address, and gmail.com passes its own DMARC perfectly. The mail is technically authentic, just deceptively labeled. Inbox anti-phishing heuristics catch some of this; DMARC structurally cannot.
• Compromised accounts. If an attacker steals real credentials and sends through your actual authorized infrastructure, the mail passes DMARC because it is legitimately authenticated. That's an account-security problem (MFA, credential hygiene), not an authentication problem.

The honest summary: DMARC at p=reject eliminates the single largest category of domain-impersonation phishing. It is necessary and it is not sufficient. Pair it with lookalike-domain monitoring and account security for fuller coverage.

When to escalate beyond your own DNS

Most spoofing is handled entirely by tightening your own policy. Receiving servers do the enforcement for you once you tell them to reject. But some situations warrant going further and reporting the activity.

• A sustained, targeted campaign. If your reports show a high-volume spoofing run aimed at your customers, report it to the mailbox providers receiving it. Google, Microsoft, and Yahoo all run abuse-reporting channels, and your aggregate reports give you the source IPs and timestamps to include.
• A specific abusive source IP or host. Look up the IP's network owner (a WHOIS or RDAP lookup gives you the responsible provider) and send an abuse report to that provider's published abuse contact, typically abuse@theirhost.com. Attach the relevant report excerpts.
• A lookalike domain actively phishing your users. This is a registrar and hosting matter, not a DMARC one. File an abuse complaint with the registrar of the lookalike domain and the host serving any phishing page. If a trademark is involved, your legal team or a brand-protection service can pursue takedown.
• Confirmed customer harm. If real recipients have lost money or credentials, escalate to law enforcement (in the US, the FBI's IC3) and warn your customers directly so they stop trusting the spoofed mail.

Keep the evidence. Your aggregate reports, with source IPs, volumes, and timestamps, are the documentation every one of these channels will ask for, which is one more reason to retain and monitor them continuously.

Can you tell who specifically was spoofed?

Sometimes. DMARC forensic reports (RUF) include individual message samples: headers, recipients, delivery status for specific failed messages. Not all receiving servers send RUF (Gmail stopped in 2023 citing privacy), but others do.

If someone tells you they received a spoofed email from your domain, and you have forensic reports enabled, you can often correlate the timestamp and approximate source IP. See /blog/dmarc-failure-report-ruf for more on RUF vs RUA.

What's next

The only way to stay on top of this is ongoing aggregate report monitoring. DMARCdrift processes your reports and alerts you when new unauthorized sources appear sending from your domain. Free for one domain.

Get started free