Who is sending mail as us? The Shadow IT Sender Inventory Problem
The biggest practical blocker to moving beyond p=none isn’t DNS syntax. It’s discovering every legitimate sender. DMARC reports expose these “unknown senders” and Shadow IT that you didn't even know existed.
You’ve published your DMARC record with p=none. You are feeling good. You are collecting data.
Then you open your first aggregate report (or look at your DMARCTrust dashboard), and the panic sets in.
"Who is 192.0.2.55? Why is 'unknown.super-marketing-tool.com' sending 5,000 emails as us? Did we get hacked?"
Relax. You probably weren't hacked. You’ve just discovered Shadow IT.
1. The DMARC Rollout Trap: You Can’t Enforce What You Haven’t Inventoried
The most dangerous thing you can do is switch to p=reject because you "think" you know all your mail servers. You don't.
In every company I’ve helped, there is always something forgotten:
- The HR platform sending offer letters.
- The invoicing tool finance signed up for last week.
- A random WordPress plugin on a forgotten marketing microsite.
- That one developer testing script running on a DigitalOcean droplet.
If you enforce DMARC before finding these, you break them. This is why the "Inventory Phase" is the most critical part of DMARC implementation. We suggest to let the monitoring run for a quarter, because some tools will not send emails on a daily nor weekly basis.
2. “Unexpected SPF IP but DKIM Still Passes”: Sherlock Holmes Mode
When you see a row in your DMARC report where SPF fails (IP mismatch) but DKIM passes, you have a huge clue.
This is almost certainly a legitimate third-party service.
Why? Because spammers generally can't sign with your private DKIM key. If the email is signed with your domain (d=yourdomain.com), someone in your organization gave that vendor the keys (or set up the CNAME records).
Action: Look at the Selector in the DKIM signature. It often points to the vendor (e.g., k1._domainkey is often Mailchimp, google._domainkey is G Suite). Trace that selector back to the owner internally.
3. The Usual Suspects: A Checklist for Your Inventory
Don't wait for the reports to surprise you. Go ask these departments what they are using:
- Marketing: Mailchimp, HubSpot, Salesforce, ActiveCampaign, Marketo.
- Support: Zendesk, Help Scout, Intercom, Freshdesk.
- HR/Finance: Workday, ADP, Quickbooks, Stripe, Xero.
- Engineering: PagerDuty, Jira, AWS SES, SendGrid, Mailgun.
- Legal: DocuSign, HelloSign.
Every single one of these needs to be configured to authenticate as YOU (usually via DKIM CNAMEs), or they will fail DMARC once you move to strict policies.
4. Vendor Management: "Do You Support DMARC?"
This is the question you need to start asking every vendor before you sign the contract.
Bad Answer: "Just add our IP to your SPF record." (This is brittle, hits the 10-lookup limit, and doesn't solve alignment issues).
Good Answer: "We support DKIM. Here are the 3 CNAME records to add to your DNS."
If a vendor sends email as your domain but doesn't support DKIM or SPF alignment, you have two choices: Make them use a subdomain (e.g., support.yourdomain.com) or find a new vendor.
5. FAQ: Solving the Mystery
How do I find all services sending email from my domain?
The only reliable way is to publish a DMARC record with p=none and analyze the Aggregate (RUA) reports for at least 4 weeks, a full quarter being optimal. This captures the full billing/monthly cycle of automated emails.
Why do DMARC reports show IPs I don’t recognize?
These are often forwarded emails (auto-forwarding by employees or recipients) or legitimate third-party senders using shared IP pools (like SendGrid or Mailgun) that you haven't authenticated yet.
What is "Shadow IT" in email?
It refers to cloud services or tools used by employees to send company email without the IT department's knowledge or approval. DMARC flushes them out... or a least reveal them!