Why Your Invoices Go to Spam: SPF, DKIM and DMARC for a Hong Kong Retail Brand

The short answer: mail that "just disappears" is almost always mail that failed an alignment check nobody knew existed. When a third-party platform starts sending order confirmations or invoices as your domain, it has to be authorised in SPF and it has to sign with DKIM that is aligned to your domain — adding the tool to your inbox is not the same as adding it to your DNS, and that gap is the single most common cause of vanished business email.

Why did our order emails just stop arriving?

A Hong Kong consumer brand — call it a mid-size homeware and lifestyle retailer, 20 to 60 staff, selling through its own site and a couple of marketplaces — switches its customer support desk to a new third-party support platform. The rollout goes smoothly. Tickets route correctly, agents like the new inbox, and nobody on the operations team thinks of it as an email project at all, because from where they sit it is a helpdesk project.

Within a week, the complaints start. A customer calls to ask where an order confirmation is. Another says the invoice never came through and asks for it to be resent — twice. A logistics partner mentions that a shipping notification landed in their spam folder. None of this looks like one incident. It looks like several small, unrelated annoyances, and for the first few days the operations manager treats them that way: a spam-filter quirk here, a customer typo there.

It is not a coincidence, and it is not spam-filter randomness. The new platform sends transactional email — order confirmations, invoices, shipping updates — using the brand's own domain in the From address, because that is what makes the email look legitimate to the customer. To do that credibly, the platform has to be trusted by the brand's own domain the way any sender has to be trusted: listed in SPF, or signing with DKIM, or ideally both — and, just as importantly, doing so in a way that is *aligned* with the domain in the message the customer actually sees. Nobody touched the DNS when the platform was switched on, because switching on a support platform does not, on its face, look like a DNS change. It is exactly that gap — a new sender added to the product, never added to the domain's authentication — that this article is about.

This is written for the ecommerce or operations manager who is looking at a pile of "did you get my invoice?" messages and a support platform vendor who says the integration is working fine, because from the platform's side, it is. The mail sends. What happens to it after that is a DNS question, and DNS is the part nobody assigned to anyone.

The three records, and the one word that actually matters: alignment

Almost every explanation of SPF, DKIM and DMARC stops at "these are three things you need," lists what each one is, and skips the part that actually determines whether your order confirmations arrive. That part is alignment. Get the three records right individually and get alignment wrong, and mail still fails.

SPF (Sender Policy Framework) is a DNS record — a TXT record on your domain — that lists which mail servers are allowed to send mail claiming to be from you. It is checked against one specific thing: the envelope sender, sometimes called the Return-Path or the MAIL FROM address, which is a technical field used during mail delivery. This is worth being precise about, because it is the detail almost every summary skips: SPF does not check the address a customer sees in their inbox. It checks a background address the customer never looks at. A message can pass SPF cleanly while the visible From address belongs to a domain SPF said nothing about.

DKIM (DomainKeys Identified Mail) is a cryptographic signature added to the outgoing message, verified against a public key published in your DNS at a specific address — a "selector" combined with your domain, so a signature made with selector s1 on yourbrand.com is checked against a DNS record at s1._domainkey.yourbrand.com. The signature proves the message was not altered in transit and that whoever holds the matching private key sent it. Critically, the domain that gets credit for a DKIM signature — the d= value in the signature — is whatever domain the signer chooses to sign as. It does not have to match the visible From address either. A third-party platform can sign its own outgoing mail with its own domain's DKIM key and have a perfectly valid signature that has nothing to do with your brand.

That is why both of the above can be individually correct and your mail can still fail. DMARC (Domain-based Message Authentication, Reporting and Conformance) is the record that closes this gap. DMARC does not introduce a new authentication method — it takes the results of SPF and DKIM and checks one more thing: does the domain that actually passed (the SPF Return-Path domain, or the DKIM d= domain) match, or reasonably match, the domain in the From address the customer actually sees? That check is called identifier alignment, and a DMARC record can require it two ways. Relaxed alignment — the common default — accepts a match at the organisational domain level, so mail.yourbrand.com aligns with yourbrand.com. Strict alignment requires the exact same fully qualified domain on both sides. A message passes DMARC if SPF passes and is aligned, or DKIM passes and is aligned — either one is enough, but at least one of them has to actually be aligned, not merely valid.

