How do I monitor for domain spoofing attempts against our brand?

The proactive monitoring you're seeking can be significantly enhanced by moving beyond your own logs and reports. While DMARC aggregate reports are useful, they only show you results from receivers that actually send reports, which isn't universal. Your aim should be to discover spoofing attempts *before* they hit inboxes.

One method is to monitor the global DNS system for new MX records or A records that could indicate infrastructure being set up to impersonate your domain. You can script DNS queries for permutations of your brand name across common TLDs and look for sudden resolutions. you could subscribe to commercial threat intelligence feeds that track phishing infrastructure; many have APIs that can be integrated into a monitoring dashboard.

Your parsed DMARC reports are also a source for proactive signals. Look for mail sources you don't recognize in the `` and `` elements of the XML, even if they passed authentication. A sudden spike in volume from an unknown provider, especially one in a geographic region you don't operate in, can be an early indicator of a campaign being tested against providers with lax policies.

That feeling of wanting a proactive alert is exactly the problem. I've been looking at this for my own documentation. The parsed DMARC reports still feel like reading yesterday's news, even if they're helpful.

You could set up a canary email address. Create an alias at your domain that you never publish or use legitimately, then monitor it for any incoming delivery attempts. If something hits that inbox, it's a strong signal someone is spraying emails from your domain without following proper DKIM/SPF. It's a simple trick but acts as a tripwire.

I like the canary email idea. It's a clever tripwire. Maybe you could feed those alerts into a separate monitoring system, like a Slack channel or a ticketing queue, so you don't miss it in the main inbox noise.

For a more programmatic check, could you script something to regularly query your domain's DMARC report URI? I'm wondering if you could compare the `source_ip` in incoming reports against your known infrastructure IPs to flag unknown ones automatically. Might be too noisy though?

That DNS monitoring script idea makes sense. Do you know if there are any existing open-source tools or Terraform modules that can set up something like that? I've seen some GitHub repos for monitoring DNS changes, but I'm not sure which one fits.

> commercial threat intelligence feeds that track phishing infrastructure
This is a good point. Are there any specific feeds you'd recommend for a smaller setup? I'm worried about costs.

For the DNS monitoring script, I've had success with `dnstwist`. It's a Python tool that generates permutations of your domain and checks for their registration or resolution. You can wrap it in a simple cron job or a GitHub Actions workflow to run daily and alert on new hits.

On threat feeds, many commercial ones are pricey. However, the OpenPhish feed is available for non-commercial use and can be pulled via its public API. It's not exhaustive, but it's a solid starting point that you can pipe into a monitoring dashboard without cost.

Totally get that feeling of wanting to be more proactive than reactive. The canary email and DNS monitoring ideas sound great for early warnings.

I'm curious about the parsing side, though. You mentioned using an open-source tool for the DMARC aggregate reports. Are you storing those parsed results anywhere, like a database? If you are, you could set up a basic Airflow DAG to run daily checks that compare the reporting source IPs against a list of your approved mail servers and flag new ones. That might catch some spoofing attempts before the reports feel like old news.

On a smaller scale, have you considered setting up a simple script to monitor the submission volume to that dmarc-reports address? A sudden drop in reports could also be a weird signal worth checking, maybe indicating someone is trying to interfere with the reporting.

Storing parsed DMARC reports in a database is the right idea, but an Airflow DAG feels like overkill for a daily lookup. It's a simple `LEFT JOIN` between your known IP table and the day's new report source IPs.

Just run a scheduled SQL query in your warehouse. The sudden drop in report volume is more interesting, but good luck setting a threshold that isn't triggered by Gmail changing its reporting schedule again.

You're right, that reactive feeling is tough to shake even with all the right protocols in place. I've been trying to do something similar.

The canary email idea from earlier in the thread sounds like it would fit right into your existing setup. Since you already control the DNS and mail server, creating that unused alias to act as a tripwire would be pretty straightforward. You could pipe any hits into a separate alert channel.

I'm also curious, have you seen any spoofing attempts yet in your parsed DMARC reports? Wondering if the volume makes that SQL query approach manageable or if it gets noisy fast.

user56 already mentioned dnstwist, and it's a solid choice for a scriptable tool. For a more "monitoring platform" approach, you could look at domainsquattingdetector, though it's a bit more opinionated in how it runs.

On the threat feeds, OpenPhish is good for the price (free). For a small setup, the PhishTank feed is another option you can integrate. The data is crowdsourced, so it has gaps, but it can catch widespread campaigns and the API is straightforward. Just be prepared to filter out some false positives.

That's a good shout about PhishTank. I've been looking at their API docs and the JSON structure seems simple enough to pull into a small Python script. Have you found their data to be timely? I'm worried about a lag if it's all volunteer-verified.

Also, when you say domainsquattingdetector is "opinionated," do you mean it forces you into a specific workflow or logging setup? I'm trying to avoid getting locked into a big monitoring platform right now.

Airflow for a daily lookup is the definition of bringing a cruise ship to a pond race. I'm with you there.

But that SQL query's simplicity is its own trap. The real mess isn't the join, it's curating that 'known IP table'. ESPs rotate IPs, new marketing tools spin up, and your cloud provider's outbound pool changes. That table becomes a full time job of chasing whitelist exceptions, which is exactly the kind of ops drudgery everyone wants to automate away in the first place.

And on the volume drop, you nailed it. Google and Microsoft decide to batch reports differently one week and your alerting goes haywire. Trying to set a static threshold for external systems you don't control is a fool's errand. Maybe you need a rolling baseline, but then you're right back to needing something more complicated than a simple scheduled query.

Oh man, you're so right about the whitelist table. I built one for our DMARC project last year and it was a nightmare. We had our main ESP, a secondary one for some campaigns, and then analytics tools. Every time we'd get a new alert, it was a frantic search to figure out if it was a legit new service someone in Marketing spun up without telling us.

That's the hidden cost nobody talks about. You think you're setting up a simple filter, but you're actually signing up to manually maintain the inventory of every single service that can send email for your company. It's exhausting.

The rolling baseline idea is smart, but then you're not really doing domain monitoring anymore. You're building a full-blown anomaly detection system. Which might be what you need, but it's a whole different project scope.

You're spot on about the reactive feeling, even with all the right protocols in place. You mentioned wanting to know the moment someone spoofs you, but the existing tools are designed for after-the-fact reporting.

Since you control DNS, I'd suggest creating a few "canary" subdomains specifically for monitoring, like `tracking.example.com` or `billing-secure.example.com`. You'd never use them legitimately. Set up a DMARC `rua` tag pointing to your report address for those subdomains specifically. Any DMARC report you receive for them is, by definition, a spoofing attempt, and it gives you a much cleaner signal than sifting through noise on your primary domain. It's a small addition that leverages your existing report parsing setup for a more proactive alert.

Love the canary inbox idea! It's such a low-effort, high-signal tripwire. I've done something similar before, but I piped the alerts into a Slack channel we barely check. Made it useless.

One heads-up: you'll want to make absolutely sure that alias isn't caught by any internal mail forwarding rules or added to an email list by mistake. I once had a "secret" monitoring address start getting internal newsletters and it ruined the whole point.

The real trick is making that alert trigger something you can't ignore.