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
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
- Microsoft: How email authentication works
- Amazon SES: SPF authentication
- Postmark: Inactive recipients and suppression
- Gmail sender guidelines
Sources reviewed 8 September 2026. Our editorial standards.