DMARCify logoDMARCify
Use case

The shadow-IT email problem: finding every tool sending mail as your domain

Most organizations can list maybe half the SaaS tools that send email on their behalf. The other half are why DMARC enforcement breaks things. · 6 min read · by DMARCify team

Editorial illustration of a network of unfamiliar SaaS senders being discovered through a DMARC reporting pane.
Field note

The DMARC aggregate report is, accidentally, the best SaaS inventory tool you have. Every authorized sender shows up by IP and ASN, and the unfamiliar ASN is the conversation you did not know you needed.

Ask a CTO to list the email-sending SaaS tools authorized to send as their domain. You will usually get five to eight names: Google Workspace or Microsoft 365, one transactional provider, one marketing platform, maybe a CRM, and maybe a help desk.

Then turn on DMARC aggregate reporting for two weeks. The list grows.

We have seen this expansion repeatedly: "we think there are nine senders" becomes "the dashboard shows 47, of which 23 are signing correctly and 24 are unaligned." That conversation is often more useful than any policy debate about when to move to p=reject.

How shadow-IT senders happen

Three pathways account for most surprises.

Send-on-behalf-of features. A marketer signs up for a webinar tool. The tool offers to send invitations from yourname@yourcompany.com. The marketer says yes, does not realize SPF and DKIM are not configured, and mail starts failing authentication.

AI outbound assistants. The newer wave of AI SDR and AI outbound tools wants SPF authorization, DKIM CNAMEs, and often permission to send from the primary domain. Procurement frequently happens before IT sees the request.

Departmental signups. HR, finance, legal, support, success, events, and regional teams each find tools that send notifications, contracts, surveys, reminders, or receipts. Many of them can send as the company domain.

What the report shows you

A compacted DMARC aggregate record looks roughly like this:

<source_ip>23.45.67.89</source_ip>
<count>2847</count>
<auth_results>
  <dkim>
    <domain>yourcompany.com</domain>
    <selector>klav-2025</selector>
    <result>pass</result>
  </dkim>
  <spf>
    <domain>klaviyomail.com</domain>
    <result>pass</result>
  </spf>
</auth_results>

That block gives you the source IP, the sending volume, the DKIM selector, and the SPF identity. Across Google, Microsoft, Yahoo, and the long tail of receivers, a few weeks of reporting builds a practical inventory of every IP and provider touching your domain.

A useful dashboard groups by ASN and organization name. The known ASNs are boring. The unknown ASN is where attention goes.

The four buckets

During onboarding, every observed sender usually lands in one of four buckets within the first month.

Sender triage buckets
  • Known and aligned: authorized, signing correctly, no work needed.
  • Known and unaligned: authorized by somebody, but SPF or DKIM alignment is missing.
  • Unknown: real volume from a plausible provider, but no owner on the security side.
  • Suspicious: low volume, weak infrastructure, no DKIM, and no business owner.

The Unknown bucket deserves discipline. About half the time it is a legitimate procurement nobody documented. About half the time it is a trial, abandoned integration, or old campaign system that should be disconnected.

The p=reject blocker

The most common reason a domain stays at p=none is not technical complexity. It is uncertainty. Security does not want to enforce DMARC because the Unknown bucket is too large, and some of those senders may be legitimate.

The way through is to do the inventory exercise. Every Unknown sender gets one of two outcomes:

  • Authorization. Add the sender to SPF where appropriate, configure DKIM, and move it into the Known bucket.
  • De-authorization. Shut down the procurement, retire the tool, disconnect the integration, or block it from sending as the domain.

After two weeks of that work, the Unknown bucket is usually small enough that policy can move. The inventory was the unblocker. The policy promotion is the easy part.

Where the dashboard helps

In DMARCify, the Senders view groups by ASN, DKIM selector, and From-domain alignment. Each sender can be tagged as Authorized, Investigate, Block, or Forwarder. Marking a sender as Investigate creates a short brief: ASN owner, likely SaaS association, volume trend, and alignment status.

For a domain in the first eight weeks, this view carries much of the value. The reporting is the inventory.

The boring punchline

The Unknown bucket is mostly mundane: procurements nobody documented, trials that auto-renewed, and a 2019 marketing tool still emailing 12 people a year. The adversarial slice is smaller, but it is the one enforcement is meant to stop.

DMARC, decoded.

The dashboard surfaces the things this post talks about — alignment, forwarders, source attribution — for every domain you monitor.

One DNS record · 60 seconds to set up