Put plainly: your brand can have textbook SPF and textbook DKIM, both technically correct, and still fail DMARC completely, because the domain that passed each check was the *platform's* domain, not yours. That is precisely the failure mode in the scenario above, and it is worth restating because it is the part every rushed explanation leaves out: the records are not the goal. Alignment to your visible From domain is the goal, and the records are only the means.

How does adding a third-party sender actually break deliverability?

Picture the DNS state before the new platform arrived. Microsoft 365 or Google Workspace was set up correctly at onboarding, which typically means a working SPF record, DKIM enabled on the primary sending domain, and — if whoever set it up was reasonably careful — a DMARC record already published, quite possibly already at an enforcing policy, because that is increasingly the sensible default rather than the exception. Ordinary staff mail authenticates cleanly and nobody thinks about it again.

Then the support platform goes live and is configured to send order confirmations and invoices "as" the brand, because a message that visibly comes from a generic platform domain converts worse and looks less trustworthy to a customer than one that appears to come from the brand itself. The platform's outgoing mail servers were never added to the brand's SPF record. The platform may sign its own DKIM, but with its own d= domain, not the brand's — because the brand never generated and handed over a DKIM key pair for the platform to sign with. The visible From address says orders@yourbrand.com. Neither the SPF check nor the DKIM check produces a result aligned to yourbrand.com. DMARC fails.

What happens next depends entirely on the DMARC policy already sitting in the brand's DNS — which is exactly why an operations manager who has never heard the word DMARC can be the one dealing with the fallout. If the domain publishes p=reject, receiving mail servers refuse the message outright: no bounce reaches the sender in any way the platform surfaces, the order confirmation simply never exists as far as the customer's mailbox is concerned. If the domain publishes p=quarantine, the message is typically delivered to the recipient's spam or junk folder — which explains the "I found it in spam" reports mixed in with the "I never got it at all" reports; both are the same underlying failure landing on receiving systems that treat quarantine slightly differently. If the domain publishes p=none, or has no DMARC record at all, the message is more likely to be delivered, but the domain also has zero protection against anyone else sending unauthenticated mail as the brand — which is a different problem this article is not about, and the one #42 below is.

There are exactly two correct fixes, and only two. Trying to solve this by asking the platform to "just not use our domain" solves deliverability by giving up the branded sender address, which is usually not what the business wants. The two fixes that keep the branded address and make it authenticate:

Two ways to fix a third-party sender, and what each one actually requires

• Add the platform to SPF. The platform's documentation publishes an include: value for exactly this purpose — something like include:mail.platformname.com. Adding it to your SPF record authorises the platform's servers to use your envelope domain. This is the smaller change, but it only fixes the SPF half of DMARC's "either/or" — it does nothing for DKIM, and it pushes you one step closer to SPF's ten-lookup ceiling (below), which matters if you already have several senders included.
• Have the platform sign with DKIM aligned to your domain. This is the stronger fix, because DKIM alignment survives being forwarded and does not depend on the receiving server trusting the network path the mail took — SPF's weakness. Doing this properly means generating a DKIM key pair for your domain, publishing the public half at the platform's chosen selector under _domainkey.yourbrand.com, and handing the private half to the platform to sign with — sometimes done automatically through a CNAME record the platform gives you rather than a raw key, which is the more common and less error-prone pattern with most SaaS senders today.

Doing both is normal, not excessive, precisely because DMARC only needs one of them to pass — having both means a temporary problem with either mechanism does not take your mail down on its own. What is not normal, and not a fix, is adding the platform to SPF and stopping there while assuming "SPF and DKIM are basically the same thing." They check different things, they can be independently wrong, and DMARC alignment is evaluated separately against each.

