A signature covers the message, not the route

A domain's reputation starts falling. Complaints increase and delivery becomes less predictable.

The obvious reaction is to inspect SPF, DKIM and DMARC. Then the reports show that most of the problematic traffic is passing.

Authentication is working. That does not necessarily mean the mail is wanted.

DKIM signs the message

DKIM applies a cryptographic signature to selected headers and the message body. If the signed parts are not changed, that signature can remain valid when the message is forwarded or relayed.

That behavior is useful. Legitimate forwarding depends on authentication surviving changes in the route.

It also creates an important limitation. DKIM proves that the signed content came through a system authorized to sign for that domain and that the covered content has not changed. It does not normally bind the message to one delivery path or one recipient.

A valid message can be sent again

If somebody obtains a legitimately signed message and resends it without changing the signed content, the DKIM signature may still validate. SPF may fail because the new sender is different. But DMARC can still pass when the DKIM signature remains valid and aligned with the From domain.

That does not mean every receiver will accept unlimited copies. Mail providers have many other abuse and reputation systems.

It means something narrower and important: DMARC is not replay protection. A message can pass authentication and still be part of abusive traffic.

Abuse can start inside your own platform

There is an even more common version of the same problem. Suppose your product lets customers send invitations, notifications, campaigns or messages. Someone creates an account and abuses that feature.

The resulting mail is sent through your infrastructure, signed with your keys and authenticated correctly. From the perspective of SPF, DKIM and DMARC, nothing is wrong.

The problem is not authentication. The problem is that a legitimate sending capability is being used for traffic you do not want associated with your domain.

Tightening DNS does not solve this

DMARC enforcement tells receivers what to do when authentication and alignment fail. These messages pass. Changing from quarantine to reject therefore does not fix them.

The useful controls sit earlier in the process: who is allowed to send, how much they can send, how quickly unusual behavior is detected and whether user-generated traffic is separated from important corporate or transactional mail.

Rate limits, account controls and anomaly detection matter here. So does stream separation.

Using dedicated subdomains for different kinds of sending will not create a perfect reputation firewall, but it gives you clearer visibility and can reduce how easily one problematic stream damages everything else.

Read the passing traffic too

DMARC aggregate reports naturally draw attention to failures. For this problem, look at the successful traffic.

Where reporting is available, compare volume with what your systems should actually be sending. Identify sources you do not recognize. Look for sudden changes in how much passing mail is appearing.

Authentication reports are not only a list of things that failed. Unexpected success can be a finding too.

The check worth running

Take your recent DMARC aggregate data and look at volume rather than failure rate. Go through the major sources producing authenticated traffic and name the system behind each one.

Any significant passing source or volume you cannot explain deserves investigation. The interesting message may be the one that authenticated perfectly.

Companion technical note: Authenticated is not authentic

Explore this expertise: Email Security

All technical notes