Here’s a question that sounds easy until you try to answer it: who is sending email as your domain right now?

Your Microsoft 365 or Google Workspace tenant, sure. Probably the website contact form. But what about the invoicing system accounting signed up for last spring? The HR platform that sends offer letters? The newsletter tool marketing started “just testing” two years ago? Every one of those is sending mail with your domain in the From: line, and most of them never filed a ticket with IT.

You usually find out the hard way. Someone tightens the SPF record, or moves DMARC to p=reject, and a week later the CFO asks why customers stopped getting invoices.

This post walks through how to find every service sending email as your domain before that happens, using the records you already have plus the one data source that actually tells the truth: DMARC aggregate reports.

Why you need a sender inventory first

DMARC enforcement only works if every legitimate sender passes SPF or DKIM with alignment, meaning the authenticated domain matches the domain in the From: header. Miss one sender and enforcement will quarantine or reject its mail. DMARC doesn’t care that it was a real invoice.

This isn’t optional anymore for a lot of organizations. Google’s sender guidelines require SPF, DKIM, and DMARC for anyone sending more than 5,000 messages a day to Gmail accounts, and require the From: domain to be aligned with either the SPF or DKIM domain. Microsoft’s DMARC guidance recommends the same slow path everyone should take: start at p=none, watch the results, then move to quarantine and reject.

“Watch the results” is the sender inventory. Let’s build one.

Step 1: Read what your DNS already says

Your SPF record is a list of senders someone authorized at some point. It’s a starting point, not the truth: entries go stale, and plenty of services never get added.

dig +short TXT example.com | grep spf1

You might get something like this:

"v=spf1 include:spf.protection.outlook.com include:_spf.salesforce.com include:servers.mcsv.net include:sendgrid.net ip4:198.51.100.10 -all"

Write down each include: and ip4: entry and figure out what it is. In this example that’s Microsoft 365, Salesforce, Mailchimp, SendGrid, and one IP address nobody remembers. That last one is your first mystery to solve. (Spoiler: it’s usually an old on-prem server or a copier that scans to email.)

While you’re in there, count the DNS lookups. RFC 7208 caps SPF at 10 lookup-causing terms (include, a, mx, ptr, exists, and redirect), and going over returns a permerror. If your record is already close to the limit, you’ll have trouble adding the senders you’re about to discover. We covered fixes in Why Your SPF Record Is Breaking Email Authentication.

Next, check DKIM for the platforms you know about. You can’t list every DKIM key on a domain, because you have to know the selector name. You can check the common ones for your mail platform:

# Google Workspace (default selector is "google")
dig +short TXT google._domainkey.example.com

# Microsoft 365 (two CNAMEs)
dig +short CNAME selector1._domainkey.example.com
dig +short CNAME selector2._domainkey.example.com

If the Microsoft 365 selectors come back empty, pay attention. Microsoft signs mail from your custom domain with your onmicrosoft.com domain until you turn on DKIM for the custom domain, and that signature won’t align with your From: address for DMARC.

Step 2: Ask the business (and check the credit card)

DNS shows what IT authorized. It won’t show what someone in sales set up with a company card. Some low-tech places to look:

  • Your SSO or identity provider app list. Any SaaS app connected to Entra ID, Google, or Okta is a candidate sender.
  • Expense reports and card statements. Search for the usual suspects: CRMs, marketing platforms, helpdesks, invoicing, e-signature, scheduling, survey tools.
  • A quick email to department heads. “Does any tool you use send email to customers or employees that appears to come from @example.com?” You’ll be surprised what comes back.
  • Website and app developers. Contact forms, password resets, and order confirmations often go out through a transactional email service the dev team picked.

Put every answer in a spreadsheet. You’ll confirm all of them in the next step.

Step 3: Let DMARC aggregate reports tell you the truth

Everything so far is what people think is sending mail. DMARC aggregate (RUA) reports show what receivers like Google, Microsoft, and Yahoo actually saw arriving with your domain in the From: header, whether it passed or failed.

If you don’t have reporting turned on yet, publish a DMARC record at p=none with a rua= address:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

p=none changes nothing about delivery. It just asks receivers to send you reports. Google says its reports are usually sent once a day, so give it a few days, and ideally a couple of weeks, to catch monthly senders like billing runs.

Each report is a zipped XML file. Inside, every <record> is a sending IP with a message count and the authentication results:

<record>
  <row>
    <source_ip>203.0.113.25</source_ip>
    <count>412</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <spf>
      <domain>bounces.vendor-mailer.net</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

This one is a classic shadow sender. 412 messages claimed to be from example.com. SPF passed, but for bounces.vendor-mailer.net, the vendor’s own bounce domain, so it isn’t aligned. DKIM failed. At p=reject, all 412 of those messages would be rejected.

To figure out who owns an IP, start with reverse DNS:

dig +short -x 203.0.113.25

A PTR record like o1.ptr1234.vendor-mailer.net usually gives the vendor away. If it doesn’t, check who owns the IP block with whois and compare it against your spreadsheet from Step 2.

For a full field-by-field walkthrough of the XML, see How to Read DMARC Reports (Without Losing Your Mind).

Step 4: Sort every source into one of three buckets

Once you’ve mapped the IPs to services, every source lands in one of these buckets:

Legitimate and aligned. Passing SPF or DKIM with your domain. Nothing to do except keep it on the list.

Legitimate but not aligned. A real service you use that’s failing DMARC. This is the bucket that breaks things at enforcement. The fix is almost always to set up DKIM in the vendor’s admin panel so it signs with your domain (usually a couple of CNAME or TXT records), or to give the vendor a custom return-path/bounce domain so SPF aligns. Microsoft also recommends putting third-party bulk senders on a subdomain like marketing.example.com, so a vendor’s reputation problems don’t spill onto mail from your users.

Unknown or unauthorized. Nobody claims it. If the volume is tiny and the IPs belong to a forwarding service or mailing list, it’s probably benign forwarding. If it’s a burst of messages from IPs in a country you don’t do business in, someone may be spoofing you. Our post on detecting email impersonation attacks covers how to tell the difference.

A simple inventory sheet with these columns works fine:

Service Owner (dept/person) Sends from SPF aligned? DKIM aligned? Action
Microsoft 365 IT example.com Yes Yes None
Invoicing app Accounting example.com No No Set up DKIM in vendor portal
Newsletter tool Marketing example.com No Yes Move to news.example.com
198.51.100.10 ? example.com Yes No Find it. Probably the copier.

Step 5: Keep the list current

This isn’t a one-time project. New SaaS tools show up every quarter, vendors change their sending infrastructure, and somebody will eventually edit the SPF record and fat-finger it. The inventory only stays accurate if you keep looking at the reports.

That’s the part most of us don’t do, because opening zipped XML attachments every morning isn’t anybody’s idea of a good time. It’s also exactly why we built MonitorDMARC. It collects and parses your aggregate reports, breaks results down by sending source, IP, and country, and emails you when a new failing source shows up or your pass rate drops. That’s usually the first sign that marketing bought another tool. It also watches your SPF, DKIM, DMARC, and BIMI records and alerts you if any of them change.

Where to go from here

Once every legitimate sender is passing with alignment, you’re ready to start tightening your policy. Our guide to moving from p=none to p=reject walks through the timeline.

If you want help with the “watch the results” part, MonitorDMARC has a 14-day free trial with no credit card required. Point your rua= tag at it and you’ll have your sender list in a dashboard instead of a pile of XML. Plans start at $19.99/month for two domains with a year of report history.

References