What does a DMARC report actually tell you, without buying a tool?

DMARC's rua tag — an email address in your DMARC DNS record — asks receiving mail servers to send you a daily aggregate report on mail claiming to be from your domain: what passed, what failed, and from where. These arrive as XML attachments, usually zipped, and reading one by hand is entirely possible for a single incident even before you consider a monitoring service.

Inside each report, the field that matters most is source_ip, which tells you which server actually sent the message — this is how you find out that a chunk of your failing mail is coming from an IP block belonging to the support platform, rather than from anywhere suspicious. Next to it, count tells you how many messages came from that IP with the same result, which is what turns "the platform seems to be failing sometimes" into "the platform sent 4,000 messages last week and 3,850 of them failed alignment." Then there is policy_evaluated, which records what your domain's policy told the receiver to do with the message — its disposition (delivered as none, sent to quarantine, or rejected outright) alongside the dkim and spf evaluation for that specific message. Finally, auth_results shows, separately for DKIM and for SPF, which domain was actually checked and whether it passed — this is where you can see directly that DKIM passed for platformname.com while your own domain's alignment failed, which is the single clearest piece of evidence that a third-party sender is the cause rather than a broken record.

The three numbers worth watching, in order, are: total volume from a given source_ip, the proportion of that volume with a disposition other than the one you intend, and whether the auth_results domain for the failing mechanism belongs to a sender you recognise. If it does, you have found your third-party sender problem. If it does not, you may have found something else — mail claiming to be from your domain that you never sent at all, which is a different and more serious conversation.

How aggressive should the DMARC policy be — and when does going straight to reject go wrong?

DMARC's p= tag takes three values, forming a deliberate ladder rather than an on/off switch. p=none asks receivers to take no special action on a failing message but still send you reports — this is the observation stage, and it is where every domain should start, including one that has been running for years without ever having its DMARC policy checked. p=quarantine asks receivers to treat a failing message as suspect, typically routing it to spam rather than the inbox. p=reject asks receivers to refuse the message outright. A pct tag can apply any of these to a stated percentage of failing mail rather than all of it, which is the mechanism that makes a staged rollout possible rather than an all-or-nothing flip.

The reason a brand should never jump straight to p=reject on a domain with unknown senders is exactly the scenario this article opened with, just run in the other direction: if the support platform (or the invoicing tool, or the marketing sender, or the ERP that emails delivery notes) is not yet correctly authenticated, moving straight to reject does not fix anything — it makes the existing failure total and immediate, with no visibility into which sender broke first. The sequence that actually works is: publish p=none with a reporting address and read the reports for a genuine cycle of business activity — long enough to see a full month-end run, a marketing send, and ordinary day-to-day order volume — until every legitimate sender shows up authenticated and aligned; then move to p=quarantine, ideally starting at a low pct and raising it as reports stay clean; only then move to p=reject. Skipping the observation stage is how a domain "protects" itself into an outage.

What else can quietly sink deliverability once SPF, DKIM and DMARC are technically in place?

Getting the three records aligned removes the most common cause, not the only one. A few adjacent issues show up often enough at this size of business to be worth naming plainly.

A shared sending IP — common with lower-cost transactional email add-ons and some helpdesk platforms' outbound mail — means your deliverability is partly determined by every other customer sharing that IP. If one of them sends mail that gets the IP flagged, your legitimate order confirmations can be caught in the same reputation damage, through no fault of your own domain configuration.

An SPF lookup-limit overflow is a slow-motion version of the same problem this article describes, and it is worth checking for directly: SPF evaluation is capped at ten DNS lookups counted across include, a, mx, ptr, exists and redirect mechanisms — a domain that has accumulated a marketing platform, an e-commerce platform, a support platform, an accounting system and a courier notification service in its SPF record over several years can quietly exceed that limit, at which point the entire SPF check returns a permanent error and effectively stops protecting anything, for every sender listed in it, not just the newest one.

