Business email

Why Invoice Emails Fail While Everyday Email Still Works

By EmailmetryReviewed 3 min read

An invoice can go missing while staff email works because the accounting application may use another sending route. Check the recipient and the application's send or delivery record first. An old address, suppressed recipient or receiving-system filter can explain the problem without any SPF fault. A successful personal email does not identify the cause.

One address can represent two sending routes

An employee can send a reminder from accounts@example.com through Microsoft 365 while an accounting application displays that address on mail sent through the supplier's own infrastructure. This is an illustrative arrangement, not how every accounting product works; some connect to the customer's existing mail service.

The visible From address does not establish which system sent the invoice. Forwarding it manually through a working mailbox can be a useful immediate workaround, but it creates a new message through a potentially different route.

That is why a successful staff email and a missing invoice are not contradictory evidence.

The same visible From, two sending paths

From: accounts@example.comWhat the customer sees
Personal reminderWritten in the staff mailbox
sent through
Microsoft 365Staff email route
Automated invoiceGenerated by accounting software
sent through
Accounting supplierA separate route in this example
Hypothetical routes. Some applications use the existing mail service. SPF checks the actual envelope domain and connecting IP; the shared visible From does not make the routes equivalent.

The application's record matters first

Before changing DNS, establish whether the accounting application attempted to send the invoice, which recipient address it used and what status it recorded.

An outdated contact address is enough to explain why invoices fail while a member of staff's replies succeed. A previous hard bounce or complaint may also cause a sending platform to suppress later attempts. Postmark documents this behaviour, although the accounting supplier's own rules need checking.

A message marked sent may only have been accepted by the sending service. A rejection or suppression detail is more useful than repeatedly pressing resend. The recipient address, timestamp and message identifier also give the supplier or IT provider something specific to investigate.

An incorrect contact address or a suppressed recipient needs attention in the application or sending platform. A rejection needs its stated cause investigated; an SPF fault is one possibility, and other rejection reasons call for different corrections.

If authentication is involved, inspect the identity actually used

SPF checks the envelope-sender domain, commonly visible after delivery as the Return-Path. It can differ from the From address. Microsoft's authentication explanation describes those identities.

For example, Amazon SES uses a provider-owned default MAIL FROM domain and supports a custom-domain option. An application using a provider's envelope domain will not necessarily be affected by a change to the business's root SPF record.

DMARC then considers alignment with the visible From domain. An aligned, passing DKIM signature can satisfy it even when SPF authenticates a different domain. The application's documented authentication settings and evidence from an actual message matter more than a generic green domain-check result.

Our email-authentication article explains that relationship. Adding an accounting supplier to the root SPF record without checking the route can be irrelevant and can add unnecessary policy complexity.

Accepted mail can still be filtered

A recipient's system may put an invoice in junk or quarantine, apply an attachment policy or process it through a mailbox rule. The sender's reputation and message content can matter alongside authentication, as reflected in Google's sender guidance.

A short personal reminder and an automated invoice with a PDF or payment link are different messages. Successful delivery of the reminder does not prove that the customer overlooked the invoice.

For a payment that needs attention now, manual delivery or another agreed contact method may resolve the immediate business problem. Investigation of the application's original send can then establish whether there is a repeatable fault.

Emailmetry's SPF checker can inspect public SPF records and their dependencies when that is relevant. It cannot see the accounting contact record, platform suppression, the recipient's quarantine or whether that invoice arrived.

Sources and further reading

Sources reviewed 8 September 2026. Our editorial standards.