Your quote was sent. Why did the client never receive it?

The quote is ready. The rep reads it over, attaches the PDF and clicks Send at 2:07 p.m. Outlook files the message in Sent Items. No failure notice comes back.

Three days later he follows up. The reply: "We never received your quote. We picked another supplier yesterday."

The email had in fact been accepted by the recipient's system. It was simply sitting in the spam folder, in a quarantine, or behind a filter nobody had checked.

The problem was neither the content of the offer nor the rep's work. It was deliverability: the ability of a legitimate email to reach the inbox rather than being delayed, rejected or classified as junk.

For a business, this is not just a mail issue. A lost quote, an invisible invoice, an ignored renewal notice or a blocked e-signature link can delay a sale, a payment or an entire project.

"Sent" does not mean "delivered to the inbox"

The Sent Items folder mostly confirms that your application handed the message to your mail system. It does not confirm that the recipient's server accepted it, still less that it was placed in the inbox.

In between, several systems ask their own questions:

• is the server sending this message authorized to use this domain?
• was the content signed, and did it stay intact in transit?
• does the visible sender address match the domain that was authenticated?
• do this domain and this infrastructure have a good reputation?
• do recipients open these messages, or report them as spam?
• do the volume, links, attachments and sending behaviour look normal?

A server can accept a message and then classify it as junk based on all of those signals together. Conversely, a message can be refused in transit and produce a non-delivery notice. The absence of a failure notice is therefore not proof that the email was seen — or even that it is in the inbox.

The three identity checks of email

SPF, DKIM and DMARC look like acronym soup. Their role gets simpler when you see them as three complementary checks: who is allowed to send, how to verify the message's integrity, and what to do when the identity does not match.

SPF: who may send for your domain?

SPF publishes in DNS the list of servers authorized to send email for a domain. When a message arrives, the receiving system compares the sending infrastructure against that list.

If your business uses only Microsoft 365, the configuration can look simple. But how many other systems also send messages in its name?

• the CRM sending sales follow-ups;
• the accounting software issuing invoices;
• the newsletter platform;
• the website contact form;
• the e-signature service;
• the ticketing system;
• the payroll application;
• the copier that scans and emails documents.

Each one can be a legitimate source to inventory and configure properly.

Two mistakes come up repeatedly. The first is creating several separate SPF records for one domain. There must be only one; multiple records cause a permanent evaluation error. The second is adding providers one after another without accounting for SPF's limit of ten DNS lookups. One provider's nested references can consume several on their own.

SPF is therefore an authorization list, not a seal of quality. It is not enough to protect the name shown in the From field, and message forwarding can also complicate its evaluation.

DKIM: does the message carry a valid signature?

DKIM adds a cryptographic signature to the email. The sending system signs certain parts of the message with a private key. The recipient retrieves the public key published in DNS and verifies that the signature is valid.

That check helps confirm two things: the message was signed by a system authorized for the domain, and the signed parts were not altered in transit.

The important detail for a smaller business is that DKIM has to be enabled for every service sending on the company's behalf. The fact that Microsoft 365 correctly signs employee messages does not mean the CRM, the marketing tool or the invoicing software does the same with your domain.

A provider can apply its own signature and pass its DKIM check while signing with its domain rather than yours. Technically the signature is valid. For DMARC, however, the identity may not match the address the client sees.

DMARC: do the identities line up, and what if they do not?

DMARC ties the two previous checks to the address visible in the From field. A message passes DMARC if SPF or DKIM succeeds and the authenticated domain is aligned with the domain shown to the recipient.

That alignment stops a sender from passing SPF with their own domain while displaying yours to look legitimate.

DMARC also tells receiving systems how to handle a message that fails:

• p=none: gather information without requesting any particular action;
• p=quarantine: recommend quarantine or the spam folder;
• p=reject: recommend rejection.

DMARC aggregate reports then let you see which services send on the domain's behalf and which pass or fail the checks. Those reports are valuable, but their raw format is hard to read; they need to be analyzed by a tool or a person who can tell a forgotten service from a spoofing attempt.

Publishing a p=reject policy immediately, without knowing every legitimate source, would be risky. Rollout should be gradual: inventory the senders, enable SPF and DKIM, watch the reports with p=none, fix the gaps, move to p=quarantine, then to p=reject once the results allow it.

That progression improves deliverability while protecting the domain against spoofing. It directly complements the measures described in our article on business email compromise , where an attacker tries to make a fraudulent message look like a genuine email from management.

DMARC changed in May 2026 — what that means

