Unknown Sender in DMARC Reports: 15-Minute Triage

A new source shows up in your DMARC aggregate reports. It sent 40 messages as example.com, and nobody on the team recognizes the IP.

It might be a CRM trial someone connected last month, a billing platform sending receipts from its own domain, a forwarder relaying mail your users sent themselves, or someone forging your domain. Treat all four the same and you either break DNS in a panic or ignore the row until a customer forwards you a fake invoice.

Below is a triage order you can run before you change any SPF, DKIM, or DMARC record.

What a report row says

An aggregate report is a receiver’s summary of mail it saw with your domain in the visible From: header. Each row has a source IP, a message count, and two separate blocks of authentication data:

• auth_results holds the raw DKIM and SPF results, uninterpreted with respect to DMARC. A DKIM pass for d=mailer.example.net sits here even though that domain has nothing to do with your From:.
• policy_evaluated holds the DMARC verdict for the row. It records the disposition the receiver applied, plus dkim and spf values that show whether an aligned identifier passed.

Alignment means the domain that authenticated matches the From: domain (exactly, or in the same organizational domain under relaxed mode). A message passes DMARC when at least one aligned mechanism passes. If you want the long version of why SPF can pass while DMARC fails, read SPF passes, DMARC fails: the alignment trap.

A row is evidence that a receiver saw mail claiming to be you. It is not proof of compromise.

The buckets

The last row is the one people get wrong in both directions. A passing unknown source is more urgent than a random failing one, because something authenticates as your domain. Often the explanation is mundane. A mailbox provider or mailing list relayed a message that still carried your original DKIM signature. Step 4 separates the two.

Step 1: save the row

Copy the report fields into your incident note, using the report’s own element names:

org_name:        reporter.example.org
date_range:      begin=1760140800 end=1760227200
source_ip:       203.0.113.47
count:           40
header_from:     example.com
policy_evaluated:
  disposition:   none
  dkim:          pass
  spf:           fail
auth_results:
  dkim:          domain=example.com selector=s1 result=pass
  spf:           domain=bounce.mailer.example.net result=pass

Keep the date_range too. Report periods are expressed in UTC, which matters when you line a row up against your own logs. Without the saved fields you cannot compare the next report cleanly.

Note what this example already tells you. policy_evaluated says DKIM aligned and SPF did not. auth_results says SPF passed for a vendor domain, which is why it did not align.

Step 2: map the IP, and keep reverse DNS in perspective

dig -x 203.0.113.47 +short
whois 203.0.113.47 | egrep -i 'orgname|org-name|netname|descr|origin|country'

Reverse DNS is a clue. Hosting providers have bland PTR names, and SaaS platforms send from shared pools that never spell out the product name. Write down a candidate owner and check it against your sender inventory.

Record one more thing here: does the IP belong to a mailbox provider or a known forwarding service? You need that answer in Step 4.

Step 3: find out if the sender should exist

Search your systems, not your memory:

grep -R "example.com\|SMTP\|MAIL_FROM\|FROM_EMAIL\|SENDGRID\|POSTMARK\|SES\|RESEND" \
  .github/ config/ deploy/ terraform/ 2>/dev/null

Then check the places that skip code review:

• billing provider email settings
• support desk outbound email
• CRM automations
• product analytics notifications
• marketing campaigns
• no-code workflows built outside engineering
• old staging or UAT environments still allowed to send real mail

Ask each owner one question: “Can this system send with From: something@example.com?” If yes, it belongs in your sender inventory.

Step 4: read which identifier passed

Do not fix every unknown sender by adding it to SPF. A record that keeps growing hits the 10-lookup limit, and exceeding it returns a permerror for the whole domain.

Look at policy_evaluated first, then at auth_results to see which domain and selector backed it up.

Case A: DKIM fails, SPF fails, source is legitimate

The sender is not authenticated for your domain. Enable custom-domain DKIM in that provider and publish the DNS record it gives you. After a test send, check the selector:

# Replace selector with the s= value from the DKIM-Signature header
dig TXT selector._domainkey.example.com +short

If the provider can only do SPF, expect trouble. SPF breaks when mail is forwarded, and it only aligns if the provider lets you use a return-path on your own domain. DKIM signed as your domain survives better. See why forwarded email fails SPF, and DKIM saves it.

Case B: SPF passes, DMARC fails

