Shadow IT and Email: The Tools Sending on Your Behalf Without You Knowing

You’ve configured SPF, DKIM, and DMARC. Your email infrastructure is under control. Then one day, while analyzing your DMARC reports, you discover dozens of unknown IPs sending emails on behalf of your domain. Not phishing - internal tools that nobody in IT ever approved.

Welcome to the world of email shadow IT.

What Is Email Shadow IT

Shadow IT refers to the use of technology services without explicit approval from the IT team. Applied to email, it’s extremely common: business teams configure SaaS tools to send emails from your domain without going through IT.

These tools aren’t malicious. They’re perfectly legitimate. But they send emails on behalf of yourdomain.com without anyone having:

• Added their IP to the SPF record
• Configured a DKIM signature with your domain
• Verified alignment with your DMARC policy

The result: these emails fail authentication checks and end up in spam - or are outright rejected if you’re at p=reject.

The Usual Suspects

The list is long, and it grows with every new tool your teams adopt:

Marketing and CRM

• HubSpot - marketing emails, prospecting sequences, CRM notifications
• Salesforce - workflow alerts, campaign emails, sales notifications
• ActiveCampaign, Klaviyo, Drip - marketing automation
• Intercom, Drift - chatbots sending email recaps
• Mailchimp - the newsletter marketing launched without telling anyone

Internal Tools and Productivity

• Notion - page sharing via email, comments
• Calendly, Cal.com - appointment confirmations and reminders
• Jira, Linear - ticket notifications
• DocuSign, Yousign - signature request emails
• Typeform, Tally - form submission confirmations

Support and Billing

• Zendesk, Freshdesk - support tickets sent from your domain
• Stripe - receipts and invoices
• QuickBooks, Xero - accounting documents
• SendGrid, Postmark - used by a developer for a one-off project, then forgotten

Former Vendors

• A freelancer who configured a tool two years ago
• A former ESP whose include is still in your SPF but no longer in use
• A trial service that’s still sending notifications

Why This Matters

Silent Authentication Failures

If these services aren’t covered by your SPF and don’t have an aligned DKIM signature, their emails fail DMARC verification. With p=none, they pass anyway - you see nothing. With p=quarantine or p=reject, they’re filtered or rejected.

Either way, someone in your company wonders why “emails aren’t getting through” - without knowing it’s a DNS issue.

Blocking Your DMARC Migration

This is the number one reason companies stay stuck at p=none for months. They want to move to p=reject (as recommended in the guide DMARC: from p=none to p=reject), but they’re afraid of breaking flows they don’t know about.

SPF Record Bloat

Each tool added requires an include: or an IP in your SPF record. With 5, 10, 15 services, you exceed the 10 DNS lookup limit imposed by RFC 7208. A broken SPF invalidates all your sends, not just the offending service.

Expanded Attack Surface

Every include: in your SPF authorizes that vendor’s servers to send on behalf of your domain. If a vendor you no longer use is compromised, their servers can send spam or phishing with your identity.

How to Detect Email Shadow IT

Method 1: DMARC RUA Reports

This is the primary tool. If you have a DMARC record with a rua= tag, mailbox providers (Gmail, Microsoft, Yahoo) send you a daily aggregate report of every IP that attempted to send email from your domain.

In these reports, look for entries with:

source_ip: [unknown IP]
spf: fail
dkim: fail
disposition: none (or quarantine/reject)

Or, more subtle:

source_ip: [unknown IP]
spf: pass          ← the IP is in your SPF
dkim: fail         ← but DKIM isn't configured
disposition: none

This second case is typical shadow IT: someone added the SPF include but didn’t enable DKIM. The email is “authorized” by SPF but not cryptographically signed.

For detailed report interpretation, see the guide Reading and Understanding DMARC Reports.

Method 2: The Sender Audit Dashboard

If you’ve added your domain to Sender Audit, DMARC reports are parsed automatically. The dashboard classifies sources into three categories:

