Relaxed DMARC Alignment Unblocks a New Sending Subdomain
A root domain's existing DMARC record used strict alignment, and it would have blocked HubSpot's sends outright once a new sending subdomain went live. We scoped a dedicated subdomain with its own SPF and DKIM, relaxed the root domain's DMARC alignment to permit it, and cleared the subdomain through the client's corporate security filters before any mail moved through it.
Executive Summary
Context
A B2B events and exhibitions operator running 90+ annual conferences across 35 brands needed a new sending subdomain live ahead of a HubSpot migration, and its DMARC posture was built around years of unrelated corporate mail, not a fresh third-party sender.
What We Built
We split domain authentication in two: SPF and DKIM scoped to a new dedicated subdomain, and a relaxed DMARC alignment mode at the root that let HubSpot's sends pass without loosening protection for existing mail.
Tech Stack
- HubSpot Marketing Hub
- DNS (SPF, DKIM, DMARC)
Not a fit if your organisation doesn't control its own domain's DNS zone, since relaxing DMARC alignment and scoping new SPF and DKIM records both require direct authority over those records. It also assumes an IT function willing to allowlist a new subdomain in corporate mail filters ahead of go-live, since without that step the sender won't reliably reach inboxes.
The Challenge
The client's root domain carried years of unrelated corporate mail under a DMARC record set to strict alignment, which ties a message's visible From address to the domain that signed it. HubSpot's sends would show the root domain in the From address but authenticate on the new subdomain, and strict alignment rejects that mismatch, so the policy would have rejected the sends the moment they went live.
Loosening the root policy without limit risked weakening authentication for mail that already relied on strict alignment, so the fix had to isolate the new sender rather than relax protection domain-wide. The client's own corporate security filters added a second constraint. They flag unfamiliar infrastructure by default, and they can quarantine mail before a recipient sees it.
Our Approach
We considered authorising HubSpot in the root domain's existing SPF record and leaving DMARC at strict alignment, because it was the simplest option and needed no new DNS zone. It hit the same wall the policy enforces: HubSpot's infrastructure couldn't authenticate as an exact match to the root domain, so strict alignment would still have rejected it.
We built a dedicated sending subdomain instead, with its own SPF and DKIM records, and moved the root domain's DMARC policy to a relaxed mode, adkim=r and aspf=r, so that the subdomain's authentication could satisfy it. That change had to land before any send volume moved, because a misconfigured record fails mail silently.
We also worked with the client's own IT function to allowlist the subdomain ahead of warm-up. That traded a stricter default posture for a named, approved exception.
Impact
A new subdomain authenticates on its own records
Scoping SPF and DKIM to the new subdomain gave HubSpot's sends their own signature and their own SPF pass, so the client's established corporate mail kept its original protections untouched.
A relaxed root DMARC policy clears the alignment HubSpot needed
Moving the root domain's DMARC alignment to a relaxed mode let a message the subdomain signs count as aligned with the parent domain, which is what HubSpot needed to deliver at all.
Corporate security filters recognise the subdomain before any send goes out
Coordinating the allowlist with the client's own IT function cleared the subdomain through corporate mail-security review before warm-up began, rather than risking a quarantine once real volume started moving.
Authentication finished as a precondition, not a parallel task
The subdomain's SPF and DKIM, the relaxed root DMARC alignment, and the corporate allowlist were all in place before the send-volume ramp began, so the first messages arrived already authenticated.
A newly created subdomain of the client's root domain, provisioned to originate HubSpot's marketing sends and kept separate from the root domain's own mailboxes. Every authentication change that followed could be scoped there alone.
The subdomain carries its own SPF record authorising HubSpot's sending infrastructure and its own DKIM key pair, rather than inheriting either from the root domain, so HubSpot's sends authenticate on their own terms.
The root domain's DMARC record moved from strict alignment to a relaxed mode, adkim=r for DKIM and aspf=r for SPF, so a message the subdomain signs still counts as aligned with the parent domain.
Subscription-preference pages that HubSpot's sends link to were hosted on a domain distinct from both the root domain and the sending subdomain, keeping the reputation the warm-up was protecting isolated from those pages.
HubSpot's sending infrastructure couldn't produce an exact match to the root domain from a new subdomain. Under strict DMARC alignment the sends would have been rejected. Loosening the root policy without limit would have weakened mail that already relied on strict alignment. So the subdomain has its own SPF and DKIM records, and the root policy moved to relaxed alignment, "adkim=r" and "aspf=r".
FAQ
Strict DMARC alignment requires a message's visible From address to match, character for character, the domain that signed it with SPF or DKIM. A brand-new subdomain using different infrastructure can't produce that match, so the owner must relax the alignment mode or give it matching authentication, or the message gets rejected or marked as spam.
Not when it's scoped correctly. Relaxed alignment still requires SPF or DKIM to pass, and it only widens which subdomains count as a match. Pairing that root-level change with SPF and DKIM records scoped to the new subdomain means the new sender authenticates on its own credentials, so the existing mail keeps the protection it had before.