If you configured DMARC a few years ago, your record still works. But the specification has been replaced, and two changes are worth making at your next DNS edit.

On May 20, 2026, the IETF published three documents that move DMARC onto the Standards Track and replace the 2015 specification: RFC 9989 for the core protocol, RFC 9990 for aggregate reporting, RFC 9991 for failure reporting.

The takeaways:

• Nothing breaks. Records starting with v=DMARC1 remain valid, and the p, sp, rua, ruf, adkim, aspf and fo tags keep their meaning.
• Three tags are deprecated: pct=, rf= and ri=. Receiving systems ignore them rather than rejecting the record, but you may as well remove them for cleanliness.
• Three new tags appear: np= for the policy on non-existent subdomains, t= as a testing indicator, and psd= carried over from a now-obsolete specification — that last one concerns only public suffix operators.
• The Public Suffix List is replaced by a DNS Tree Walk for determining the organizational domain.
• DMARC now evaluates SPF only on the MAIL FROM address, with no fallback to the HELO identifier.

The new tag worth applying: np

The np tag defines the policy for subdomains that do not exist at all. It closes a common spoofing gap: an attacker sending from billing.company.ca when that subdomain was never created.

Publishing np=reject costs one DNS edit and carries no risk to your legitimate mail, since by definition no service sends from a subdomain that does not exist. It is one of the rare security gains with no trade-off.

What the new specification takes away

The old pct tag let you apply the policy to a growing percentage of traffic — 10 percent, then 50, then 100. It has been removed, and the new t tag is only a testing switch, not a dial.

The staged approach described above remains right, but it now has to happen operationally: by fixing sending sources one at a time before tightening the policy, rather than by gradually exposing a fraction of the traffic.

Good configuration does not automatically buy you the inbox

SPF, DKIM and DMARC are essential, but they are not a free pass. The major providers also use domain reputation, sending IP reputation, and behaviour observed over time.

That reputation is not a universal score you can look up once a year. Each provider applies its own models and combines several signals, including:

• complaints and spam reports;
• non-existent addresses and hard bounces;
• sudden swings in sending volume;
• the history and consistency of mail associated with the domain;
• the links and domains present in messages;
• recipient engagement;
• the track record of the sending infrastructure;
• the general quality of mailing lists.

Google's real threshold, and it is stricter than most people think

Google asks senders to keep the spam rate reported in Postmaster Tools below 0.10 percent, and never to reach 0.30 percent or higher.

The nuance matters. People often cite 0.3 percent as if it were the target; it is actually the threshold beyond which the impact becomes considerably more severe. The target is three times stricter.

Three useful details:

• The rate is calculated daily, and its effect on delivery is graduated rather than binary. Keeping the rate low provides resilience against occasional spikes in user feedback.
• There is a way back. A bulk sender remains ineligible for mitigation while its rate exceeds 0.3 percent, and becomes eligible again once the rate stays below that threshold for seven consecutive days.
• Google does not track open rates and cannot verify those reported by third parties. A low open rate is not a reliable indicator of a delivery problem.

A small business sending far fewer messages can also be classified unfavourably if its mail generates complaints, uses an old list, or spikes suddenly.

Separate operational mail from marketing

Operational email and marketing campaigns need to be distinguished. An invoice, a password reset and a quote do not play the same role as a newsletter.

Using a separate subdomain for marketing sends — news.company.ca , for example — can limit a campaign's impact on the reputation of day-to-day mail. Microsoft recommends this separation for bulk sending services that are not under the company's direct control.

One clarification that often puts people at ease: one-click unsubscribe is required only for marketing and promotional messages. Transactional messages are excluded — password resets, reservation confirmations, form submission confirmations. Your invoices do not fall under that rule.

The main domain remains a critical asset. Our article on domain name ownership and renewal explains why registrar and DNS access must stay under the organization's control: that is exactly where SPF, DKIM and DMARC are published.

Why is the quote so often the message that disappears?

A quote sometimes combines several unusual factors: a new recipient, a first conversation, a large attachment, several links, and a message sent from a CRM rather than the rep's usual mailbox.

None of those makes the email bad in itself. Their combination, though, gives the recipient's filter less positive context to work with.

The problem can also sit on the client's side. Their security gateway may quarantine the PDF, block a type of link, or apply a stricter rule to new senders. An internal policy may even deliver the message to an administrator-only quarantine that the user never sees.

That is why nobody can guarantee consistent inbox placement. You can authenticate the domain properly, maintain good sending hygiene and monitor the results. The final decision always belongs to the receiving system.