• Verified: known sources with correct authentication
• Needs review: sources with partial authentication (SPF pass but DKIM fail, or vice versa)
• Unauthorized: unknown sources failing all checks

Continuous monitoring also detects new sources appearing between reports - the most reliable signal for catching a newly configured SaaS tool.

Method 3: Reverse SPF Audit

List all include: mechanisms in your current SPF record, then verify each one:

1. dig TXT yourdomain.com - list all include: mechanisms
2. For each include:, identify the service (e.g. include:spf.brevo.com → Brevo)
3. Ask each department: “Are you still using this service to send emails?”
4. Remove orphaned include: entries

It’s tedious but revealing. Finding 2 or 3 obsolete services is not uncommon.

The Resolution Workflow

Once shadow IT sources are identified, here’s the process for each one:

Step 1: Identify the Service

From the source IP (visible in the DMARC report), trace back to the service:

• rDNS: dig -x [IP] - the provider name often appears in the PTR record
• Whois: whois [IP] - identifies the organization owning the IP range
• ASN: the AS number and associated organization (Amazon, Google Cloud, OVH, etc.)
• Sender Audit: the dashboard automatically displays rDNS and organization for each source IP

Step 2: Validate Legitimacy

Contact the relevant department:

• “Are you using [service X] to send emails from yourdomain.com?”
• “Who configured it and for what purpose?”
• “Is it still active and needed?”

Three possible outcomes:

Step 3: Integrate Properly

For each validated legitimate service:

1. SPF: verify the include: is present (and that you don’t exceed 10 lookups)
2. DKIM: enable custom DKIM signing in the service settings. Most offer this option via a DNS CNAME
3. Verify alignment: send a test from the service and analyze it with Sender Audit to confirm SPF and DKIM align with the From:
4. Document: maintain a registry of services authorized to send from your domain

Step 4: Block Unauthorized Sources

• Remove the corresponding SPF include: entries
• Progressively tighten your DMARC policy toward p=reject
• Monitor RUA reports to confirm unauthorized traffic is being blocked

Preventing Shadow IT: Email Governance

Email shadow IT is a recurring problem. Without governance, it comes back every time a new service is adopted.

Email Sending Policy

Document a simple, shared policy:

Any service sending emails from @yourdomain.com must be approved by IT before configuration. Contact it@yourdomain.com with the service name, intended use, and the vendor’s DNS documentation.

New Service Onboarding Checklist

For each new SaaS that needs to send emails:

1. Collect the vendor’s DNS requirements (SPF include, DKIM CNAME)
2. Verify the SPF addition won’t exceed 10 lookups
3. Configure custom DKIM
4. Test the send flow with Sender Audit
5. Add the service to the registry
6. Optional: dedicate a subdomain (support.yourdomain.com for Zendesk)

Continuous Monitoring

Even with good governance, services slip through the cracks. Automated monitoring is your safety net:

• DMARC reports flag every new source
• Sender Audit monitoring alerts on DNS changes (new SPF include:, modified DKIM, altered DMARC)
• Checks every 12 hours detect drift before it impacts your sends

Real-World Example: A 50-Person Company with 8 Sending Services

Here’s a simplified real case. A small company with the domain acme.com:

Audit results:

• 2 services known and properly configured
• 2 services in SPF but missing DKIM → DKIM enabled
• 2 services not covered → added to SPF + DKIM configured
• 2 obsolete services → include: entries removed from SPF

After remediation: the SPF record drops from 9 to 7 lookups, all legitimate services pass DMARC, and the migration to p=reject can finally begin.

Learn More

• Reading and Understanding DMARC Reports (RUA)
• DMARC: Migrating from p=none to p=reject
• SPF: The Complete Guide
• DKIM: Signing Your Emails
• Email and DNS: Every Record You Need to Know
• Sender Audit Dashboard to visualize your sending sources