What to do when a report shows Unknown senders

Why "Unknown" exists in the first place

Every row in a DMARC report has a source IP — the actual server that connected to the receiver and tried to deliver mail. Our dashboard runs each of those IPs through a corpus of known senders (Google Workspace, Microsoft 365, Mailchimp, Amazon SES, several dozen others) and attaches a vendor name when it matches.

The corpus isn't exhaustive. New ESPs launch, regional providers exist, niche SaaS apps spin up their own outbound infrastructure. When an IP doesn't match anything we know, the row is labeled Unknown. That's a statement about our coverage, not about the IP's intent.

Practically: most Unknowns turn out to be a real vendor that's just outside the corpus. Some are forwarders or relays that legitimately handle your mail but don't sign as you. A small minority are bad actors. The triage below sorts them.

Step 1: Look at the alignment column first

Before doing any investigation, glance at whether the row passed DMARC alignment. Alignment is the load-bearing signal for triage — much more than the SPF or DKIM raw pass/fail. It tells you whether the sender has authority to send as your domain.

Aligned + passing → almost always a forgotten vendor

A sender that passes alignment is producing valid SPF and/or DKIM authentication for your domain. They couldn't do that without your DNS explicitly authorizing them at some point. Spoofers can't fake alignment — they'd need to either control your DNS or possess your private DKIM key.

So: if you see Unknown + aligned + passing, the question isn't "are they legit?" — they are. The question is "which vendor is this and did we set them up on purpose?"

Common culprits when this happens:

• A marketing tool a previous employee set up (Mailchimp, ConvertKit, ActiveCampaign).
• An invoicing or billing platform (Stripe, FreshBooks, Xero, QuickBooks).
• A help-desk or support tool (Zendesk, Intercom, HubSpot, Help Scout).
• An e-signature or document tool (DocuSign, HelloSign, PandaDoc).
• A monitoring / status / alerting tool (PagerDuty, StatusPage, OpsGenie).
• A CRM you forgot integrated email-sending (Salesforce, HubSpot, Pipedrive).
• A regional ESP that's not in our corpus yet.

Once you confirm what it is, hit the Identify button on the Senders tab. Name the vendor, pick a category, and the IP becomes a known sender for every future report — both for your workspace and (when you opt in) as a corpus contribution.

Misaligned but passing → broken setup, forwarder, or scoped third-party

SPF or DKIM passes for some domain, but not your domain. This is common and usually not malicious. A few specific causes:

• A vendor that signs as itself, not as you. Some transactional senders sign with their own DKIM domain (e.g. d=mailgun.com) when they really should be signing as you. Their setup needs fixing, not yours. Reach out to the vendor and ask them to enable domain-aligned DKIM signing for your tenant.
• Email forwarders. Someone subscribed to your mailing list uses a forwarding rule (Gmail forwarding, an old corporate forward). Forwarders preserve DKIM but break SPF (the connecting IP is the forwarder's, not yours). DMARC was redesigned around DKIM survival specifically because of this — if your DKIM is solid, the forwarded mail aligns and passes.
• Mailing-list software. Listserv-style mailing lists rewrite headers and re-sign the message; the result is that authentication passes but doesn't align to you. Modern lists handle this with From: rewriting (the message appears to come from the list, not the original sender) but plenty of old configurations still misalign.

When the volume is small, ignore these. When it's large and you've identified the vendor as legitimate, ask them to fix their alignment — or accept that some chunk of mail won't align and plan policy progression accordingly.

Failing outright → likely either spoofing or a forwarder breakage

SPF fails AND DKIM fails. The sender either has no authentication at all or their authentication is broken. Two common cases:

• Spoofing or phishing. Someone is sending mail with From: you@your-domain.com from infrastructure they control. They have no authority to authenticate as you, so SPF and DKIM both fail. This is exactly what DMARC was built to expose.
• Forwarder breakage. Some old-school forwarding setups break DKIM in transit (header modifications, body modifications). The message was originally signed correctly; the forwarding broke it. Volume tends to be small and reception domains tend to repeat — telltale.

Triage: look at the message count and whether the same IP appears in past reports. Five messages once a month from a small ISP is probably forwarding breakage. Two thousand messages from an unfamiliar block, all to a single receiver, with no historical pattern — that's worth investigating.

Step 2: Figure out who the Unknown IP actually is

For any Unknown you want to identify, here are the four cheap lookups in order of usefulness:

Reverse DNS (rDNS)

Most well-run senders have meaningful PTR records. dig -x 1.2.3.4 (or any "what is the rDNS of this IP" tool) often gives you the vendor name immediately: outbound-mail.sendgrid.net, mail.protection.outlook.com, relay.mailroute.net. If the rDNS is generic (cloud provider IP with no business name), move on.

WHOIS the IP

WHOIS (or any IP-info lookup tool) tells you who owns the IP block. Often that's the cloud provider (AWS, GCP, Cloudflare, OVH) — which doesn't help directly but does tell you "someone is sending from a public cloud, likely a SaaS." It can also surface the actual operator's name when the block is directly registered.

ASN owner

Every public IP belongs to an Autonomous System (an ASN). The ASN owner is usually the network operator. whois -h whois.cymru.com 1.2.3.4 gives you "AS15169 Google LLC" or similar. Strong signal when the ASN is a recognizable ESP.

Reverse-search by SPF

If the rDNS or ASN suggests a vendor, check their published SPF record. Resolve _spf.example-vendor.com recursively and see if the Unknown IP falls inside any of the published ip4: / ip6: ranges. If it does, you've confirmed the vendor.

Last resort — search the IP

Paste the IP into a search engine. Spam blocklists, threat-intel writeups, and vendor support pages frequently come up. If the first few results are spam-blocklist entries, the answer is "this is a known bad source" and you've got your spoofing confirmation.

Step 3: Identify or ignore

Once you know who the Unknown is, hit the Identify button on the Senders tab. Pick a category, name the vendor, and submit. The row turns into a known sender for every future report. The mental model of "who sends as us" stays accurate.

For Unknowns you confidently can't identify after the lookups above:

• If volume is small (single digits a week) and aligned + passing— leave it. It's probably a forwarder or a one-off relay; identifying it gains nothing.
• If volume is small and misaligned — also fine to leave. Same reasoning.
• If volume is large and aligned + passing — keep investigating. There's a vendor in your stack you don't know about, and you really do want to know what it is before progressing past p=none.
• If volume is large and failing alignment — flag it, investigate, and don't progress your DMARC policy until you understand it. This is the case DMARC was built for.

The slow-bake principle

Don't rush to identify every Unknown the first day. A single low-volume Unknown might never appear again. Wait for a week of reports and look at which Unknowns repeat — those are the ones worth the investigation budget. Patterns over a week tell you more than any single report does.

Conversely: when an Unknown shows up suddenly with high volume and you've never seen it before, that's exactly when you act fast. New + high-volume + unfamiliar = the signal that triggered DMARC's existence in the first place.

What never to do

• Don't auto-Identify Unknowns based on rDNS alone. An IP's rDNS can be misleading or stale; a confident match needs SPF reverse-search confirmation, not just a hostname guess.
• Don't progress your DMARC policy past p=none while large-volume Unknowns are unidentified. Enforcement on unidentified senders means real mail starts disappearing. Identify first, progress second.
• Don't blindly add an Unknown's IP to your SPF record. If the sender is legitimate, they should be authenticating themselves (publishing an SPF that includes their IPs, or signing with DKIM). Cramming their IP into your SPF burns a lookup slot and creates a long-term maintenance burden.

Related

• Reading your first DMARC report — context for what a report row even means.
• DMARC alignment, in plain English — the column triage hinges on.
• Progressing past p=none safely — what to do once your Unknowns are sorted.