How to detect when your domain is being used to send spoofed email and whether it reached anyone
Two types of domain spoofing. Only one uses your actual domain.
Most articles about domain spoofing are about lookalike domains attackers registering paypa1.com instead of paypal.com, or infraova-support.com instead of infraova.com. These are real threats, but they require the attacker to register a different domain.
There is a second type of domain spoofing that requires nothing except an email client and your actual domain name in the From field.
It looks like this:
From: support@yourdomain.com
The attacker did not register a lookalike domain. They did not compromise your mail server. They wrote your domain in the From field and sent the email. The recipient sees your domain your actual domain in the From address. It looks exactly like it came from you.
This is exact-match domain spoofing. And it is the type of spoofing that DMARC is designed to stop.
Whether it is stopped depends entirely on your DMARC policy. Whether you know it is happening depends entirely on whether you are reading your DMARC aggregate reports.
How exact-match domain spoofing works
When a mail server receives an email, it performs a series of authentication checks:
SPF check: Does the sending server's IP address appear in the domain's SPF record? If yes, SPF passes. If no, SPF fails.
DKIM check: Does the email carry a valid DKIM signature from the domain? If yes, DKIM passes. If no, DKIM fails.
DMARC evaluation: Given the SPF and DKIM results, what should the receiving server do? The answer comes from the domain's DMARC record.
An attacker sending email from a server they control, using your domain in the From field, will fail SPF and DKIM. Their server is not in your SPF record. They cannot produce a valid DKIM signature for your domain.
But here is where DMARC policy matters:
If your DMARC policy is p=none: The receiving server evaluates the failed authentication, records it in the DMARC aggregate report, and delivers the email anyway. Your DMARC record explicitly instructs receiving servers to take no action on authentication failures. The spoofed email reaches the recipient.
If your DMARC policy is p=quarantine: The receiving server sends the failing email to the spam or junk folder. The spoofed email does not reach the inbox, but it does reach the recipient's mailbox.
If your DMARC policy is p=reject: The receiving server refuses to accept the email at the SMTP layer. The spoofed email never reaches the recipient. It is stopped before delivery.
The attacker's capability is the same in all three cases. What changes is whether your DMARC policy gives receiving servers the instruction to stop it.
Why spoofing is invisible without aggregate reports
An attacker sending spoofed email from your domain does not interact with your infrastructure in any way. They do not log into your mail server. They do not modify your DNS records. They do not send through any system you control.
The only record that a spoofing attempt occurred exists in the DMARC aggregate reports sent by the receiving mail servers Gmail, Yahoo, Microsoft, and others to the reporting address in your DMARC record.
Those aggregate reports contain, for every email evaluated against your DMARC policy:
- The sending server's IP address
- Whether SPF passed or failed
- Whether DKIM passed or failed
- What the DMARC disposition was (none, quarantine, or reject)
- How many messages were evaluated
When an attacker sends 500 spoofed emails from a server in an unrelated data center using your domain in the From field, those 500 emails appear in the aggregate reports sent back to your rua= address. Each one shows an IP address you do not recognize, SPF failure, DKIM failure, and whatever disposition your DMARC policy instructed.
If your domain has no rua= address configured, those reports go nowhere. The spoofing happened. You have no record of it. You find out when a client, partner, or customer tells you they received a suspicious email from your domain or when the damage is already done.
If your domain has a rua= address but nobody is reading the reports, the situation is functionally identical. The data exists. The insight doesn't.
What Infraova detects and surfaces
Infraova monitors DMARC aggregate reports for every domain under management and detects unauthorized senders IP addresses sending email using a domain without passing SPF or DKIM authentication.
When a spoofing attempt is detected, Infraova surfaces:
Source IP address: The exact IP address the spoofed email was sent from, along with its reverse DNS hostname. This identifies whose infrastructure the attacker was using a cloud provider, a VPS host, or a known spam network.
Message count: How many emails were sent from this unauthorized source during the reporting period. One message could be a test or a misconfigured sending tool. Five hundred messages is an active spoofing campaign.
Current DMARC policy: What policy is in effect for the domain at the time of the detection p=none, p=quarantine, or p=reject.
Whether the policy blocked it: This is the most operationally important piece of information. Infraova tells the team directly: did these spoofed emails reach recipients, or were they stopped?
- Policy blocking: Yes The domain's DMARC policy is quarantining or rejecting the spoofed messages. Recipients are protected. The attack is being stopped.
- Policy blocking: No The domain is at
p=none. The spoofed messages were delivered to recipients. The attack succeeded.
These are two fundamentally different situations requiring different responses. Infraova surfaces which one the team is dealing with.
The two scenarios when spoofing is detected
Scenario 1: Policy blocking Yes
The domain has p=quarantine or p=reject. The spoofed emails are being quarantined or rejected. Recipients are protected from the current campaign.
The team still needs to know this is happening. Even with policy blocking active, a spoofing campaign targeting a client domain is a security event worth documenting. The team knows about it before the client does. They can investigate the source IP, assess the scale, and make an informed decision about whether to notify the client.
Inside Infraova, the team can send a spoofing incident report directly to the client's contact email showing the source IP with reverse DNS, the message count, the DMARC policy, and confirmation that the policy is blocking the messages. The client receives a professional security notification. They learn about the spoofing attempt from their agency, not from a confused customer who received a suspicious email.
That is the difference between operating proactively and reacting after the fact.
Scenario 2: Policy blocking No
The domain has p=none. The spoofed emails were delivered to recipients. The attack succeeded.
This is the scenario where the damage is happening in real time. Recipients are receiving emails that appear to come from the client domain phishing attempts, BEC attacks, credential harvesting campaigns and the client's DMARC policy is instructing receiving servers to deliver them anyway.
The team now has two immediate priorities:
Notify the client: The client needs to know their domain is being used to attack people. Their customers, partners, and suppliers may have received spoofed emails. The client needs to issue warnings to their contacts and take steps to investigate the scope of the campaign.
Move the DMARC policy: The domain needs to progress from p=none to at least p=quarantine as quickly as the evidence supports. Every day the policy stays at p=none is another day the attacker can send spoofed email that reaches recipients.
Infraova surfaces both the detection and the current DMARC policy state. The team can see immediately that the domain is at p=none, understand that the spoofed messages are reaching recipients, and initiate the policy progression workflow through Infraova creating a proposal to move to p=quarantine, getting approval, executing the change, and verifying the live record.
Why the reverse DNS matters
When Infraova detects a spoofing attempt, it surfaces the source IP address alongside its reverse DNS hostname.
The reverse DNS hostname often reveals whose infrastructure the attacker is using:
ec2-13-37-195-136.eu-west-3.compute.amazonaws.comAWS EC2 instance in Europemail.spamnetwork.rua known spam infrastructure operatorshared-hosting-provider.coma compromised shared hosting account
This context helps the team assess the nature of the attack. An EC2 instance suggests a sophisticated attacker with cloud infrastructure. A known spam network suggests a commodity phishing campaign. A shared hosting provider suggests a compromised account that may be worth reporting.
The reverse DNS is also useful for the client notification. Instead of telling the client "someone spoofed your domain," the team can say "we detected 500 spoofed emails sent from an AWS server in Europe. Your DMARC policy is currently allowing these through. We recommend moving to p=quarantine immediately."
That specificity changes the client relationship. The team is not just alerting the client to a problem. They are demonstrating operational intelligence knowing where the attack came from, how many messages were sent, and whether recipients were protected.
The connection between spoofing detection and DMARC policy
Every spoofing detection in Infraova carries a direct implication about the domain's DMARC policy state.
Detection + policy blocking: Yes means the domain has already progressed past p=none. The authentication infrastructure is working. The attack is being stopped. The team's job is awareness, documentation, and client notification.
Detection + policy blocking: No means the domain is at p=none and the attack is succeeding. The team's job is immediate policy progression alongside client notification.
This is why DMARC policy progression is not an abstract security improvement. It is the difference between a spoofing detection that says "we stopped it" and one that says "they got through."
Infraova handles both sides of this operationally:
On the detection side: monitoring aggregate reports, identifying unauthorized senders, surfacing the source IP with reverse DNS, counting message volume, and determining whether the current policy is blocking the attack.
On the remediation side: proposing DMARC policy progression when the evidence supports it, waiting for human approval, executing the approved change through the connected DNS provider, and verifying the live record to confirm the policy is now in effect.
The two capabilities are part of the same operational loop. Detection without remediation leaves the team informed but the domain unprotected. Remediation without detection leaves the team fixing problems they didn't know existed. Together, they give the team the full picture and the tools to act on it.
What agencies owe their clients on this
For an agency managing email infrastructure across multiple client domains, spoofing detection is an operational responsibility, not a nice-to-have.
A client whose domain is being used to send phishing emails to their customers has a real security problem. If the agency discovers this before the client does, the agency has an opportunity to demonstrate exactly what they are paid to do operate the client's infrastructure proactively, catch problems before the client notices, and handle the response with professionalism.
If the client discovers it first because a customer called confused about a suspicious email, or because a partner flagged a phishing message the agency's position is inverted. They are explaining why they didn't know. They are reacting to a client complaint instead of managing a security event.
Infraova gives agencies both the detection and the client notification tool in one workflow. The detection happens automatically through aggregate report monitoring. When a spoofing event is detected, the team reviews it in Infraova and can send a professional incident report directly to the client's contact email showing the source IP, the message count, the DMARC policy status, and the recommended action.
The client receives a security notification from their agency before they find out any other way. That is what proactive infrastructure management looks like in practice.
What to check right now
For every client domain in a portfolio:
Does the domain have a DMARC record with a rua= address?
If not, spoofing attempts are completely invisible. No aggregate reports are being received. No detection is possible.
Is anyone reading the aggregate reports?
If the rua= address exists but nobody is processing the reports, the detection capability is theoretical. The data exists but the insight doesn't.
What is the current DMARC policy?
If any domain is at p=none, spoofed emails from that domain are reaching recipients right now whenever an attacker chooses to send them. There is no enforcement in place.
Has a spoofing attempt already occurred?
The aggregate reports for any domain with a rua= address contain a complete history of authentication results, including any unauthorized senders. If a spoofing campaign has happened, it is in those reports.
Infraova answers all four of these questions automatically for every domain under management monitoring aggregate reports continuously, surfacing unauthorized senders when they appear, identifying whether the current policy is blocking them, and providing the workflow to notify the client and progress the policy when it isn't.
The spoofing may already be happening. The question is whether the team knows about it before the client does.
Infraova is an email infrastructure operations platform for agencies, MSPs, deliverability consultants, and businesses managing email at scale. Infraova monitors DMARC aggregate reports for every domain under management and surfaces spoofing detections with source IP, reverse DNS, message count, and policy blocking status automatically. Start operating your infrastructure →