Enter your idea

Christopher - Up until today, I had always assumed that the problem was with criminals spoofing the originating email address. If they are genuinely using Xero's email server to send SPAM, then that is a SERIOUS issue, and needs to be dealt with URGENTLY. I have seen emails that have been SPOOFED, but not from a hacked Xero email service.

I agree with Dennis - This needs escalating, either to Xero, or to NCSC. if you have relevant evidence, then by just sitting on it you are not helping to stop the problem. If you have definite information that the SPF/DMARC has been hacked, then NCSC need to know.

Just marking all emails from Xero as SPAM makes it even more difficult for those who do NOT have the technical expertise to use add-on systems.

I agree with the diagnosis that it is passing SPF/DMARC. They are also allowing the messages on a subdomain used for financial comms.

If the reason for not tackling it is to allow free trials, they could at least bump free accounts onto a different subdomain.

I understand the appropriate action is to forward any examples as an attachment to phishing@xero.com

For such a major vendor and persistent security issue, it could go to the National Cyber Security Centre (NCSC) in the UK - see if they can communicate with Xero about it.

Good luck with that and enjoy. We had 335 fraud emails today across 2000 people, and they are the ones reported. I wont be using my 11 staff to spend their entire working year chasing 335 new vendors each day.

If a vendor cant secure their system they are on the blacklist. End of.

Thanks, and I wish you all a good day.

Can Xero clarify what escalation path you recommend for reporting suspected fraud or platform abuse outside of the normal support ticket process?

Forum discussions and standard tickets don’t always reach the team responsible for security review, and in cases where emails are being sent through Xero’s messaging service and passing SPF / DMARC, it would be helpful to know the correct channel to report this so it can be reviewed by the appropriate security or abuse team.

If there is a dedicated contact, abuse address, or incident-response process that partners and IT providers should use for situations like this, please provide that information so these reports can be submitted through the proper path instead of only being raised in forum threads.

Christopher,

Complaints on the forum by themselves don’t fix the underlying issue, I agree with that. My point was that if the concern is serious enough that you are blocking an entire vendor sending domain across client environments, then the discussion should move beyond forum posts and into a proper escalation path with the vendor. Forum threads are useful for awareness, but they are not the same as reporting a security incident through the channels vendors use for abuse, fraud, or incident response.

If Xero truly considers the behavior expected, then the right place to challenge that is through their security or abuse reporting process, not just community discussions. Most platforms have a separate escalation path for fraud, spoofing, or platform abuse that goes beyond normal support tickets, and that is typically how these kinds of issues actually get reviewed by the people who can make changes.

From my side, the reason I questioned this is because blocking an entire service like post.xero.com at the client level treats the symptom but does not address the source. I understand why you would do it to protect clients in the short term, but long-term that approach just shifts the problem instead of resolving it. Blocking symptoms without reporting the cause does not improve security, it just moves the problem somewhere else.

Great, you mean like this never ending thread of responses of people telling Xero how insecure their platform is allowing anybody to send emails from Xero and Xero responding saying its not an issue. E.g. they already know these Xero emails are not secure so I see no point to this.

Anybody receiving these emails has already raised / followed the cyber security issue with Xero. Xero are not interested, if they was we wouldnt have them blocked on every client system due to high risk fraud.

I also want to address the comment about “virtue signaling,” because that does not apply to what I said. Virtue signaling is when someone makes a statement purely to appear morally superior or to gain approval, without any real intent to solve the problem. That is not what I am doing here. My response was based on standard incident-handling practice that we use in the IT industry every day.

When a system is believed to be insecure, compromised, or being abused to send messages, the normal process is to notify the source with enough technical detail for them to investigate. That is not trying to fix the world, and it is not trying to make a point — it is simply how root-cause resolution works. We do this regularly when other companies’ tenants, mail systems, or domains are used to send malicious or suspicious messages to our clients. We contact their IT or security team, provide headers/logs, and let them handle it on their side.

In this case, the concern raised was about Xero’s sending platform. If that platform is considered insecure or untrustworthy, then reporting the behavior to the vendor with the data you already have would be the normal and professional step, especially for a company that provides IT security services. That is not virtue signaling — that is basic escalation and responsible handling of a security concern.

It may also make sense to ask Xero what escalation path they recommend for security-related incidents outside of normal support, so situations like this can be reported through the proper channel instead of only working through standard ticketing. Most vendors have abuse, security, or incident response contacts specifically for this reason.

I agree that our priority is to protect our own clients, and we do the same. But part of protecting clients is addressing the source when possible, not only putting local restrictions in place and leaving the underlying issue unresolved. Blocking symptoms without reporting the cause does not improve security, it just moves the problem somewhere else, and increases the chance that the same issue will continue to affect other companies as well.

Great, go and knock on Xero's door then and tell their CISO they have insecure platform and you will fix all their issues for them. Then repeat it for every company in the world with an insecure issue.

Then when finished virtue signaling go and actually look after your clients

Christopher,

As an IT services provider myself, I deal with these situations regularly. When one of my clients receives suspicious or malicious emails from another company, I contact that company directly to let them know their account has likely been compromised so they can correct the issue on their end. Once notified, the expectation is that their IT or security team takes ownership of the problem, investigates the breach, secures the account, and confirms that the threat has been contained.