A missing or misconfigured return-path — the technical address SPF actually checks, as distinct from the visible From address — can cause SPF to evaluate against a domain nobody intended it to check, particularly when a platform sends on a subdomain it manages for you without your team ever seeing that subdomain's own SPF state.

And content that reads like a phishing attempt, independent of authentication entirely — an invoice email with an unusual sending pattern, an unfamiliar link shortener, or wording that trips a receiving server's content filters — can suppress delivery even when SPF, DKIM and DMARC all pass cleanly, because authentication and content filtering are separate systems making separate decisions on the same message.

Who should actually own this, permanently?

The clean way to divide responsibility, and the one that survives the next platform switch rather than only fixing this one, is: the DNS is yours, the platform is theirs, and the ongoing monitoring belongs in whoever manages your Microsoft 365 or Google Workspace tenant day to day. The platform's job is to tell you, in its own documentation, what SPF include value or DKIM CNAME record it needs. Your job — or your IT provider's — is to actually make that DNS change, verify it propagated and resolves correctly, and confirm the platform's mail is showing up authenticated and aligned in your DMARC reports before you consider the integration finished. Treating "the vendor said it's set up" as the end of the process, without an independent DNS check, is how this failure mode keeps recurring every time a business adds a new sender.

Three ways Hong Kong brands actually handle a new sender

• Nobody owns it, and DNS is only touched when something breaks. The platform goes live, mail starts sending, and the first anyone learns about SPF or DMARC is when a customer complains. This is the default outcome of treating a support-platform rollout as a helpdesk project rather than an email project, and it is exactly the position the brand in this article's scenario is in.
• DNS is checked once, at launch, and never watched again. Someone — often whoever set up the original Microsoft 365 tenant — adds the new platform's SPF include and calls it done. This catches the obvious case but misses drift: a platform that changes its sending infrastructure, a DMARC report nobody is reading that would have shown a second, unrelated sender quietly failing, or a lookup-limit creeping toward its cap as more tools get added over the following year.
• DNS changes go through a managed process, and DMARC reports are actually read. Every new sender is authenticated and verified against reports before go-live, the SPF record is periodically checked against its lookup limit, and the DMARC policy is advanced deliberately — none, then quarantine, then reject — rather than left wherever it happened to be set once. This is the only version of the three that catches a second failing sender before a customer does.

What does Brocent do here, and how is this different from stopping fraud?

It is worth being explicit about the difference between this article and a closely related one, because both are about SPF, DKIM and DMARC and they are not about the same problem. Our guide to a Hong Kong wholesaler's near-miss with supplier payment fraud is about the opposite direction of travel: mail arriving at your business, appearing to be from a genuine supplier, asking you to pay a different bank account. That article's SPF, DKIM and DMARC discussion is about what those records can and cannot do to stop someone else impersonating a sender to you. This article is about your own outbound mail failing to reach your own customers, because a sender you added yourself was never properly authenticated. Same three DNS records, same underlying mechanics, opposite direction, different fix.

Brocent's managed IT cloud services covers the Microsoft 365 side of this directly: setting up and managing Exchange Online with SPF, DKIM and DMARC configured as part of the deployment, alongside Safe Links, Safe Attachments and anti-spam through Microsoft Defender for Microsoft 365 — the identity-setup step in a standard rollout includes configuring SPF and DMARC for the domain from day one, rather than leaving it until a third-party sender exposes the gap. Where a business needs the anti-phishing and impersonation-detection side rather than the authentication-record side, that sits under managed email security, which layers anti-phishing and business email compromise detection, ransomware and malware blocking, and quarantine management in front of a Microsoft 365 or Google Workspace environment. Both are relevant here for different reasons: the cloud-services side gets your own authentication correct in the first place; the email-security side is what matters once you are worried about mail coming the other way, which is the subject of the article linked above rather than this one.

