Why Your Invoices Are Landing in Spam (and What to Fix First)

Business email lands in spam when the receiving system can’t verify or trust the sender, either because your own domain lacks working SPF, DKIM, and DMARC, or because the invoice came from an app’s mail server, not yours. The first fix is finding out which of the two your invoices fall into.

If your business email is landing in spam, invoices are usually where you notice it. A customer says they never got the bill. Someone finds it in junk three weeks later. Payment slips a month. Nobody connects it to email.

Most of our clients run their email on Microsoft 365, and getting it authenticated properly is part of our Cloud and Microsoft 365 work. It’s also squarely in my lane. QuickBooks and Outlook have the most application issues of any programs we support, and an invoice is exactly where the two of them meet.

Almost everything below is fixable. Some of it is DNS. Some of it is changing how the invoice gets sent.

Why Invoices Get Caught Before Anything Else

Email deliverability is whether a message reaches the recipient’s inbox rather than their spam folder or a rejection. For business email it comes down mainly to authentication, the SPF, DKIM, and DMARC records that prove a message came from the domain it claims, plus the reputation of whatever system actually sent it.

Invoices get extra scrutiny for a plain reason. Criminals send fake ones. The FTC’s May 2026 alert for small businesses warns that scammers “sometimes email you fake invoices,” and Microsoft’s threat intelligence team reported in January 2026 on emails “intended to trick organizations into paying fake invoices.” Behind them sits business email compromise, which the FBI’s 2025 Internet Crime Report tied to 24,768 complaints and $3,046,598,558 in reported losses, second only to investment fraud.

Filters know all of this. A message that says “invoice,” carries a PDF or a payment link, and can’t prove where it came from looks, to a machine, a lot like the thing it’s trained to stop. Your invoice isn’t suspicious. It just can’t prove it isn’t.

The vendors say so themselves. Xero’s support article is refreshingly blunt. “Emails sent from Xero usually contain financial information, so can sometimes be incorrectly identified as spam and redirected to junk folders, or rejected completely.” Honest of them.

First, Find Out Which Server Sends Your Invoices

Almost everyone skips this step. When you click send in your accounting software, the invoice may leave through your own Microsoft 365 mailbox, or it may leave through the software company’s mail system with your name on it. Those are different problems with different fixes. Check first.

The sources are each vendor’s own help pages, QuickBooks Desktop email setup, QuickBooks Online’s Gmail option and its delivery troubleshooting, Xero’s email settings, FreshBooks’ sending addresses, and Stripe’s custom email domain guide.

The table splits this in two. If the invoice leaves through the app’s own mail system, your DNS records don’t decide its fate. The receiving filter is judging the vendor’s servers and reputation, not yours, and Intuit’s own advice is to have an IT expert add its mail servers to an allow list. You can’t fix that from your end. Not with SPF, anyway.

If the invoice leaves through your own mailbox, which is how QuickBooks Desktop works and how anyone sending a PDF from Outlook works, then your domain’s authentication is the whole story. That second case is where your own records matter, and it’s where the rest of this guide spends its time, because it’s the one you can actually fix from inside your own office.

Microsoft 365 Doesn’t Sign Your Domain Until Someone Sets It Up

It’s easy to assume Microsoft handles this. For your own domain, it doesn’t. Not by itself.

Microsoft’s own DKIM documentation says that mail from the built-in onmicrosoft.com domain is signed automatically, but “currently, no DKIM signing occurs for outbound mail from custom domains” until someone configures it. That’s your company domain. The one on your invoices. Its DMARC guidance is just as direct. There are “no admin portals or PowerShell cmdlets in Microsoft 365” for your custom domain’s DMARC record, so it has to be created at your registrar or DNS host.

A migration can stop at the mailboxes. It happens. Mail flows, everyone’s happy, and nobody goes back to publish DKIM and DMARC. That can look fine for months, right up until a large customer tightens its filtering and your invoices start disappearing without a single bounce message to tell you why. If you’re planning a move, the Microsoft 365 migration isn’t finished until those records are in place.

Microsoft’s filters notice, too. Its email authentication overview describes a composite check, stamped in the message header as compauth, and gives the example of a domain with “no SPF, DKIM, or DMARC records” getting compauth=fail. One reason for authentication, in Microsoft’s words, is making sure it “doesn’t automatically junk email from your customer domains simply because it isn’t authenticated.”

One SPF Record, Ten Lookups

SPF is the list of systems allowed to send mail as your domain. Two rules trip up small offices constantly, and both come straight from the standard, RFC 7208.