Asking each client to add your address to their approved senders can rescue an isolated case. It is not a deliverability strategy. If several organizations stop receiving your mail, the cause needs fixing at the source.

Silence and a bounce do not mean the same thing

Here is a nuance that changed recently and improves diagnosis.

Gmail has moved from warning to enforcement. Mail that fails the sender requirements now receives temporary or permanent SMTP rejections rather than being quietly filtered — and the rejection code indicates which requirement failed.

In other words:

• A bounce with an error code generally points to an authentication or compliance problem. That is the good news: the information is in the rejection message.
• Silence — your message accepted, then nowhere to be found — points instead to reputation, content, or a filter at the recipient's end.

The scenario that opens this article is a case of silence. It is the hardest kind to diagnose, precisely because no system tells you what happened.

How to investigate a vanished email

A useful investigation starts from one specific message, not from the general question "is our email working?"

1. Establish the facts. Note the exact sender and recipient addresses, the time sent, the subject, the system used, and whether there were attachments. A message sent from Outlook and one sent by the CRM can show the same address while following completely different paths.

2. Check the message trace. Microsoft 365 and sending platforms keep traces that show whether the message was submitted, delivered, delayed or rejected. A "delivered" status generally means the receiving system accepted it; it does not prove it was placed in the inbox.

3. Get the full headers. If the recipient finds the message in their spam or quarantine, the full headers reveal the SPF, DKIM and DMARC results, the servers traversed, and several filtering decisions. A screenshot of the email contains none of that.

4. Check alignment, not just the "pass" results. SPF and DKIM can each show a pass while DMARC fails, simply because the authenticated domains do not match the visible address. This is common when a third-party service sends on the company's behalf without a custom DKIM signature or an aligned return path.

5. Read the rejection code if there is one. A bounce from Gmail now indicates which requirement failed. It is the fastest diagnosis available — you just have to look.

6. Look for a pattern. One blocked message can come from a rule at the client's end. Multiple failures to Gmail, Outlook or different domains point instead to an authentication, reputation or infrastructure problem. Bounces, complaints, suppressions and volume swings help reveal the pattern.

To test, use real Gmail and Outlook mailboxes you control, then examine the result and the headers. Sending in bulk to fake addresses to "see what happens" degrades your sending quality and can harm your reputation further.

The check to run this week

A smaller business can already remove much of the risk with this sequence:

1. List every domain and subdomain used to send email.
2. Inventory every source: Microsoft 365, website, CRM, accounting, marketing, e-signature, devices and line-of-business applications.
3. Confirm there is exactly one SPF record per domain, authorizing only sources still in use, without exceeding the DNS lookup limit.
4. Enable DKIM with your domain on every platform that allows it.
5. Publish DMARC in monitoring mode and have the reports analyzed.
6. Remove the pct, rf and ri tags if present in your record, and add np=reject.
7. Fix unaligned sources before moving gradually to quarantine, then rejection.
8. Separate marketing sends from operational mail where volume or risk justifies it.
9. Monitor your reported spam rate in Postmaster Tools, with 0.10 percent as the real target.
10. Check bounces, complaints and suppressions; remove invalid addresses promptly.
11. Redo the check whenever a provider, an application or DNS changes.

None of this replaces protecting the mailbox itself. Domain authentication, anti-spam policies, link and attachment analysis, MFA and monitoring all work together. Our guide to securing Microsoft 365 for business covers the other priorities around mail, identities and devices.

In closing

Email feels instant because the Send button is. Behind that button, though, every message has to prove its identity, preserve its integrity, and earn enough trust from the system receiving it.

A business that configured SPF once when it moved to Microsoft 365 has not necessarily finished the job. Its tools change. A CRM gets added, a marketing platform changes, a former provider lingers in DNS, and a web form starts sending messages. A configuration that was correct two years ago may today be incomplete, too complex — or simply written to a specification that has since changed.

The right goal is not to promise that every email will always reach the inbox. It is to be able to answer three questions clearly: who sends on behalf of our domain, is it properly authenticated, and do we find out quickly when something breaks?

Before the next important quote, the best test is therefore not to check whether it is in your Sent folder. It is to check whether your domain still deserves the trust of the systems that will receive it.

An IT project or a question?

MMO Techno can audit your sending sources, verify SPF, DKIM and DMARC, analyze the reports and trace delivery problems — without promising the impossible, but by fixing the causes that put your business email in spam unnecessarily.

Talk to an MMO Techno expert .