Why DMARC Passes for Mail You Did Not Send

The confusing DMARC pass you did not expect

You check your DMARC aggregate reports after deploying a strict p=reject policy. Most of the data looks good -- spoofed attempts are being rejected, and your legitimate sending domains are passing authentication as expected.

Then you see something odd. There are 179 emails showing a passing DMARC result, going to Google-owned IP addresses, with the From header set to your own domain. You never sent them. Your marketing team is not running campaigns from Google IPs. Your IT team is not sending from those addresses either.

So how did they pass DMARC?

The short answer is that DMARC passing and DMARC authorized are two different things. Authentication and authorization are not the same layer in email, and reading your DMARC reports correctly requires understanding that distinction from the start.

Authentication vs Authorization: The distinction DMARC does not make for you

SPF, DKIM, and DMARC are all authentication mechanisms. They check whether an email's technical sending infrastructure is permitted to claim a particular domain. They do not check whether whoever is sending the email actually has permission to use that domain in the From header.

Here is what each protocol actually verifies:

SPF checks whether the sending mail server's IP address is listed in the SPF record for the domain in the Envelope From (also called Return-Path or MAIL FROM). It does not look at the From header at all.
DKIM checks whether an email was signed with a private key that matches a published public key for the signing domain. The signing domain can be different from the From header domain.
DMARC ties SPF and DKIM results to the From header domain through alignment. If either aligned SPF or aligned DKIM passes, DMARC passes.

None of these checks ask: "Is this sender actually allowed to send on behalf of this organization?"

That is an authorization question, and email was not designed to answer it at the protocol level.

How this happens in practice: The third-party sender scenario

The situation in the original report -- 179 emails passing DMARC from Google IPs, From header showing the organization's own domain -- is a textbook example of how legitimate third-party senders can produce exactly this result.

Here is the technical chain that makes it possible:

1. A third-party service sends email with your domain in the From header. This could be a SaaS marketing platform, a cloud platform your developers use for internal notifications, a financial service that sends invoices, or a legacy internal relay.
2. The third party authenticates with its own SPF record (the sending IP is authorized for their service's domain) and signs with its own DKIM key (the signing domain is their service domain, not yours).
3. The message passes DMARC through one of two mechanisms:

DKIM alignment via third-party signing: Many SaaS email services use Domain Matching -- they sign with a DKIM key published on your domain's DNS rather than their own. If the service holds the DKIM private key and your DNS has the matching public record, the DKIM signature validates for your domain. When that aligned DKIM passes, DMARC passes regardless of SPF.

SPF alignment via SRS: Sender Rewriting Scheme rewrites the Envelope From address when relaying mail, so the Return-Path domain matches the From header domain. This satisfies SPF alignment even though the actual sending infrastructure belongs to the third party.

In both cases, the From header says it came from your organization, the authentication checks agree, and DMARC passes -- but your own SPF record and DKIM keys played no role.

Common real-world examples include:

Google Workspace configured to route outbound mail through Google's servers with your custom domain in the From header

SaaS platforms that send customer-facing email with the customer's domain as the From address (common in HubSpot, Marketo, SendGrid, Postmark, and transactional email services)

Internal developer notification systems that relay through third-party SMTP providers

CRM systems that send on behalf of sales representatives with organizational From addresses

Why this is a security problem even when DMARC passes

A DMARC pass does not mean your domain is being used correctly. It means your domain is being used, and the sending infrastructure is authenticated -- not that the sender is authorized.

The risk is unauthorized but authenticated email. A malicious actor who compromises a legitimate third-party service that sends with your From header can produce DMARC-passing email without touching your own infrastructure at all. Your SPF record will not show the attacker's IP. Your DKIM keys are untouched. The only evidence is in your DMARC aggregate reports: a sending source you did not know about, sending authenticated email you did not authorize.

This is not a theoretical edge case. Services that authenticate with your From header are a documented attack surface. If such a service is compromised, attackers can send email that passes DMARC and appears to come from your organization, reaching the inbox without triggering any of your own authentication failures.

How to investigate using DMARC aggregate reports

DMARC aggregate reports (RUA) do not contain message content -- they contain metadata about authentication results, including the sending IP, the result of SPF and DKIM checks, and the envelope domains. Here is how to use them when you see unexpected passes:

Step 1: Identify the sending IP. A DMARC pass from an IP you do not recognize needs investigation. Look the IP up. If it belongs to a cloud provider (Google, AWS, Microsoft Azure), a SaaS email service, or any platform you did not knowingly onboard, that is a finding.

Step 2: Read the Return-Path domain. The Return-Path (envelope from) tells you the actual origin domain at the SMTP level. If it shows a service domain you do not recognize -- something like sendgrid.net, mailgun.org, or a major cloud provider -- that service is the actual sender. This is not automatically malicious, but if you did not onboard it, you need to find out how it got there.

Step 3: Cross-reference DKIM results. If the report shows a DKIM pass, find out which domain signed the message. If it is not your own domain, the message was signed by a third party on your behalf. That third party may be authorized (a service you hired) or unauthorized (a compromised or misused service).

Step 4: Look for volume anomalies. A sudden increase in DMARC passes from an unknown source is more alarming than a steady baseline. Know what your normal sending patterns look like so new sources stand out immediately.

Step 5: Check for domain mismatch patterns. Services you onboarded should map to known sending IPs and envelope domains. Anything that does not map to your known inventory needs a reason.

How DMARCFlow surfaces these findings automatically

Doing this investigation manually is slow and easy to neglect. DMARCFlow processes your aggregate reports continuously and automatically flags unknown sending sources, new DKIM signing domains, and volume anomalies before they become incidents.

When a DMARC pass appears from a sending IP outside your known inventory, DMARCFlow alerts you. When a third-party DKIM signing domain appears that does not correspond to any authorized service in your configuration, DMARCFlow surfaces it. The manual investigation steps above -- checking sending IPs, Return-Path domains, DKIM signing domains, volume baselines -- are the automated logic that DMARCFlow runs on every report, around the clock.

Rather than discovering unexpected authenticated senders during a post-incident review, you see them as they appear. That is the practical difference between periodic manual audits and continuous monitoring.

Key takeaways

DMARC pass means authentication passed, not that the sender was authorized.
Third-party senders using your From header can produce DMARC-passing email legitimately, without any malicious activity.
A compromised third-party service can send DMARC-passing email that appears to come from your organization, bypassing all your own authentication infrastructure.
Your DMARC aggregate reports are the primary investigation tool -- look for sending IPs and Return-Path domains you do not recognize.
Continuous DMARC report monitoring is the only reliable way to catch unexpected authenticated senders before they become incidents.

FAQ

Can DMARC pass for email I did not send?

Yes. If a third-party service is authorized to send on your behalf and its sending infrastructure satisfies SPF or DKIM alignment, DMARC will pass. This is not a misconfiguration -- it is how DMARC works when third-party senders are involved. The question is whether you know about and have authorized every service that sends this way.

What does it mean when SPF and DKIM pass but I did not send the email?

It means the sending server was authorized by its own SPF record, and either that server or a signing service holds a valid DKIM key for a domain that aligns with your From header. This is common with SaaS platforms and legitimate third-party senders. It can also indicate that a compromised third-party service is being used to send on your behalf.

How do I find out who is sending email from my domain without authorization?

Check your DMARC aggregate reports for sending IPs you do not recognize. Look at the Return-Path domain to identify the actual envelope sender. If the sending IP belongs to a service you did not onboard, investigate whether it should have been authorized through a formal onboarding process. Automated monitoring tools like DMARCFlow keep a running inventory of every sending source that authenticates against your domain so unexpected additions stand out immediately.