Neither service will authenticate a specific third-party platform for you without someone actually reading that platform's documentation and making the DNS change it asks for — that step is always specific to the sender in question, and no generic managed service replaces it. What a managed relationship changes is whether anyone is watching the DMARC reports afterward, and whether the SPF record gets audited before it quietly hits its lookup limit.

Frequently asked questions

Why did our email work before and suddenly stop?

Almost always because a new sender was added to what leaves your domain — a support platform, a marketing tool, an invoicing system — without a matching change to SPF or DKIM. The domain's existing mail, from Microsoft 365 or Google Workspace directly, keeps authenticating exactly as before; only the new sender's mail fails, which is why the problem looks intermittent rather than total.

Can we just add the platform to our SPF record and be done with it?

It helps, but it is only half of what DMARC checks. SPF passing and being aligned is one way to satisfy DMARC; DKIM passing and being aligned is the other. Adding the platform to SPF alone leaves you dependent on SPF continuing to work for that sender specifically — including the network path the mail travels — with no DKIM signature to fall back on if it does not. The more robust fix is both.

What is DKIM alignment, specifically?

DKIM alignment means the domain that gets credit for a valid DKIM signature — the d= value in the signature header — matches, or under relaxed alignment shares the same organisational domain as, the address in the visible From header the customer sees. A platform can sign mail with a technically valid DKIM signature under its own domain all day; none of it is DKIM-aligned to you unless it is signing as your domain specifically.

How long do DNS changes like this actually take?

The DNS record itself typically propagates within minutes to a few hours, depending on the time-to-live already set on the record being replaced. The safer answer for planning purposes is to allow up to 24 to 48 hours before you conclude a change has not worked, and to re-check the record directly with a DNS lookup rather than only waiting to see if customer complaints stop.

Should we set our DMARC policy to p=reject?

Eventually, if you can get there safely — but not as a first move, and not while any sender might still be unauthenticated. The safe sequence is none, then quarantine, then reject, moving to each stage only once DMARC reports show every legitimate sender passing aligned. Jumping to reject on a domain with unreviewed senders risks silently blocking exactly the mail you are trying to protect.

Do we need a dedicated DMARC monitoring service, or can we read the reports ourselves?

For a single incident, reading a handful of aggregate XML reports by hand, as described above, is entirely workable. For an ongoing domain with several third-party senders and any expectation of moving toward p=reject, a monitoring service or a managed provider that actually reviews the reports on a schedule catches drift — a new sender added later, a platform that changes its sending infrastructure — far earlier than manual review at irregular intervals.

Does this only affect Microsoft 365, or does it happen on other platforms too?

The mechanics are identical regardless of what your primary mailbox platform is — SPF, DKIM and DMARC are internet standards, not Microsoft or Google features. The scenario in this article happens exactly the same way on Google Workspace, or on any other email platform, whenever a third-party sender is added without a matching DNS change.

Who inside the business should actually own our DNS and this configuration?

Ownership should sit with whoever manages your Microsoft 365 or Google Workspace tenant day to day — internal IT, or a managed IT provider — rather than with marketing, ecommerce operations, or whichever department happened to sign up for the platform that triggered the problem. The platform vendor can tell you what it needs; only whoever controls the domain's DNS can verify it was done correctly and stays correct as more senders get added over time.

Getting the ownership right before the next platform switch

The brand in this article's scenario did not have a security problem, and it did not have a platform problem — the support platform worked exactly as designed. It had an ownership gap: a DNS change that needed to happen alongside a product rollout, and nobody whose job it was to notice that the two were connected. Fixing the immediate failure is a DNS change and a few days of reading reports. Fixing the pattern is deciding, once, who checks authentication and alignment every time a new sender gets added — before the next helpdesk platform, marketing tool or invoicing system quietly repeats the same failure.

If your team is dealing with mail that has started disappearing after a recent platform or vendor change, or you want your DNS and DMARC reports reviewed properly before you switch anything else, talk to our team. If you would rather see how this fits into a managed Microsoft 365 setup and what it costs, our pricing page and per-user managed IT plan set out the model.