The weekly XML, or the parsed view of it, shows an IP you do not recognize. The dangerous move is to treat that row as an attack and publish p=reject before you know whether the IP is the shipping-mail vendor finance signed up for in March.
Of the four patterns in the table below, only one points to someone else using your domain. The table is a triage guide, not a verdict: a row can match a pattern and still need the IP owner checked before you act.
Last verified: 26 September 2026, against RFC 9989 and the bulk-sender pages at Gmail and Yahoo, which still accept p=none.
What the report is showing
DMARC aggregate reports list sources that attempted to use your domain. The current policy standard is RFC 9989. The report format itself is specified alongside it (aggregate reports in RFC 9990). You do not need to read the XML by hand if a tool has parsed it. You do need the same fields: source IP, message count, SPF alignment, DKIM alignment, and the domains those checks used.
How to read reports for alignment walks through a passing and a failing signature. This page starts when the source is not one you meant to operate. What DMARC is is the policy primer. DMARC in 2026 is what RFC 9989 changed, including why p=reject is not a switch you flip because a row looks wrong.
Four unknown-sender patterns in DMARC reports
| Pattern in the report | Likely situation | What you do |
|---|---|---|
| DKIM passes, but on a vendor’s domain, so alignment fails | A tool is sending with your From address and its own signature | Authorize it with aligned DKIM, or stop it using your From domain |
| SPF fails, DKIM passes and aligns | Forwarding or a path where the envelope changed and the signature held | Confirm it is your mail. Do not delete DKIM to “clean up” SPF. |
| SPF fails and DKIM fails, steady volume, network you do not use | Consistent with someone else using the domain | Keep monitoring, alert on it, and move policy only after every real source aligns |
| A single failure from a mailbox provider’s IP | Often forwarding residue | Watch. Do not rebuild DNS for one message. |
InboxEagle’s DMARC monitoring checks your DMARC policy record every 24 hours and alerts on change. It does not read aggregate reports. Ingesting and processing them at volume is a separate paid product, DMARC Processing, which does not need an Email Deliverability subscription. Neither decides which vendor is legitimate. Someone who knows the stack still has to match the IP to a contract.
What not to do the day an unknown sender appears
Do not set p=reject or even p=quarantine solely because a row is unfamiliar. Gmail and Yahoo, as of this writing, still treat p=none as a valid published policy for bulk senders. Enforcement is how you ask receivers to reject or junk failures. If the failure is your order tool, you throw away receipts. The order confirmation failures that come from a vendor domain are this row, seen from the customer’s side.
Do not flatten the entire SPF record in a panic. If the new source is real, it needs an include or an aligned DKIM key, and the 10-lookup limit is how a hasty include takes SPF down for everyone else.
Do not ignore a source that sends every day and fails both checks. That is the case for moving toward enforcement after the known vendors are aligned, not instead of aligning them. No DMARC record is the setup if you are not receiving reports yet. You cannot investigate a source you are not collecting.
InboxEagle
Confirm what your DMARC record asks for
The free DMARC checker shows your published policy and report address, so you know where the next unknown source will show up. Match each source to a contract before you change the policy.
Sources
- DMARC, RFC 9989. Policy evaluation. Aggregate report format is in RFC 9990.
- Email sender guidelines, Google. A DMARC record of at least
p=nonefor bulk senders. - Sender best practices, Yahoo. DMARC at
p=noneor stronger for bulk senders, and DMARC must pass.