SPF passed for a domain that does not align with the From: domain. In the headers of a test message (Gmail or Outlook, “Show original”) this looks like the following, in Authentication-Results syntax:

From: invoices@example.com
Return-Path: <bounce@mailer.example.net>
Authentication-Results: mx.example.org;
  spf=pass smtp.mailfrom=mailer.example.net;
  dmarc=fail header.from=example.com

More SPF includes will not fix this. You need a custom return-path domain on example.com, or DKIM signing with d=example.com.

Case C: DKIM passes, but for the vendor’s domain

Authentication-Results: mx.example.org;
  dkim=pass header.d=mailer.example.net;
  dmarc=fail header.from=example.com

The message is signed by the vendor’s domain, so DMARC finds nothing aligned. Enable custom-domain DKIM in the vendor’s settings. The record usually lands under a selector such as selector._domainkey.example.com, or as a CNAME pointing at the provider.

Case D: the unknown source passes DMARC

Do not jump to “shadow IT”. A frequent cause of an unrecognized IP passing DMARC is forwarding or a mailing list. Your user sent a legitimate message with your DKIM signature, a forwarder or list relayed it unchanged, and the signature still verified from the relay’s IP. The report shows an unknown IP with an aligned DKIM pass and, usually, a failed SPF.

Work through the identifier:

An aligned SPF pass from an unknown IP carries more weight than an aligned DKIM pass, because a forwarder normally relays under its own or a rewritten envelope domain rather than yours.

If the selector or SPF path points at a real unknown sender:

• review recent API key creation at your email providers
• review DNS changes for DKIM selectors added without a ticket
• check provider audit logs for newly verified domains or sender identities
• rotate SMTP/API credentials if the owner cannot explain the traffic

Do not wait for high volume. A source that authenticates as your domain can send convincing password-reset lures and supplier fraud.

Step 5: enforce after legitimate senders are clean

If the source fails and nobody claims it, a DMARC policy is the control. It only works safely when your legitimate senders pass through aligned SPF or DKIM. Check the current record:

dig TXT _dmarc.example.com +short

A monitoring-only record:

v=DMARC1; p=none; rua=mailto:reports@example.com

p=none expresses no preference about how receivers handle failing mail; you still get reports. Once legitimate senders are clean and unknown failing traffic remains, move to p=quarantine first. Do not add pct=; the current standard removed it. The rollout order is in moving from DMARC p=none to p=reject.

Keep in mind that a DMARC policy is a request. Receivers make the final call.

For domains that never send mail, publish v=spf1 -all and a reject policy. If they also receive no mail, add a null MX (0 .), which tells senders the domain accepts no mail. For active product domains, finish the sender audit first.

Step 6: compare the next report

After you fix or classify the sender, wait for the next aggregate report and look for one of these:

Reports arrive after their reporting period closes, so a DNS change will not show up the same hour. For immediate feedback, send a test message to a Gmail and a Microsoft mailbox and read the Authentication-Results header. Then use the next aggregate report to confirm the trend. If reports have stopped, that is not good news.

Incident checklist

• Save org_name, date_range, source_ip, count, policy_evaluated (disposition, dkim, spf), and the auth_results domains, selector, and results.
• Map the IP with reverse DNS and WHOIS. Note whether it belongs to a mailbox provider or forwarder.
• Search code, config, billing, support, CRM, marketing, and staging for an owner.
• Check which identifier passed: DKIM d= and selector, or SPF.
• Aligned DKIM pass, your selector, forwarder IP: forwarding. Aligned SPF pass from an unknown IP, or a selector you do not recognize: shadow IT or credential misuse.
• If legitimate, fix DKIM or return-path alignment before adding SPF includes.
• If unknown and failing, watch volume and enforce once legitimate senders are clean.
• Confirm in the next aggregate report before closing.

What it costs to get this wrong

Random spoof attempts are background noise. The expensive mistakes are an SPF edit that breaks your own billing receipts, and a passing unknown sender nobody looked at until the first fake invoice reached a customer.

In DMARC Guardian, the Senders tab groups the last 30 days of report rows by source (provider, or IP when no provider matches) with an aligned / misaligned / spoofed status, volume, and pass rate, and by default shows only the sources that need a decision. You still run the reverse DNS and WHOIS lookups from Step 2 yourself.

Find who is sending as your domain before a customer gets the fake invoice →