Why DMARC Passes for Mail You Did Not Send

If you checked your DMARC aggregate reports and found passes for emails you never sent, you are not imagining it. This happens regularly, and in most cases it has a specific technical explanation. Here is what is going on.

The difference between authentication and alignment

Before getting into why DMARC passes for unsent mail, it helps to understand what DMARC actually checks. There are two separate steps.

SPF and DKIM are authentication mechanisms. They check whether the sending server is authorized and whether the message carries a valid cryptographic signature. Neither of these checks looks at your From header.

DMARC alignment is what connects authentication to your domain. It asks: does the domain that passed SPF or DKIM match the domain in the From header that the recipient sees? All three checks must align for a true DMARC pass.

This distinction matters. A message can have valid SPF, valid DKIM, and still fail DMARC if the authenticated domain does not match your From domain. Conversely, a message can pass DMARC for reasons that have nothing to do with your sending infrastructure.

Why forwarding causes unexpected DMARC passes

When a message is forwarded, the forwarder re-sends it from its own mail servers. Here is what typically happens.

The original DKIM signature usually survives the forward. It was added before the message left the original sender, and most forwarders do not strip it. When the receiving server validates that signature, DKIM passes for the original sender domain.

SPF behaves differently. The forwarder mail server IP is not in the original sender SPF record, so SPF fails for the original domain. However, SPF does pass for the forwarder own domain -- because the forwarder is authorized to send for itself, not for you.

When the receiving server evaluates DMARC, it checks whether the domain that passed authentication aligns with the From header. The From header still shows the original sender domain. Since DKIM passed for that same original domain, alignment holds -- even though SPF failed. This is why DKIM-aligned forwarding produces DMARC passes that look unexpected.

If the forwarder rewrites the From header to its own domain, alignment fails and DMARC fails. But many forwarders, including most email clients and mailing lists, leave the original From header intact.

Authorized third-party senders

A more intentional version of the same scenario: you may have vendors, platforms, or service providers that send email as your domain. Marketing platforms, CRM systems, billing software, and support tools often send transactional email on behalf of their customers domains.

If those providers are properly authorized in your SPF record or your DKIM signing domain, authentication passes. Alignment also passes because they send using your From domain. This shows up in your DMARC reports as passes from IP addresses you do not recognize, and those passes are legitimate. The mail was authorized, just not sent by your internal team.

If you see passes from IPs you do not recognize, the first step is to check whether they belong to any platform you use. Many businesses do not realize how many services are authorized to send as their domain until they read the aggregate reports.

When passes could indicate a real problem

Most DMARC passes for unsent mail are harmless forwarding or documented vendor sending. But there are cases worth investigating.

Look for passes from IP ranges that do not match any known vendor. If you have retired a platform but it still appears in your reports with passes, someone may still be using those credentials. If you see unusual volume -- hundreds of passes from a source you do not recognize -- that is worth a closer look.

Unauthorized passes can also occur when a service is compromised. A marketing platform account breach might let an attacker send as your domain from infrastructure you did not authorize. The authentication would still pass because the platform is authorized. The signal in your DMARC report would be a new, unfamiliar IP sending volume.

This is one reason DMARC aggregate reports are worth reading even when everything looks fine. Patterns you did not expect are often the first sign of something unusual.

How to investigate unfamiliar passes

Your DMARC aggregate reports contain the IP addresses, sending volumes, and authentication results for every message seen purporting to come from your domain. Here is how to use them.

First, identify the IP addresses in your reports and cross-reference them against your known sending infrastructure. Your internal mail servers, your approved vendors, your cloud platforms -- build a list of everything authorized to send as your domain.

Second, check DKIM selector domains. If a message passed DKIM with a selector you do not recognize, that DKIM key does not belong to your infrastructure. It could be a vendor you forgot to document, or it could be something to investigate further.

Third, look at sending volume over time. A spike in passes from a source you have not seen before, especially around the same time as a platform migration or vendor onboarding, often has a mundane explanation. But sudden new patterns deserve a direct look.

If you do not have a tool to parse XML aggregate reports automatically, this is where DMARC monitoring services add real value. Reading raw XML is possible but time-consuming for any domain with meaningful mail volume.

DMARCFlow automates the report analysis and flags unfamiliar sending sources automatically, so you can distinguish between new vendors you have not documented yet and genuinely unexpected infrastructure. Rather than reviewing every unfamiliar IP by hand, you get a prioritized alert when something new appears in your reports.

What action to take

If the passes all come from known, approved vendors: document them, confirm they are expected, and move on. Unauthorized passes that are actually harmless are still worth knowing about for inventory purposes.

If unfamiliar IPs appear in your reports: investigate before you panic. Check whether the IP belongs to a platform you use. Look at the sending volume. If the pattern persists and you cannot explain it, consider temporarily tightening your DMARC policy from p=none to p=quarantine to see whether it affects legitimate sending before making any firm changes.

If you need ongoing visibility into which sources are passing DMARC for your domain, regular report monitoring helps. DMARCFlow can automate the analysis and alert you to new sending patterns as they emerge, which is especially useful if you manage multiple domains or work with several third-party senders.

FAQ

Can someone send email as my domain without my knowledge?
Yes, if they control a platform that is authorized to send on your behalf. This is not uncommon with marketing and transactional email platforms. It is also possible through compromised accounts on authorized platforms.

Why do I see DMARC failures and passes for the same type of mail?
This usually means different receiving servers handle your messages differently, or your sending infrastructure changed. Some servers may handle forwarding differently than others, producing different alignment results for the same message.

Should I block all DMARC passes from IPs I do not recognize?
Not without investigating first. Some passes from unfamiliar IPs are legitimate vendor sending. Others could indicate a misconfiguration. Understand what is producing the passes before taking action.

What is the difference between RUF and RUA in DMARC?
RUA (Reporting URI for Aggregate) sends you regular summaries of authentication results. RUF (Reporting URI for Forensic) sends individual failure reports for specific messages. RUF gives you message-level detail but generates much higher volume. Most small to mid-size businesses get value from RUA first.