Settings and activity
2 results found
-
409 votes
Hi team, we appreciate the on-going support and feedback we're receiving on this idea and pleased to be able to share this update. Our product team are actively exploring how we can best solve for the needs raised here, although at this time are unable to provide any set timeframes.
They are very much aware of the appetite from our community on this, and as part of their exploration have reached out some users here as they gather insights.
For the time being we'll shift to In discovery and I'll return as soon as there is more on this to share.
An error occurred while saving the comment An error occurred while saving the comment 
Adam Romain
commented
Andrew,
I think there may be a bit of a misunderstanding here.
The suggestion isn't that anyone should be able to send arbitrary email addresses through Xero. The whole point of domain verification is the opposite .... it proves that the sender actually controls the domain they're sending from.
Platforms like SendGrid, Amazon, HubSpot and many others already do this. You add a DNS record to prove ownership of the domain, then configure SPF/DKIM so receiving mail servers can verify the message is legitimate.
Without that verification step, it wouldn’t work in the first place.
The current situation actually has the opposite problem .... invoices arrive from @post.xero.com, which can look less authentic to recipients who expect communication from the company’s own domain….
An error occurred while saving the comment Adam Romain
commented
Kelly and the team @ Xero. I'm VERY pleased to see this major problem has now progressed internally at Xero.
From Xero's point of view, the objective is simple. Give customers who want the ability to use their own domain, following proof of ownership of the domain, the ability to send as alias@company-name.com
.A straightforward domain ownership verification step would prevent abuse. Once verified, users could configure the necessary DNS records (SPF/DKIM/DMARC) to support it.
If there are concerns around support load due to misconfigured mail authentication, the feature could simply be opt-in with a clear disclaimer that configuration of SPF/DKIM/DMARC is the responsibility of the customer.
Businesses that already operate with custom domains typically have access to the resources needed to configure DNS correctly. And for smaller customers or those who prefer simplicity, the existing @post.xero.com option remains perfectly suitable.
In other words, this doesn't need to replace the current system ... just provide a proper option for those who need it.
Ultimately, enabling this would strengthen the authenticity and professionalism of communications sent through Xero.... giving SMEs a small but meaningful professional boost, and making it a clear win for both customers and Xero.
Be bold Xero. Lead on this. It's important.... trust me..... I'm a consulting CISO.
An error occurred while saving the comment Adam Romain
commented
@Mike I see how you might have misread my post, so I’ve just updated it.
Basically, I’m saying that a bad actor could sign up, create fake invoices using a legitimate logo, and send them through Xero’s sending platform - using message-service@post.xero.com - making them appear entirely genuine.
An error occurred while saving the comment Adam Romain
commented
@Mike.
I think we may be getting wires crossed. I'm really saying two things:That legitimate email from post.xero.com is properly configured from a DMARC perspective (including SPF and DKIM).
That I agree with you regarding what's needed from both Xero and its customers to support sending from a custom domain.
It’s been a long day - so perhaps I didn’t explain myself clearly. :o)
An error occurred while saving the comment Adam Romain
commented
****And why does this really matter?****
Xero offers a 30-day trial with no credit card required. It’s not beyond imagination that a malicious actor could exploit the platform to impersonate a legitimate company and send highly convincing invoices or payment requests - all delivered via Xero’s trusted infrastructure.
>> UPDATED for context: >>>
By using the default Xero Mailer and therefore the generic domain post.xero.com.... the domain we ask our clients to trust <<<
To an unsuspecting recipient, it could look entirely legitimate. I wouldn’t be at all surprised if this has already happened.
By allowing customers to authenticate and send using their own domains, Xero could help prevent abuse and strengthen trust in the platform. It’s not just a feature request - it’s a security control. An very important one.
An error occurred while saving the comment Adam Romain
commented
To clarify for anyone confused about DMARC (along with SPF and DKIM): the sending domain post.xero.com is fully DMARC-aligned. It has the recommended policy (p=reject), and the SPF and DKIM records align correctly with the message headers my team and I have reviewed for legitimate emails.
The issue, however, is that clients expect accounting-related emails to come from my company’s domain - not from a generic sender that may or may not appear to be genuinely linked to us. That’s the core limitation I’d like to see improved.
I want to demonstrate that we have control and accountability over the emails we send - and the best way to do that is by using our own domain and brand. This is something many other SaaS platforms already support.
Yes, it’s true that not all Xero customers may be in a position to set up domain authentication - but that’s no reason to deny the option to those of us who are. It should be something we can opt into.
What’s needed from Xero is the ability for customers to send from their own domain, along with a clear setup guide covering how to implement or adjust DMARC (and the supporting SPF/DKIM records). Many SaaS providers offer this - complete with record validation and setup walkthroughs. It’s entirely doable.
It just needs doing.
An error occurred while saving the comment Adam Romain
commented
@Perry yes, online. I don't know much about the desktop version but I would assume that would mail through the user's mail account directly/use on-prem servers for relay and therefore benefit from the domain authenticity of that set up.
An error occurred while saving the comment Adam Romain
commented
@Perry You said:
"The best solution is for Xero to finally deal with this most basic of user requirements. It's an industry standard and DKIM/SPF support is necessary, now. It's simply not that hard to implement."
Absolutely agree.
As a cyber security consultant, a key part of my role is helping businesses, large and small, improve their email security posture. I routinely advise them on identifying phishing attempts, securing their email domains, and implementing SPF, DKIM, and DMARC properly, especially when adopting complex SaaS platforms.
Then we send them an invoice via Xero - and it arrives from a generic mailer. More often than not, we hear that it wasn’t received, was flagged as suspicious, or ended up quarantined by their mail filters. It undermines our credibility. We look like we’re not following our own advice.
This issue is especially relevant to me now. I recently moved away from QuickBooks which, incidentally, has the same limitation. Furthermore, with the loss of my commercial director (who had a more 'old school' way of working), I’ve been focused on streamlining operations and getting the most out of Xero.
So yes, this is a significant matter. Fortunately, I have the technical expertise to implement a workaround in the short term. But I want to... no, I expect to.... see Xero address this with urgency.
An error occurred while saving the comment Adam Romain
commented
@Marc I've just followed you on GitHub, took a clone of the repo and done a quick scan of the code. Without testing it, looks okay to me on initial pass. I'll review it with my team next few days and have a go at implementing in our MS tenant.
I've got some further ideas to assist with deployment, pre-req checks etc. Will share feedback/contribute via GitHub.
Perhaps the Xero development team could take note....
An error occurred while saving the comment Adam Romain
commented
@Marc Banyard
I'm interested in this project as both a user and contributor. I run a cyber sec business so I have access to resources that may be useful. You can contact me via the following temp email address: metals.pulleys_8y@icloud.com
An error occurred while saving the comment Adam Romain
commented
Regarding "Sending emails from a cloud environment as another domain would require permissions being granted to xero that many network administrators would find difficult to agree to."
I am a consultant CISO. I can tell you this is standard practice. As organisations move to SaaS platforms, this is exactly what network administrators should support, particularly with the correct use of DKIM and DMARC. In fact, it's MORE secure.
An error occurred while saving the comment Adam Romain
commented
I've just found out today that some of my clients automatically block mail from message-service@post.xero.com because of phishing/spoofing attacks. And as a result our invoices and quotes have not been delivered. This suggestion goes bat to 2013. That's TWELVE years ago.
So the idea is accepted. And what? That's it? Xero accept the problem. Thanks. Come on. This is a FUNDAMENTAL requirement in 2025.
I can imagine why this is not implemented yet.... .. a lot of small businesses, solo traders, etc., may not have the technical capability to deal with domain integrations/DMARC/SPF/DKIM and because of that, XERO backs away given the support implications would be too heavy to deal with.
Adam Romain
supported this idea
·
-
125 votes
An error occurred while saving the comment Adam Romain
commented
Wow, I'm new to Xero. I'm very surprised how buried the Send Remittance function is. It would make perfect sense to me if the function was available after processing the payment. ¯\_(ツ)_/¯
Adam Romain
supported this idea
·
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.