I keep receiving DMARC email reports despite not sending any emails

[ctrlbrk]

For the past few days my domain has been receiving DMARC reports even though it has not sent any emails out.

My understanding of DMARC is that the various mail providers for thei recipients send you daily summary reports for any activity that has taken place for the previous day.

Example of my expectations:

Yesterday

• 2 emails sent to @google.com addresses
• 1 email sent to @comcast.net address

Today

• DMARC summary report from [email protected]
• DMARC summary report from [email protected]

But yesterday there were no outgoing emails from my domain, and yet those 2 providers sent me reports anyway. The reports' timestamps are indeed for yesterday.

Question: Is it possible these reports are generated because my email provider is attempting "retry" activity from my domain over past emails that may have not reached recipients?

Thanks

 

[ukwebhosting]

Hi,

It could be email it could not deliver from a few days before, however DMARC reports will send you a report of all mail to them pass or fail DMARC so you should investigate the reports it has sent to you.

They can be a bit of a pain to read, as there are only 2 I would be happy to look at them and decipher them for you.

Essentially if you have DMARC reports on then you should be deciphering them anyway to make an informed choice about your DMARC policy.

If all good mail passes DMARC and is delivered fine and bad is not over say a month the you can increase your p= in your policy to quarantine or reject

However if good mail is failing DMARC then rectify the issue be that with SPF or DKIM or whatever then repeat above until no good mail fails and all bad does then you can tighten your policy.

 

[ctrlbrk]

Thanks @ukwebhosting - all the reports I checked so far are a pass, so I'm not concerned about that, but you seem to be confirming that the ones received (against no mail sent) are possibly reflecting retry attempts.

 

[ukwebhosting]

Thanks @ukwebhosting - all the reports I checked so far are a pass, so I'm not concerned about that, but you seem to be confirming that the ones received (against no mail sent) are possibly reflecting retry attempts.

Hi,

Potentially, but there are a few things they could be.

To track it down properly if you recognise the IP in the report they were sent from you could check the logs there if you have access to them.

Just a lot of variables to say it is definitely retries, it could be any number of other things for example a website that sends emails in response to any number of things like failed logins, logins

Sorry so many to list!

If you have access to the sending email server then your answer should be in the mail mailserver logs.

 

[ctrlbrk]

To track it down properly if you recognise the IP in the report they were sent from you could check the logs there if you have access to them.

Yes, the IP is always the one from my email provider (Zoho), so I don't have direct access to them unfortunately.

Just a lot of variables to say it is definitely retries, it could be any number of other things for example a website that sends emails in response to any number of things like failed logins, logins

Yes but these would be emails sent by my domain, which means I would see them going out.

At the moment I only send transactional emails (register confirmation, password reset, etc.), and none of these have taken place in the last few days.

 

[ukwebhosting]

Hi,

Thanks for the info, as you can see the IP is Zoho the quickest route to an answer would be just to ask them as I would think they are the only people with the access to give you a definitive answer.

 

[Russ Michaels]

Do you have proper dmarc reporting setup or are you just getting the raw files emailed to you?
If the emails were not sent by you are angry of your legit sources, then they are spoof attempts, which the reports will show you.
Do you have your dmarc policy set to reject unauthentic mail?

 

[NickZ]

most are a zip file, if you run windows, you could be in for a surprise.

 

[fisicx]

most are a zip file, if you run windows, you could be in for a surprise.

Please read the opening post again. It has nothing to do with phishing.

 

[UKSBD]

I get one of these every day on one of my emails

it's just an xml file

<feedback>
<version>1.0</version>
<report_metadata>
<org_name>google.com</org_name>
<email>[email protected]</email> <extra_contact_info>https://support.google.com/a/answer/2466580</extra_contact_info>
<report_id>7356072248051310740</report_id>
<date_range>
<begin>1741392000</begin>
<end>1741478399</end>
</date_range>
</report_metadata>
<policy_published>
<domain>mydomain.uk</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>quarantine</p>
<sp>none</sp>
<pct>100</pct>
<np>none</np>
</policy_published>
<record>
<row>
<source_ip>23.83.223.170</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>mydomain.uk</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>mydomain.uk</domain>
<result>pass</result>
<selector>default</selector>
</dkim>
<spf>
<domain>mydomain.uk</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
</feedback>

 

[Russ Michaels]

I get one of these every day on one of my emails

it's just an xml file

<feedback>
<version>1.0</version>
<report_metadata>
<org_name>google.com</org_name>
<email>[email protected]</email> <extra_contact_info>https://support.google.com/a/answer/2466580</extra_contact_info>
<report_id>7356072248051310740</report_id>
<date_range>
<begin>1741392000</begin>
<end>1741478399</end>
</date_range>
</report_metadata>
<policy_published>
<domain>mydomain.uk</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>quarantine</p>
<sp>none</sp>
<pct>100</pct>
<np>none</np>
</policy_published>
<record>
<row>
<source_ip>23.83.223.170</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>mydomain.uk</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>mydomain.uk</domain>
<result>pass</result>
<selector>default</selector>
</dkim>
<spf>
<domain>mydomain.uk</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
</feedback>

These Are not meant to be human readable, they are meant to be processed by a reporting solution.
If you getting the XML files sent to directly and ignoring them, then you are defeating the point in having dmarc as you won't even know if there's any issues.

See my reply above for more details.

 

[MarcTX]

Great discussion here. A few clarifications that might help:

Why you receive DMARC reports when you didn't send mail

DMARC aggregate reports aren't triggered by your sending activity. They're triggered by any email
that arrives at a recipient's mail server claiming your domain in the From: header. This includes:

• Spoofing attempts: Someone trying to impersonate your domain
• Forwarded mail: A recipient forwarding your old email (breaks SPF alignment)
• Mailing lists: Similar alignment issues
• Delayed delivery/retries: Queued mail from days prior

A word of caution though: If you haven't sent any mail for several days and you're still receiving reports, I'd investigate more closely. This pattern often indicates someone is actively spoofing your domain (sending mail pretending to be you). The reports will reveal this: look for unfamiliar source IPs, or SPF/DKIM failures.

If that's the case, the fix is straightforward: tighten your policy to p=reject. This tells receiving servers to outright refuse emails that fail authentication, effectively killing spoofed mail. You're currently at p=quarantine which is good, but reject is the end goal. Might be something to investigate.

Russ is right that these XML files are designed for machine processing. The key fields to eyeball quickly are:

• <source_ip>: Is this your authorized sender? Check if this IP belongs to your ISP or SMTP server
• <count>: Volume of messages
• <dkim> and <spf> under <policy_evaluated>

One thing I noticed in your policy: <sp>none</sp> means your subdomains aren't protected at all. Worth tightening to sp=reject to prevent attackers from spoofing mydomain.uk.

If you'd like, I can run a quick check on your domain's current DMARC/SPF/DKIM setup at dmarctrust.com/domains, happy to share findings here.