How many emails sent today?

Hi all,
I was wondering if there is a simple command or script to see how many emails are being sent out today for the domain in question or the whole server if possible. The DC wants to null route my server because one customer stopped with O365 and forget to adjust all DNS records. Any help much appreciated.

Interworx v6.11.3



There is not any kind of premade script or command or anything for that, no. All incoming/outgoing mail is in the logs in /var/log/send. You could probably use some creative grepping to maybe find that information from those logs. The one weird thing with the mail logs is that the timestamps are not human readable, so you would just need to make them so by piping tai64nlocal.

So, for example, this looks for all messages in /var/log/send/ folder that were sent either from, or to the domain, on the 13th (today)–this domain is a weird example, but I’m using a test server so there isn’t any actual mail going through it.

[root@jenna send]# cat /var/log/send/* | tai64nlocal | grep installtest.installtest| grep 2021-11-13
2021-11-13 03:32:02.843788500 info msg 18289740: bytes 806 from <root@installtest.installtest> qp 31727 uid 0
2021-11-13 03:32:02.854364500 starting delivery 2357: msg 18289740 to remote root@installtest.installtest
2021-11-13 03:32:02.912975500 info msg 19615761: bytes 778 from <root@installtest.installtest> qp 31737 uid 0
2021-11-13 03:32:02.923471500 starting delivery 2358: msg 19615761 to remote root@installtest.installtest
2021-11-13 03:32:02.940455500 starting delivery 2359: msg 18359787 to remote root@installtest.installtest
2021-11-13 03:32:02.960362500 starting delivery 2360: msg 18359788 to remote root@installtest.installtest
2021-11-13 05:26:35.628825500 info msg 18468914: bytes 46573 from <admin@installtest.installtest> qp 12171 uid 0
2021-11-13 05:26:35.645401500 starting delivery 2361: msg 18468914 to remote admin@installtest.installtest
2021-11-13 05:26:35.763835500 starting delivery 2362: msg 18468917 to remote admin@installtest.installtest
[root@jenna send]#

Can narrow that down to just messages from

[root@jenna send]# cat /var/log/send/* | tai64nlocal | grep installtest.installtest| grep 2021-11-13 | grep -v to
2021-11-13 03:32:02.843788500 info msg 18289740: bytes 806 from <root@installtest.installtest> qp 31727 uid 0
2021-11-13 03:32:02.912975500 info msg 19615761: bytes 778 from <root@installtest.installtest> qp 31737 uid 0
2021-11-13 05:26:35.628825500 info msg 18468914: bytes 46573 from <admin@installtest.installtest> qp 12171 uid 0
[root@jenna send]#

Or just give a count of the above:

[root@jenna send]# cat /var/log/send/* | tai64nlocal | grep installtest.installtest| grep 2021-11-13 | grep -v to | wc -l
[root@jenna send]#

Determining how many messages, period, are going out from all domains on the server within a given time may be a bit more difficult because less specific information to filter through, though. :frowning:

Hi Jenna @IWorx-Jenna
Thank you ever so much, your example was perfect. I can grep todays email for the domain in question.
That’s fantastic, stress was high, it just got me as the DC was saying there was excessively high volume from that domain.
Many thanks.


There are also some very old log analysis tools that have essentially been abandoned but still operate in some ways. They may work for a simple “get all emails sent by X for the last two days”, anything more than that may no longer function. Complete documentation can be found here: NodeWorx Email Guide — InterWorx documentation

This documentation is for InterWorx 6. The tools still exist in IW7, but as they haven’t been updated in years, we no longer really advertise them since we aren’t 100% sure of the state. They only read the logs, so they may be worth a shot.

Hi Brandon @iworx-brandon Many thanks, I still use the IW6 so that is fine, will have a read.
I used Jennas example and that domain had only sent 3 emails that day, just wonder will nullify the server IP really stop spammers spoofing that domain name with a wrong SPF record?


Sorry, it’s unclear what you mean by “nullify the server IP”. I’m not sure there is enough information about your situation to really be able to comment. If you want to add more information here, that’s fine, but you’re also welcome to do so in a support ticket if you’d like to keep that information private. We’ll try to get you the best information we can, but I think we need to understand the problem better before we can comment.



@iworx-brandon Nico is referring to the datacenter null routing his server IP.

In UK, it is normal for the datacenters to have measures in place to highlight and stop spam on their networks. We use Pulsant and this measure is the third level of protection of our IP CIDR

Many thanks


Hi John, @d2d4j @iworx-brandon
The domain on our server has sent 3 emails that day, the SPF record was not correct because customer was stopped using O365, so someone else was spoof spamming, once I got warning from DC/Spamcop I fixed it, but of course the DNS record needs propagating and DC was treating to nullify the server IP so all shared accounts would be effected. got email at 3:24 and fixed at 7:19. If this is common practice for my DC then perhaps time to find another DC?


@iworx-brandon @Nico just to bring this to a close

I spoke with Nico and now fully understand Nico issue and No, it is not common practice in this instance. The common practice would be if they could see spam email was been sent by their network (your IP) then a block on email port and warning is sent to you to correct or if no correction, a null route is implemented to protect their reputation and abide by the majority of FBL in place

The domain in question was been spoofed and no spam email was been sent from Nico servers
Spamcop should not have contacted Nico datacentre - they should have contacted the IP address owner (which is a dynamic IP address - usually from an ISP)
The datacentre should not have contacted Nico and certainly should not have threaten to null route his IP address as his IP address was not involved in the spam sending. If our DC had undertaken same actions to ourselves, we would immediately threaten business interruption if they null routed or blocked email ports
The SPF record control is always with the domain owner unless they have authorised a third party to maintain their DNS or specific DNS record.
GDPR stops an unauthorised change by a hosting supplier to DNS unless authorised to make a change by the domain owner.
Where a hosting supplier makes an unauthorised DNS record change, they then have to accept all legal implications of that change, which in the case of SPF could be loss of email and business loss due to that change.
We make changes to DNS records upon request or authorisation to make changes as we see fit in order to help the domain owner.

@nico, sorry if I have missed anything or made a mistake above, please correct and glad you now understand fully

Many thanks


@d2d4j Hi John,
Many many times THANKS to take the time and explain this in such details.
Kind regards,

Thanks for the clear explanation. Yes, that certainly seems like an insane way to deal with a spam issue. Sounds like turning off the water to a house because another house across town has a burst pipe.

Based on that explanation, no, it wouldn’t have helped the spam issue, at all. The spam that they were sending wasn’t touching your server at all, so it would have just made trouble for you without solving the issue.

I’ve never heard of anyone doing that. Sigh.