Your own systems are the ones getting caught

A CRM sends a notification to eight employees. Two see it. The others find it in junk, if they look at all.

Nobody reports a security incident. They report that the CRM's email is unreliable. The surprising part is that the organization's own anti-spoofing controls may be doing exactly what they were configured to do.

The message is legitimate. Its authentication design is not.

The visible sender and the authenticated sender can be different

A business application needs a way to send mail. Out of the box, many platforms authenticate using infrastructure and domains they control.

At the same time, the visible From address may use your company domain because that is how the feature is meant to look to the recipient. Those two identities are not automatically the same.

DMARC asks whether successful SPF or DKIM authentication aligns with the domain visible in the From address. If neither authentication path aligns, DMARC fails.

The mail may have been generated by a perfectly legitimate CRM or billing platform. From the receiving system's point of view, it still has the shape of mail claiming your domain without aligned authentication.

Your security control may be the first place you notice

Organizations often have additional protection against inbound messages claiming to come from their own domain. That is a useful control. It can also expose badly configured application mail.

An employee receives a message that appears to be from the company, but the authenticated identity belongs to an unrelated sending platform. The security control has no way to know that somebody in another department approved the SaaS integration six months ago. It sees the mail in front of it.

This is why turning off spoofing protection is the wrong first response. The message needs to be fixed at the source.

Why the symptom looks like a spam problem

Every participant can tell a technically true story. The SaaS vendor says the message was sent. It was.

Your DNS team says SPF, DKIM and DMARC are configured for the corporate mail platform. They are.

The employee says the message was filtered. It was.

The missing question is: How is this particular application authenticating mail that displays our domain? That is the question that joins all three observations together.

Fix the sending source where possible

Many mature SaaS platforms provide a way to authenticate mail using customer-controlled DNS. That may include custom DKIM signing, a custom return path or another mechanism that lets the application's mail align with your domain. The exact feature differs by product.

The objective is the same: At least one successful DMARC authentication path should align with the visible From domain.

Another architecture is to route application mail through an outbound service you control, where that design is supported and justified. That can simplify authentication across several systems, but it also adds another piece of infrastructure to operate.

Either approach is better than broadly weakening the anti-spoofing control that revealed the problem.

Be careful with bypasses

A temporary exception is sometimes necessary. Treat it as temporary.

• Scope it narrowly.
• Record why it exists.
• Give it an owner.
• Give it a removal condition.

A broad bypass for an entire sending platform can authorize far more than the one application or tenant you intended to fix. The permanent answer should be correct authentication wherever the sending product supports it.

Find the senders you did not know existed

Fixing the one application that generated a complaint often exposes a larger inventory problem.

• CRM.
• Billing.
• Ticketing.
• HR.
• E-signature.
• Monitoring.
• Survey tools.
• Product notifications.
• Marketing systems.

Every one of them can send using a company identity. DMARC aggregate reporting can help expose sources observed sending under the domain, although reporting is not a complete inventory of every message everywhere. Use it together with SaaS inventory and actual message headers.

An unfamiliar source should be investigated before anyone changes DNS to make it pass. First establish what is sending. Then decide whether it should be authorized.

The check worth running

List the applications that send messages displaying your company domain. Take one recent message from each. Inspect both DKIM and SPF in the headers and check whether at least one successful authentication path aligns with the visible From domain.

Anything that fails deserves one of two outcomes:

• Correct its sending configuration.
• Or stop allowing it to send as you.

Explore this expertise: Email Deliverability

All technical notes