In this case, since you are not contacting Xero directly, they may not even be aware that their system or domain is being used in a way that is causing issues for others. As an IT security company, you are in a position to provide them with message headers, logs, timestamps, and other technical details that most normal businesses would not know how to gather or send. Sharing that information is part of responsible incident handling and helps stop the problem at the source instead of only working around it.

While I agree that we should be able to use our own domain without restrictions, the lack of ownership being taken here is concerning. When a security-focused IT provider sees activity that appears malicious or compromised, the standard practice is to notify the source, provide the evidence, and work to have the root cause corrected. Simply blocking or refusing communication without escalating it to the affected vendor does not resolve the underlying issue and allows the problem to continue.

From our side, we will continue to secure our environment as needed, but the responsibility for reporting and working with the sending platform falls on the party that identified the security concern, especially when that party is an IT security provider.

Why would I do that? We provide cyber services to our clients, if Xero have an issue with Fraud its not my problem. We get hundreds of things like this a day, Xero are not our client. We use Xero for our finances but a third party sends our invoices for us. More simply raising awareness here as a small cyber security provider, we block the post.xero address in our client systems as it is a known fraud address.

Christopher - If that is the case, then have you had direct discussions with Xero?? I know that it is not easy to get hold of them, but it is possible....

Tim - I am not a fan of these long trails however the emails certainly are being sent from Xero systems. They match the SPF records exactly. The spammers simply sign up for a xero account and then send the spam.

We investigate these xero fraud emails weekly as a cyber security company, they nearly always match the SPF and DMARC and pass. If you dont know what these are then just take it from me, they are sent from Xero.

I AM not excusing Xero's response so far to this issue, but please remember that the emails are NOT being sent via Xero's systems. Spammers are spoofing the address, and there is NOTHING that Xero can do about that part of the problem.

Obviously, if we are able in the future to send our emails from our own domain, this will mitigate the issue for most larger companies, who have their own domain. However, it will not stop the problem of emails being sent with spoofed addresses, and this will still affect small businesses, who struggle with many IT setup issues.

I own an IT support business, we manage IT and networks for dozens of small businesses in our area. One question I am getting without fail, over and over again, is: "Are there any options for accounting software that aren't Quickbooks?" This email issue is the main thing that keeps me from recommending Xero as it indicates a fundamental lack of understanding by Xero of how basic email security works.

If Xero is this clueless about email, what other security issues are they overlooking?

Kelly - Just FYI I run a small cyber security company. We only support around 2000 people however we have these Xero scams every week from post.xero.com. We have to tell our clients it is an untrusted address. We use a third party paid tool for our invoices syncing to Xero, but it is terrible we see this scams every single week from Xero without fail.

Here's an example of something that looks wrong and shouldn't be happening.

It's an email from xero.com but for a company recruiting for AirBnB by asking to click a link.

To me, this stuff should not come from xero.com, it's what gets our invoices blocked.

I sent 13 invoices to one customer of a client yesterday; if I get through my tasklist today, I'll have sent another 11. Because of the volume of invoices - every contractor is required by their systems to be invoiced separately, and there's a LOT of them - their email systems have automatically flagged message-service@post.xero.com as spam. As a result, I have to send each invoice individually to me, forward individually to the customer (modifying the email to make it look more professional and aligned with my client's brand), and then individually mark each invoice in Xero as sent, to whom, and that delivery and read receipts were enabled.

That's doubling my workload for no benefit to the client. Other than being able to add delivery and read receipts, which I was comfortable foregoing for the ease of invoicing that Xero offered before the domain got flagged.

I'd ask the client's customer to whitelist the domain, but frankly they shouldn't have to.

Happy to provide some free consultancy on this. Have run an email hosting service in a London datacentre since 1999, and ran a software development team for 20 years.

Andrew, in a proper implementation the ability to send from a domain is tied to proof of ownership of that domain.

The platform would require DNS verification first, and only the account holder who successfully verifies control of the domain would be permitted to send using it.

Without that verification step, the domain simply can’t be used. Mature SaaS platforms already implement this control as standard practice.

I think there may be some confusion about how domain verification and SMTP authorization actually work in this scenario.

In a properly designed system, granting SMTP or domain-verified sending rights inside one tenant/company should not allow another tenant (including Demo companies) to send mail from that domain. Domain verification is normally tied to DNS ownership, and the verified domain should only be usable within the specific organization that completed that verification.

In other words, if Xero implemented this correctly, a threat actor using a Demo company would not be able to send from my domain unless they also had control of my DNS records or access to my organization. That is the same model used by services like Microsoft 365, SendGrid, Amazon SES, and others.

Because of that, the risk would not come from Demo accounts themselves, but from a misconfiguration, lack of tenant isolation, or improper domain verification controls.

From a security standpoint, allowing verified domain sending is actually more secure than forcing everything through @post.xero.com, because proper SPF, DKIM, and DMARC alignment can be enforced and recipients can validate the sender more reliably.

If there is a concern that Demo environments share the same mail infrastructure without strict separation, then that would be the real issue that needs to be addressed, not the concept of using a verified domain itself.