How to identify and handle spoofed emails violating DMARC policies?
Updated on 23 Oct 2026: We clarified how to distinguish spoofing from legitimate DMARC failures and interpret receiver handling and reporting limits.
To identify and handle spoofed emails violating DMARC policies, start with your DMARC aggregate reports. They show the source IP, message counts, SPF and DKIM results, domain alignment results, Author Domain, reporting receiver, disposition, and available policy override reasons. Use these results to prioritize investigation, then check your sender inventory and message-level evidence before classifying a source as spoofing.
Find the failing source in DMARC reporting, check whether it is a legitimate sender or forwarder, and confirm that neither SPF nor DKIM passes with the required match to the From domain. Then fix legitimate mail or handle confirmed spoofing as abuse. If your domain already has p=reject, investigate receiver handling and any policy overrides while checking that legitimate mail still passes. Keep support and security informed about confirmed spoofing.
Do not treat every spike as a breach. A sudden jump in DMARC failures often means your domain was chosen for a phishing, spam, or business email compromise (BEC) spoofing campaign. It can also mean a new sending platform, a forgotten system, an email forwarder, or a penetration test is using the domain without proper authentication. The work is to prove which one it is.
What a DMARC violation tells you
A DMARC failure means the message used your domain in the visible From address without a passing authentication result that meets DMARC identifier alignment. DMARC does not require both SPF and DKIM to pass. At least one mechanism must pass authentication with a domain that matches the Author Domain in the RFC5322.From header under the selected alignment mode. Relaxed alignment compares organizational domains, while strict alignment requires an exact domain match. The message fails DMARC if neither mechanism meets both requirements, even when your policy is p=none.
- Visible domain: The domain in the From header is the domain DMARC protects because that is what recipients see.
- SPF alignment: SPF must pass for the SMTP MAIL FROM domain, usually shown in Return-Path, and that domain must match the visible From domain under the selected alignment mode.
- DKIM alignment: At least one DKIM signature must pass with a signing domain (d=) that matches the visible From domain under the selected alignment mode.
- Policy result: The record requests none, quarantine, or reject handling. The receiver makes the final delivery decision using its own policy and other evidence.
The first question to answer
Ask whether the failed source is yours or is forwarding legitimate mail. Confirm the business owner and sending configuration before fixing a recognized service. An unknown IP, shared provider network, or unfamiliar country is an investigation lead, not proof of spoofing. Check message samples and forwarding routes before classifying the traffic.
A DMARC pass is not a safety verdict. It means the message has a passing authenticated identifier with the required domain match to the Author Domain. A message can still be fraudulent if an approved sender, mailbox, API key, or template has been abused.
Suped's DMARC monitoring groups aggregate reports by sending source and authentication result, helping your team compare failures with approved senders without manually reading XML.
Four-part DMARC violation diagram showing From domain, SPF domain match, DKIM domain match, and policy action.
Why suspicious mail passes DMARC or gets delivered
A message can look spoofed to a user and still pass DMARC if the visible domain is not actually yours or an approved sender or account was abused. A receiver can also deliver a DMARC-failing message after evaluating a trusted Authenticated Received Chain (ARC); this does not change the current DMARC failure into a pass. DMARC validates use of the Author Domain. It does not validate the sender's intent, display name, logo, invoice request, or password-reset story.
- Display-name spoofing: The display name says your brand, but the From domain belongs to someone else. DMARC for your domain is not evaluated.
- Lookalike domain: Read the entire From domain. An unrelated domain with your brand name embedded in it authenticates under its own domain. Handle that as brand abuse; actual subdomains of your domain remain subject to DMARC policy discovery.
- Approved source abuse: Mail from a real sender or compromised account can pass alignment. Investigate account logs, API keys, templates, and recent vendor changes.
- Replay or forwarding: A valid DKIM signature can survive replay or forwarding in some cases. Compare headers, timestamps, and volume patterns before changing policy.
For these cases, preserve full headers and message samples. Aggregate reports show the traffic shape, but message-level evidence is needed to distinguish DMARC failure from authenticated abuse.
How to verify one suspicious message
Start with the original message and its complete headers, ideally saved as an .eml file or forwarded as an attachment. A screenshot, copied body, or message forwarded as ordinary inline content omits or changes the evidence needed to verify the receiver's DMARC decision.
- Find the trusted result: Locate the Authentication-Results header added by the receiving system you trust. Ignore untrusted copies inserted before that boundary.
- Compare identifiers: Compare header.from with smtp.mailfrom for SPF and header.d for each passing DKIM signature. At least one passing identifier must be in alignment.
- Trace the route: Start with the newest Received header added by your trusted receiver and work toward earlier hops only while the route is verifiable. Treat headers below the trusted boundary as unverified claims.
- Inspect ARC: Check the ARC chain and the receiver's override result. ARC preserves prior authentication evidence, but an ARC pass is not a safety verdict.
- Correlate the message: Compare the last-hop source IP, From domain, and authentication results with the matching aggregate report period. A matching group supports correlation but does not identify an individual message or its exact sending time.
Illustrative header fields to collect, signatures abbreviatedtext
Authentication-Results: mx.receiver.example; spf=fail; dkim=fail; dmarc=fail header.from=example.com From: Billing <billing@example.com> Return-Path: <bounce@sender.example> DKIM-Signature: v=1; d=sender.example; s=selector1; ... ARC-Seal: i=1; d=forwarder.example; cv=none; ...
Trust the receiving boundary
A sender can insert a fake Authentication-Results header. Use the result written by your receiving system or another verified hop, then trace earlier headers from that trusted boundary.
What DMARC reports cannot tell you
Aggregate reports (RUA) usually cover a UTC day and arrive after that period. Use the report date_range rather than its arrival time when comparing a spike with DNS changes. They are not a live incident feed. RFC 9990 defines aggregate reporting.
- Coverage is incomplete. Reports describe traffic observed by reporting receivers; silence does not prove that spoofing stopped.
- Counts are grouped observations. They are not a list of unique messages or recipients, and forwarding can cause related traffic to appear at different receivers.
- Disposition describes DMARC handling, not inbox placement. A none result does not prove inbox delivery; check the authentication results and override reasons together.
- RUA does not include message bodies or a rejected-message archive. Obtain original samples and receiving logs for message-level investigation.
Failure reports (RUF), sometimes called forensic reports, can include message headers or content, but many large receivers restrict or disable them. Request them only for a defined diagnostic need with appropriate handling of personal data, and do not depend on them to recover every rejected message. RFC 9991 explains these reporting limits.
How to identify a sending source
The sender identity in DMARC is not a person. It is usually an IP address, an authenticated source, or a provider network. You can often identify the operator of the sending infrastructure, but you usually cannot identify the individual actor behind a spoofing run from DMARC alone.
Use this sequence when a domain shows a sudden increase in failures. In XML, auth_results contains raw SPF and DKIM outcomes; policy_evaluated shows the results used for DMARC, including domain alignment.
- Group by source IP: Sort DMARC failures by volume and receiver so the largest source is handled first.
- Resolve ownership: Use regional registry RDAP data or WHOIS to identify the network owner and abuse contact.
- Check reverse DNS: Use reverse DNS as a clue to infrastructure ownership, then verify it against registry data and your sender inventory. A hostname alone does not establish authorization or compromise.
- Compare senders: Match the source against your approved sending inventory before calling it malicious.
- Review samples: Use forensic evidence, mail logs, user reports, or seed inboxes when available, but do not rely on aggregate reports for message body content.
WHOIS and DNS checks for a failing IPbash
whois 203.0.113.25 host 203.0.113.25 dig -x 203.0.113.25 +short
The owner shown by an IP lookup is not always the sender. It can be a hosting provider, infected customer server, VPN service, or shared outbound relay. In forwarded mail, the reported source IP is the last-hop relay seen by the receiver. For a large spoofing run, capture the top IPs, UTC reporting windows, volume, reporting organizations, and DMARC failure evidence. Use message samples or receiving logs for exact timestamps and recipients.
Likely legitimate source
- Recognized platform: The source matches an approved service and its owner confirms the workflow. Shared IP ownership alone is insufficient.
- Consistent pattern: Failures appear at expected campaign times or workflow triggers.
- Fix path: Add DKIM, update SPF, change the return-path, or configure a custom sending domain.
Likely spoofing source
- Unknown network: The IPs have no confirmed connection to your approved senders or legitimate forwarding routes.
- Wide spread: Traffic appears across unrelated networks, and message samples or logs confirm unauthorized use of your domain.
- Response path: Preserve evidence, notify internal teams, and report abuse where volume justifies it.
What to check in your DMARC record
Before escalating a spoofing spike, check the applicable DMARC record for the exact From domain and its inherited policy. p=none requests no DMARC enforcement; a missing reporting address affects visibility, not enforcement. Check for duplicate DMARC records and test mode, and inspect any explicit subdomain policy rather than assuming the parent policy always applies.
Example reject policy after legitimate sender verificationdns
_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc-reports@example.com"
|
|
|
|---|---|---|
p | reject after sender verification | Requests rejection of DMARC failures; the receiver makes the final decision. |
sp | reject or inherited p policy | Applies to subdomains without their own applicable policy; inspect explicit subdomain records. |
np | reject or inherited sp/p policy | Requests handling for non-existent subdomains; omission does not automatically leave them unprotected. |
rua | valid, reachable reporting destination | Requests aggregate reports. External destinations need reporting authorization. |
t | absent or n for enforcement | Under RFC 9989, t=y requests handling one level below quarantine or reject. |
adkim | r by default; s if required | Relaxed DKIM alignment is the default. Strict alignment requires an exact domain match. |
aspf | r by default; s if required | Relaxed SPF alignment is the default. Strict alignment requires an exact domain match. |
Fields to check when spoofed mail fails DMARC
RFC 9989 is the current DMARC specification. The older pct tag is historic. t=y requests quarantine handling for a reject policy and no DMARC enforcement for a quarantine policy. An absent t defaults to t=n. Do not depend on percentage rollout or assume every receiver supports the newer tags. Verify actual report results after each policy change. The example leaves adkim and aspf at their relaxed defaults; strict matching is a separate configuration choice.
If reports go to an external domain, confirm that destination authorizes reports for your domain and accepts the report mail. For subdomains, sp falls back to p, while np falls back to sp and then p. Check the effective policy for the exact From domain before changing DNS.
If you are unsure whether the record is valid, run it through a DMARC checker before changing policy. Syntax mistakes during an incident can create new deliverability problems.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
How to handle confirmed spoofing
Once a source is confirmed as spoofing, the response depends on your policy. If you are at p=none, the immediate goal is to move toward enforcement after verifying legitimate senders. If you are at p=quarantine, assess legitimate mail and forwarding before deciding whether reject is appropriate. If you are already at p=reject, the technical control is already in place, so the next work is monitoring and response.
DMARC response stages
Use policy state to decide what action matters during a spoofing spike.
Observe
p=none
Collect reports and identify every legitimate sender.
Contain
p=quarantine
Request spam or quarantine handling and review legitimate failures.
Enforce
p=reject
Request rejection of failures and review receiver overrides and legitimate mail.
For a confirmed malicious run, take these actions:
- Preserve evidence: Save report ranges, source IPs, volumes, receiver names, and timestamps before the data rolls off.
- Notify support: Warn customer-facing teams that users might report suspicious mail that appears to use your domain.
- Notify security: Correlate the spike with login attempts, help desk impersonation, invoice fraud, and brand abuse reports.
- Report abuse: Send concise evidence to the network owner when a small number of IPs drive meaningful volume.
- Keep monitoring: Spoofing campaigns often move networks, domains, and timing once rejection starts to bite.
Reject does not stop attempts
A reject policy requests rejection of mail that fails DMARC. Receivers use local policy and other evidence in their final decision. It does not prevent forged sending attempts. Seeing failures after moving to reject is normal; review the reported dispositions and override reasons alongside legitimate-mail failures.
If the spoofing campaign reaches customers or imitates a breach notice, invoice, password reset, or support message, prepare a plain user-facing warning through channels you control. Keep it factual, avoid attachments and unnecessary links, tell users what the company will not ask for by email, and coordinate legal, security, and support before sending broad notifications.
DMARC policy is one input to the receiving system's handling decision. Local policy or a trusted ARC chain can justify accepting a failing message without changing its DMARC result. Review override reasons and receiving logs before treating delivery as a policy violation. For forwarding cases, see inbound DMARC handling.
How Suped helps during a spoofing spike
Suped's product supports investigation during a spoofing spike: group failing sources, compare their authentication results with approved senders, and review reported receiver handling before changing policy. Use these reports alongside message samples and your sender inventory.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
Use the source and issue views to review an unverified sender and investigate its failures. Confirm whether a business system was launched without DKIM or a custom return-path before treating the source as an attacker.
Questions to resolve
- Ownership: Does the source belong to an approved service or a forwarding route?
- Authentication: Which passing identifier, if any, matches the visible From domain?
- Receiver handling: What disposition and override reasons were reported?
Suped workflow
- Source view: Group failures by source and compare reporting periods.
- Issue review: Use authentication results to identify configuration work for the sender owner.
- Policy management: Use Hosted DMARC to manage policy after the initial DNS delegation.
Hosted DMARC is especially useful when several teams need policy changes but only one team owns DNS. Instead of editing TXT records for every stage, Suped can manage policy staging through Hosted DMARC after the required CNAME setup is in place.
When to fix authentication instead
Reporting your own mail as abuse delays the real fix. Legitimate mail can fail DMARC because of domain mismatches, missing or invalid authentication, forwarding, or message changes in transit. The fix depends on the actual failure.
|
|
|
|---|---|---|
SPF pass, DMARC fail | SPF domain mismatch with no passing DKIM domain match | Configure a custom bounce domain with SPF, or enable DKIM signing with the required domain match. |
DKIM fail | Missing or incorrect DNS key, or signed content changed | Verify the selector and key, then check for message modification in transit. |
No DKIM | Domain signing is not enabled | Enable DKIM with your domain and publish the required DNS records. |
SPF fail | Unauthorized sending IP or forwarding | Verify ownership and the route. Fix SPF only for approved direct senders; do not authorize arbitrary forwarders. |
SPF permerror | Too many DNS lookups or an invalid SPF record | Keep one SPF record and stay within the 10 DNS-lookup term limit, including nested includes. |
Subdomain fail | Wrong domain match or an unexpected inherited policy | Check the exact From domain, effective DMARC policy, and authenticated domains. A separate DMARC record is not always required. |
Direct mail passes, forwarded mail fails | Forwarding breaks SPF; message changes invalidate DKIM | Preserve DKIM where possible and investigate trusted ARC handling with the receiving administrator. |
Authentication fixes for legitimate sources
One passing mechanism with the required domain match is enough for DMARC, but configure both SPF and DKIM for legitimate senders. RFC 9989 requires domains at reject to sign with valid DKIM rather than relying solely on SPF. Test forwarding and mailing-list traffic before tightening policy.
A clean sender inventory makes this faster. Keep a list of every platform allowed to send as the domain, the department that owns it, the DKIM selector, the return-path domain, the expected volume, and the approval status. When a DMARC spike appears, this list prevents guesswork.
Best practice
Do not add every failing source to SPF during a spike. SPF is not a permission list for anything that claims your domain. Only add senders you own, trust, and have configured for alignment with your visible From domain.
If failures are coming from a sender you recognize but cannot explain, inspect the full authentication chain. A focused troubleshooting path is better than changing several DNS records at once. For a deeper breakdown, use DMARC failure troubleshooting to isolate domain alignment, forwarding, and record problems.
How to report and monitor abuse
Reporting abuse is worth doing when the evidence is concentrated. If 80 percent of the spoofed volume comes from one network, send that network a short abuse report. If the traffic is scattered across thousands of residential or compromised hosts, reporting every IP usually burns time without changing the outcome.
Abuse report evidence templatetext
Subject: Forged mail using example.com from 203.0.113.25 We are seeing unauthorised mail using example.com in the visible From header. Source IP: 203.0.113.25 Observed window (UTC): [report period start] to [report period end] Reporting organizations: [names from report metadata] Reported message count: [count for this source and reporting period] DMARC result: fail SPF alignment result: fail DKIM alignment result: fail Reported disposition and override reason: [values from report] Supporting evidence: [report identifiers; original headers if available] Requested action: investigate and stop abusive outbound mail.
Keep the report factual. Do not include sensitive customer content unless your legal or security process allows it. DMARC aggregate reports do not include message bodies, so the safest evidence package is usually metadata, timestamps, and authentication results.
Flowchart showing how to handle a DMARC spoofing spike by grouping sources, fixing known senders, reporting abuse, and monitoring policy.
Monitor the pass rate of approved senders separately from total DMARC failures, because a spoofing surge can inflate the failure percentage without changing legitimate mail. Also track reported dispositions, receiver coverage, and user complaints. Save original message attachments so authentication evidence survives investigation.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
What not to do during a spike
A spoofing spike makes people want to move fast, but the wrong DNS change can break legitimate mail. Avoid these moves unless there is clear evidence and a rollback plan.
- Do not loosen policy: Moving from reject to none because spoofing attempts exist removes the protection receivers are using.
- Do not overfill SPF: Adding unknown sources can authorize mail you do not control. SPF has a limit of 10 DNS-lookup terms during evaluation, including nested include records.
- Do not ignore subdomains: Attackers often try unused subdomains when the organizational domain is protected.
- Do not trust display names: DMARC protects the visible From domain, not every lookalike name or cousin domain.
- Do not skip users: Tell support and security what users might report, especially when the campaign targets customers.
A common false fix
Adding a suspicious IP to SPF because it appears in a DMARC report is backwards. A DMARC report shows who is using your domain, not who should be allowed to use it.
If suspicious mail passes SPF and DKIM, verify that at least one passing domain also meets DMARC alignment. For a true DMARC pass, investigate lookalike domains, replay, or approved sender abuse. For a delivered DMARC failure, investigate forwarding and receiver overrides. Recheck the trusted Authentication-Results boundary and sending logs before changing DNS.
Frequently asked questions
DMARC usually identifies the source IP, reporting receiver, authentication results, and sending volume. It does not usually identify the individual person behind the traffic. Use the IP owner, reverse DNS, logs, and abuse reports to build a practical investigation path.
A reject policy tells receivers what to do with mail that fails DMARC. It does not stop someone from attempting to send forged mail. Seeing failed attempts in reports means the domain is being used in attempts, not necessarily that those messages reached inboxes.
Contact network owners when the volume is concentrated and the evidence is specific. For scattered low-volume attempts across many networks, focus on DMARC enforcement, internal awareness, and monitoring trends.
Only change SPF for senders you own and approve. Do not add unknown failing sources to SPF. A source appearing in a DMARC report means it used your domain, not that it should be authorized.
Identify the cause before editing DNS. Configure DKIM with the required domain match, set a custom return-path where needed, and verify SPF for approved direct senders. If the mail was forwarded or modified, investigate that route rather than adding the forwarder to SPF.
Yes. Approved sender abuse or a replayed valid DKIM signature can produce a DMARC pass. An unrelated lookalike domain can also pass DMARC for its own domain. ARC-based acceptance is different: a receiver can accept mail whose current DMARC result is fail. Check trusted Authentication-Results headers and compare the message with sending logs.
