A client’s campaign platform may show a successful send. Their CRM may report no technical errors. Yet a growing share of messages never reaches the inbox because the visible From address does not align with the domains that authenticate the message. That is a DMARC alignment failure, and it becomes far more costly once a domain moves to a quarantine or reject policy.
For agencies and web teams, this is not just an email administration problem. It can affect order confirmations, password resets, lead follow-ups, invoices, newsletters and carefully timed campaigns. The operational risk is compounded when one client has several sending platforms, multiple trading domains and a DNS zone managed by someone else.
What DMARC alignment actually checks
DMARC sits on top of SPF and DKIM. SPF checks whether the server sending a message is authorised by a domain in the message’s return path. DKIM checks whether a cryptographic signature on the message is valid for the domain named in its `d=` tag. DMARC then asks a further question: does either authenticated domain align with the domain the recipient sees in the From field?
A message can therefore pass SPF or DKIM and still fail DMARC. This catches a common misconception: authentication alone is not enough. The authenticated identity needs to match, or be an acceptable subdomain match for, the public-facing sender identity.
Take a newsletter sent as `[email protected]`. If the email platform uses `bounce.vendor-mail.com` as its SPF return-path domain, SPF may pass but not align with `client.co.uk`. If the platform also signs with `client.co.uk`, DKIM can align and DMARC passes. If it signs only with `vendor-mail.com`, both routes fail alignment and DMARC fails.
That distinction matters because organisations often configure SPF, see a pass in a testing tool, and assume the job is complete. It is not complete until the results show an aligned SPF pass or an aligned DKIM pass.
Why a DMARC alignment failure appears after a change
Most failures have a trigger. A new marketing platform, helpdesk, booking engine or e-commerce application starts sending from the client’s main domain without its authentication being fully configured. A supplier changes its sending infrastructure. A developer updates DNS but omits a DKIM record. Or a brand team uses a new From address that has not been accounted for in the existing setup.
The more domains and platforms a client operates, the more likely this becomes. One organisation may send customer messages through Microsoft 365, transactional email through an e-commerce platform, marketing through a CRM, support replies through a helpdesk and invoices through an accounting system. Each sender needs to be treated as a separate authenticated mail stream, even when all of them display the same brand domain.
Alignment settings can also make a previously acceptable configuration fail. DMARC supports relaxed and strict alignment. Relaxed alignment permits an organisational-domain match, so `mail.client.co.uk` can align with `client.co.uk`. Strict alignment requires an exact match. Strict mode has a place where domain control needs to be tightly constrained, but it requires deliberate configuration and closer change control.
Start with the message headers, not the sending dashboard
When a client reports missing emails, inspect headers from a message that arrived in a recipient mailbox or a controlled test inbox. The sending platform’s dashboard is useful, but it cannot tell you how the recipient evaluated authentication.
Look for the `Authentication-Results` header. It typically reports SPF, DKIM and DMARC outcomes, along with the domains involved. You are looking for more than `spf=pass` or `dkim=pass`. Identify the SPF `smtp.mailfrom` domain and the DKIM `header.d` domain, then compare each against the visible `header.from` domain.
If DMARC fails, establish whether SPF, DKIM or both failed alignment. This narrows the remedy quickly. An SPF-only issue may be expected when a provider controls its own bounce domain, provided DKIM is correctly configured to sign with the client’s domain. A failure on both methods is more urgent: the message has no aligned authentication route.
Also check the DMARC record itself. A record at `_dmarc.client.co.uk` defines the policy and reporting addresses. Syntax errors, duplicate records and a record published on the wrong domain can all create confusion. The policy tag matters too. With `p=none`, recipients may still deliver a failed message, though placement can suffer. With `p=quarantine` or `p=reject`, the consequence becomes more visible and less predictable across recipients.
Fix the aligned identity, not just the symptom
The cleanest fix is usually to configure DKIM for every legitimate third-party sender using the client’s own domain or an aligned subdomain. Most reputable email platforms provide DKIM selectors and CNAME records for this purpose. Publish the records exactly as supplied, allow DNS propagation, then send a fresh test message and verify that the signature passes and aligns.
SPF can provide the aligned pass instead, but it is often less flexible for third-party services. SPF authorisation is evaluated against the return-path domain, which a provider may not let you customise. It also has a ten-DNS-lookup limit. Adding every new sender to an already complex SPF record can create a different deliverability failure when that limit is exceeded.
For that reason, DKIM is commonly the more durable alignment mechanism for marketing and transactional platforms. It does not mean SPF should be neglected. SPF still protects the return path and offers a valuable second authentication signal. The practical target is for every legitimate stream to have aligned DKIM, aligned SPF where feasible, and a clear owner for the related DNS records.
Do not solve a failing service by weakening the entire DMARC posture. Moving from `p=reject` back to `p=none` may restore delivery while you investigate, but it also removes protection against direct impersonation. If business continuity demands a temporary change, document it, set a review date and restore enforcement as soon as the legitimate sender is configured.
A practical workflow for agency teams
Treat deliverability as an inventory and monitoring discipline, not a one-off DNS task. Build a sender register for each client: visible From domain, sending platform, purpose, SPF domain, DKIM signing domain, owner and last verified date. It gives account managers, developers and client stakeholders one reference point when a new system is introduced.
Then use a controlled rollout process. Before a new service sends to a live audience, confirm its DNS requirements, publish and validate its DKIM records, test real messages, and check alignment in the received headers. This is particularly important for password-reset and receipt emails, where a delivery issue can look like a broken website or failed purchase.
DMARC aggregate reports help expose senders that the register missed. They show which IP addresses and domains are sending mail that claims to be from the organisation, and whether those streams pass SPF, DKIM and alignment. The reports can be noisy, so focus first on meaningful volume and legitimate services that are failing. Low-volume unauthorised sources may be spoofing attempts rather than configuration work.
Portfolio-level monitoring is valuable here because client DNS changes are easy to miss. TLDTrack can help teams keep DNS, DMARC and email deliverability checks alongside the uptime, certificate, content and security monitoring already used across a website estate. That reduces the chance that a marketing change creates an inbox problem days after launch.
Common fixes that do not hold up
Adding every possible provider to SPF is not a sustainable strategy. It can exceed the SPF lookup limit, make the record difficult to audit and still leave messages unaligned. Likewise, copying a DKIM record from another client or domain will not work: selectors and keys are specific to the provider and sending domain.
Another weak fix is assuming a subdomain will automatically be covered. Whether `updates.client.co.uk` aligns with `client.co.uk` depends on the alignment mode and the specific identities used by the sender. Test the exact From address and exact platform configuration rather than relying on naming conventions.
Finally, do not confuse a valid-looking DMARC record with a working enforcement programme. A `p=none` record can be a sensible observation phase, especially for a complex estate. But if it remains there indefinitely, the organisation receives reporting without the full anti-spoofing protection DMARC was designed to provide.
The useful habit is simple: whenever a client asks a new tool to send as their brand, make aligned authentication part of the launch checklist. A five-minute header check before the first campaign is far easier than explaining why a legitimate message was rejected when the campaign is already live.
