Your invoices are landing in junk. Here's the email plumbing we'd fix.

A customer says they never got the invoice. It was sent. It's in their junk folder, or it bounced with an error code nobody in the office reads. Next week it's a booking confirmation.

That's rarely bad luck. Usually more systems send email as your business than anyone has written down, and some can't prove they're allowed to.

Count the systems that email your customers

In a typical small business, the list of things that email customers looks like this:

• staff mailboxes in Microsoft 365 or Google Workspace
• the website contact or enquiry form
• the job, booking or practice-management system (confirmations, reminders)
• a quoting or proposals tool
• a newsletter platform
• a payment-reminder or statements app
• the accounting software

Each one does one of two things. It sends as your domain (From: accounts@yourbusiness.com.au), in which case it has to be properly authorised for that domain. Or it sends from its own domain and puts your address in reply-to.

Xero is in the second group right now. Xero's own response on its product ideas board says invoice emails go out from Xero's message service, with replies going to the reply-to address you set. On 21 October Xero moved "send from your own domain" to In development, with no date. One commenter on that thread said spam filtering had got bad enough that they now download invoices and email them by hand. When that feature does arrive, Xero becomes one more system sending as your domain, so your domain's records need to be sorted before then.

What the receiving server checks

Three DNS-based checks decide whether a message claiming to be from your domain gets trusted:

• SPF: a TXT record listing which servers may send mail for your domain.
• DKIM: a cryptographic signature added by the sending system, checked against a public key in your DNS.
• DMARC: a record that says "the domain in the From: line must match a passing SPF or DKIM domain, and here's what to do if it doesn't". It also asks receivers to send you reports.

The word that trips people up is alignment. A booking tool can pass SPF and DKIM for its own domain and still fail DMARC for yours, because the domain that passed isn't the one in the From: line.

What the big inboxes ask for now

Google's sender guidelines say that since 1 February 2024, anyone sending to personal Gmail accounts needs SPF or DKIM set up. Senders of more than 5,000 messages a day need SPF, DKIM and DMARC, with alignment. Unauthenticated mail "might be marked as spam or rejected with a 5.7.26 error."

Microsoft's Outlook.com postmaster site says that from 5 May 2025, domains sending more than 5,000 emails a day to Outlook.com must pass SPF, DKIM and DMARC. Non-compliant mail goes to junk and can be rejected with 550 5.7.515.

Most Adelaide businesses don't send 5,000 emails a day, so the strictest rules aren't aimed at you directly. A newsletter platform sending under your domain might be, though, and your business customers' filters make their own calls. Proper authentication is now the baseline.

Where it usually breaks

1. DKIM never switched on for your own domain in Microsoft 365. Microsoft's documentation is blunt: "no DKIM signing occurs for outbound mail from custom domains" until you configure it with two CNAME records.
2. A broken SPF record. The SPF standard (RFC 7208) caps the lookups an SPF check can trigger at 10. Every include:, a, mx and redirect counts. Go over and the result is a permanent error. Publishing two SPF records gives the same result.
3. Third-party tools that aren't aligned. As above, they pass for their domain, not yours.
4. The website form sending through the web host's mail function, from a server that isn't authorised anywhere in your records.
5. Old services still listed in SPF after you stopped using them. The Australian Signals Directorate's guidance on email service providers points out that including a provider in your SPF record means "your SPF posture is set by the permissiveness of the ESP's DNS records."
6. DMARC stuck at p=none forever, with reports going to a mailbox nobody opens.

It's not only about deliverability

ASD's Annual Cyber Threat Report 2024–25 lists the top cybercrimes businesses reported. Email compromise with no financial loss was 19% of reports, and business email compromise fraud with a financial loss was 15%. The average self-reported cost per cybercrime report for a small business was $56,600.

A DMARC policy at enforcement stops people sending mail that uses your exact domain, at receivers that honour it. It won't stop a lookalike domain or a staff mailbox that's been taken over. So keep the human control too: call a known number before changing anyone's bank details.

What we'd build

1. A sender inventory built from evidence, not memory. Publish DMARC at p=none with a reporting address that feeds a small parser. The daily aggregate reports (XML files from receivers) go into a database. Every sending source is mapped to a named system and an owner, and anything unknown is flagged.
2. DNS as code. Your mail-related DNS records live in a git repository and changes go through a pull request. An automated check parses SPF, counts lookup terms (fail above 10, warn when close), confirms there's exactly one SPF record, confirms every DKIM selector resolves and validates the DMARC syntax. Where your DNS host has an API, deployments go through it, so the repo and the live records match.
3. Fix each sender properly. Turn on DKIM in Microsoft 365 or Google Workspace with 2048-bit keys where supported. Authenticate each third-party tool with its own DKIM selector, which ASD recommends so one can be revoked without touching the others. Move marketing email to a subdomain, as both Microsoft and ASD suggest. Move the website form onto an authenticated transactional email service. Remove includes for services you no longer use.
4. Staged enforcement. Go from p=none to quarantine (ramped up) to reject, moving to each step only when the report data shows every legitimate source aligned for a set period.
5. Daily send tests. Each system that emails customers sends a test message to seed mailboxes: a personal Gmail account, an Outlook.com account and a business Microsoft 365 tenant. A script reads the Authentication-Results headers (SPF, DKIM and DMARC pass, plus alignment) and which folder each message landed in. Any failure raises an alert.
6. Alerts that go to a real person. Triggers include a new unknown source in the DMARC reports, a known system's alignment dropping, a DNS record changed outside the repo, 5.7.26 or 5.7.515 bounces turning up in the accounts mailbox, and DKIM keys past their rotation date.
7. A one-page checklist for the next tool. Before any new system emails a customer: domain authentication set up, subdomain or not decided, a test send passed, and the system added to the inventory with an owner.

No new platform needed: DNS, a few small scripts, a database and some alerts.

Want to see it on your domain?

Book a free chat first. If it's a fit, we'll build one free tailored demo for your business. Give us your domain name (only public DNS, no logins) and we'll show you your current SPF, DKIM and DMARC records, your SPF lookup count, which known services look authorised, and a working sender-inventory dashboard built from your records. If you can forward headers from a few emails your systems sent, or a week of DMARC reports, we'll map your real sending sources as well. No obligation, and no promised deliverability numbers.

Sources: Google Email sender guidelines (support.google.com/a/answer/81126); Outlook.com Postmaster policies and Microsoft Support on 550 5.7.515; Microsoft Learn, DKIM for custom domains; RFC 7208 §4.6.4; ASD, Marketing and filtering email service providers; ASD Annual Cyber Threat Report 2024–25; Xero product ideas board, own-domain sending (status updated 21 Oct 2026).