First, one record. If a domain publishes more than one SPF record, the check “produces the ‘permerror’ result,” which is a failure. The usual cause is innocent. Someone sets up a new service, its instructions say “add this SPF record,” and they add a second record next to the first one instead of editing the one that was already there. Now neither works.

Second, ten lookups. SPF implementations “MUST limit the total number of those terms to 10 during SPF evaluation,” and exceeding the limit also returns permerror. Microsoft’s SPF guidance adds the catch people miss. Fewer than ten include statements can still add up to more than ten lookups, because includes can contain includes. Microsoft 365, the website’s contact form, a marketing tool, and a CRM all spend from the same budget. It runs out fast.

Nothing looks broken when this happens. Mail still sends. It just stops passing.

Microsoft’s own fix for services you don’t control is worth copying. It recommends “using a subdomain (for example, marketing.contoso.com) instead of your main email domain,” which keeps a newsletter tool or a CRM from eating your main domain’s lookups, or its reputation.

What the Big Mailbox Providers Now Require

Since February 2024, Google, Yahoo, and then Microsoft have each published sender rules and started enforcing them, and the enforcement has moved from quietly filtering mail into spam toward rejecting it outright. Most small offices aren’t bulk senders. The baseline rules apply to everyone.

The sources are Google’s email sender guidelines and its sender guidelines FAQ, Yahoo’s sender best practices, and Microsoft’s announcement for Outlook.com high-volume senders.

Two details matter for invoices. Google is explicit that its requirements apply “only when sending email to personal Gmail accounts,” so mail to a business Google Workspace account isn’t covered by these specific rules. But a lot of small customers, contractors, and homeowners use personal Gmail, and those are the invoices these rules govern. And Google warns that messages that aren’t authenticated “might be marked as spam or rejected with a 5.7.26 error.” That code is worth knowing if a customer ever forwards you a bounce.

How to Tell What’s Actually Failing

Guessing wastes weeks. The receiving server writes down exactly what it checked.

Send a real invoice, the way you normally send it, to a personal Gmail address and to an Outlook.com address you control. Open the full message headers. Start with the From address. It tells you which case you’re in. Then find the Authentication-Results line. Microsoft’s header reference spells out what each part means. Four fields matter.

• spf= pass, fail, softfail, or permerror. Permerror usually means two SPF records or too many lookups.
• dkim= shows pass or fail, and the header.d value tells you which domain signed it. If it’s missing, or it names onmicrosoft.com rather than your domain, DKIM isn’t set up for your domain.
• A dmarc=bestguesspass result is Microsoft telling you that no DMARC record exists at all, but the message would pass if one did. Close, not done.
• compauth=fail with reason 001 is the one to worry about. Microsoft defines it as a sending domain that “didn’t have email authentication records published,” or had only weak ones.

A few minutes with the headers usually tells you which of the fixes below you actually need.

What to Fix First

Order matters. More here than in most IT projects, because tightening policy before the sending sources are fixed blocks your own mail.

1. Work out how each kind of invoice leaves, through your mailbox, through the app’s mail service, or through a service sending as your domain. The header test above settles it.
2. For invoices sent from the app’s own servers, give customers who keep missing them the vendor’s sending domains to add to their safe senders, or send those customers the PDF from your own mailbox instead.
3. Turn on DKIM for your custom domain in Microsoft 365.
4. List every other system that sends as your domain. The website’s contact form, any marketing or CRM tool, and the office copier’s scan-to-email if it relays through your domain. Authenticate each one the way its vendor documents, or move it to a subdomain.
5. Collapse everything into one SPF record, and count the lookups.
6. Publish a DMARC record at p=none with reporting turned on, and read the reports for a few weeks. They show every system sending as your domain, including the ones nobody put on the list.
7. Move the policy to quarantine, then to reject. That’s the path Microsoft recommends, and “the goal is to get to a p=reject DMARC policy for all of your custom domains and subdomains.”

Reject is where the U.S. government put itself years ago. CISA’s Binding Operational Directive 18-01 required federal agencies to set “a DMARC policy of ‘reject’ for all second-level domains and mail-sending hosts,” calling it “the strongest protection against spoofed email.” A 20-person office can get there too. It just shouldn’t get there in one step.

The Same Records Stop Fake Invoices in Your Name

Fixing your domain has a side effect worth more than the fix itself. Once it publishes DMARC at reject, receiving servers are told to reject mail that claims to be from you and can’t prove it. That includes the fake invoice someone sends your customer from a forged copy of your address, with new bank details on it.

That’s the business email compromise playbook, and our business email compromise guide walks through how it plays out. Same records, both jobs. The ones that get your real invoices delivered are the ones that keep the forged ones out. It’s one of the few security fixes that also makes something work better. Take the win.

Common Questions About Invoices and Spam