External Domains Sending as Your Organization: BEC Risk Guide

The Discovery That Sparks the Question

A new network administrator inherits a mess. During a routine review, they find that emails from external senders are arriving with the organization's own domain in the From header. No phishing link, no suspicious attachment, just a sender using the company name as if they have every right to.

The first reaction is often confusion: how is this even possible? The second reaction is usually a harder question: is this a security risk?

The short answer is yes. But the full answer matters more than the short one.

Why External Domains Can Send Email as Your Organization

Email was not designed with sender authentication at its core. The SMTP protocol lets any server claim any From address. This is not a bug in your mail system. It is how email was built.

When an external domain sends mail claiming to be from your organization, two things are actually happening:

1. The sending server has no obligation to prove it controls the domain it is sending on behalf of.
2. Your inbound mail gateway accepts or rejects the message based on your current email security configuration.

Without DMARC enforcement in place, your receivers have no signal telling them whether to trust the sending domain. SPF and DKIM checks happen independently, but neither of them says: "this domain is actually authorized to send on behalf of my domain."

The Difference Between SPF, DKIM, and DMARC

SPF verifies that the sending server is authorized for the return-path domain. DKIM verifies that the message was signed by a domain that matches the From header. DMARC ties both together and adds a policy: what should receivers do with mail that fails?

Here is the practical gap most organizations miss: an external sender can pass SPF by sending from their own authorized server and pass DKIM by signing with their own domain. Neither check stops them from using your domain in the From field. Only DMARC alignment does that.

If your DMARC policy is set to p=none, external senders can still use your domain in the From header, and receivers will accept the mail without complaint. Your employees see an email that appears to come from your organization. It may come from anywhere.

What Attackers Do With This Capability

The technique is sometimes called domain impersonation or BEC spoofing. Attackers scan an organization's public-facing email addresses, then send messages from external servers using the target domain in the From header. The return path points somewhere else. The email passes SPF and DKIM because the sending infrastructure is technically valid.

BEC criminals prefer this approach because it is cheap, hard to trace, and effective without payloads or malicious links. All they need is an external mail server and a target organization's domain name.

The problem is not theoretical. DMARC aggregate reports frequently show external domains sending as your domain before any incident response is triggered. The visibility gap exists in most organizations that have not reviewed their aggregate reports.

How DMARC Aggregate Reports Show External Domain Sending

When a receiver processes mail claiming to be from your domain, it performs authentication checks and generates a report. These reports land in your inbox or a designated endpoint as XML or JSON. They show which sending IPs are sending mail for your domain and which ones are passing or failing authentication.

The field that matters here is the sending domain itself, not just the IP. If an external domain is using your brand name in the From header, the aggregate report will show that domain appearing as a source of mail for your organization. You may see sending IPs you do not recognize, domains you have never authorized, and mail volumes you cannot explain.

DMARCFlow processes these aggregate reports and surfaces exactly which external domains are sending as your organization. This is the earliest possible signal of an impersonation issue, before your employees receive the phishing messages.

Without a tool that parses and organizes these reports, the data exists but remains unreadable. Most organizations that generate DMARC reports never actually analyze them. A single external sender using your domain can go undetected for weeks.

How to Detect and Stop Unauthorized External Domain Sending

Step 1: Review your DMARC aggregate reports regularly. Look for sending domains in the From header that are not your primary domain and not any authorized third-party sender. Any unexpected domain is a signal worth investigating.

Step 2: Check whether each unexpected domain corresponds to a legitimate email service provider you use. Marketing automation platforms, support ticketing systems, and CRM tools often send mail on your behalf. These should be authorized through your SPF record or by configuring DKIM signing from their infrastructure.

Step 3: For any external domain that is not a known vendor, assess whether it represents a brand impersonation attempt. Look at the sending volume, the target recipients, and whether the mail is being sent to internal addresses or scraped from your public contact list.

Step 4: Raise your DMARC policy to p=quarantine for domains that fail alignment. This tells receivers to treat suspicious mail as potentially hostile. Before doing this, make sure all legitimate sending sources are properly authorized, or you risk quarantining real email.

Step 5: Set up ongoing monitoring so new external domain senders trigger an alert. Attackers do not announce themselves. You need automated visibility. DMARCFlow automates this by parsing your aggregate reports and sending an alert whenever a new external domain appears as a sender for your domain.

Frequently Asked Questions

Q: Is it a security risk if any external domain can email my organization?

Yes. The risk depends on whether the external domain is using your brand identity in a way that deceives your employees or customers. Even if no malicious content is present, the ability to send as your domain without authentication is a gap that BEC actors exploit.

Q: How do attackers use external domains for email impersonation?

Attackers set up external mail servers and send messages with your domain in the From header. Because SPF and DKIM can pass without your domain being authorized to send from that server, the messages arrive normally. The attack works without any compromise of your own infrastructure.

Q: How can I detect external domains sending as my organization?

DMARC aggregate reports are the primary detection method. They show every sending domain that appears in mail claiming to be from your organization. Without these reports, you have no systematic way to see who is using your domain in email.

Q: What does DMARC have to do with external domain impersonation?

DMARC alignment is the only built-in email authentication mechanism that requires the From domain to match the authenticated sending domain. SPF and DKIM alone do not enforce this. A properly configured DMARC policy forces receivers to reject or quarantine mail where the From domain does not align with the authenticated domain.

Q: How do I fix unauthorized external domain sending?

Authorize legitimate senders through SPF or DKIM. Raise your DMARC policy to enforce alignment. Monitor aggregate reports for any new unauthorized domains. DMARCFlow automates the report parsing and alerts you when new external domains appear as senders for your domain.

How DMARCFlow Helps Surface External Domain Sending Risks

DMARCFlow parses DMARC aggregate reports and flags external domains that are sending as your organization. Rather than reading raw XML reports, you get a structured view of which domains are using your brand in email, which ones are passing authentication, and which ones are new.

This visibility is the prerequisite for closing the gap. You cannot fix what you cannot see. DMARCFlow gives you the continuous monitoring layer that most organizations lack, so new external domain senders do not go unnoticed until after a BEC incident.

If you are already generating DMARC reports, the missing piece is the parsing and alerting. That is what DMARCFlow handles.