Do I need to add my ESP's SPF include to my domain?

Usually not, and with Mailchimp it actively does not help. Mailchimp's documentation states that adding its include is not required for authentication and does not provide DMARC alignment, because the envelope sender stays on a Mailchimp domain. DKIM signing with your own domain is what produces alignment. Every include you add also spends one of the ten DNS lookups RFC 7208 allows before SPF returns permerror.

Why does my report show SPF passing but DMARC failing?

Because passing and aligning are two different tests. A marketing platform sends from its own infrastructure with its own envelope sender domain, so that domain's SPF record validates correctly. DMARC then compares that domain against the one in your visible From header, finds they do not match, and treats SPF as unaligned. Klaviyo documents this behaviour explicitly for its own sending. The fix is DKIM signed with your domain, not more SPF.

Can I use strict DMARC alignment with HubSpot?

Only if your sending domain is a subdomain. HubSpot states that under strict alignment a custom return path is supported for an address such as user@mail.company.com but not for user@company.com. HubSpot recommends keeping both adkim and aspf set to r for relaxed alignment, which is the sensible default for most small businesses because it lets subdomain senders align with the root domain.

Mailchimp, HubSpot, Klaviyo: Fix DMARC Alignment

The bounce that starts this call

A client forwards us a screenshot. The monthly newsletter went out and a good chunk of it came straight back. The copy is fine, the list is clean, and those same people receive mail from that same domain every day without trouble. The only thing that changed is that the newsletter now leaves through a marketing platform, and the domain finally has a DMARC policy with teeth.

Almost every time, this is not a reputation problem and not a content problem. It is alignment. The platform authenticated the message perfectly well, using its own domain, and DMARC asked a different question: does any of that match the address the reader actually sees in the From line? Mailchimp, HubSpot and Klaviyo each break this in their own way, and each has a specific fix.

Alignment, in one paragraph

SPF checks the envelope sender, the hidden address that bounces go to. DKIM checks the signature and the domain in its d= tag. DMARC ignores both of those results on their own and asks whether either identifier matches the domain in the visible From header. RFC 7489 calls this Identifier Alignment, and it has two modes: relaxed, where the organizational domains have to match, so a subdomain counts; and strict, where only an exact DNS match counts. Only one of SPF or DKIM has to pass and align for DMARC to pass. Gmail's sender guidelines say the same thing for bulk senders: the From domain must be aligned with either the SPF domain or the DKIM domain.

Now the part that explains all three platforms at once. A marketing platform sends from its own infrastructure, so it uses its own domain for the envelope sender. SPF passes, because the platform's domain has a valid SPF record, and then fails alignment, because that domain is not yours. DKIM is where you win. Every fix below is really the same fix: get the platform signing with a d= value inside your domain.

What we check before touching DNS

Guessing wastes a week of propagation time, so we start with evidence.

Pull one real message that the platform sent, open the full headers, and read the Authentication-Results line. The d= value tells you immediately whether the signature belongs to you or to the vendor. Our header analyzer does this in one paste.
Confirm the exact From address the campaigns use, including whether it sits on the root domain or a subdomain. That single detail decides what is possible later.
Check inside the platform whether a sending domain was ever set up, or whether it is still running on the vendor default.
Pull the last two weeks of DMARC aggregate reports, so we can see every sender at once instead of the one that complained.

Only then do we open the DNS panel.

Mailchimp: two CNAMEs, and the SPF include that does nothing

Mailchimp's domain authentication is two CNAME records for DKIM plus one TXT record for DMARC. In the app you get a Name (Host) and a Value for CNAME 1 and CNAME 2. Copy them out of the app rather than retyping a selector you found in an article, because the pair is generated for your domain.

The trap is SPF. Mailchimp publishes an include, include:servers.mcsv.net, and half the internet still tells people to add it. Mailchimp's own documentation is blunt about this: adding that include is not required for authentication with Mailchimp and will not provide DMARC alignment, because Mailchimp sends from its own servers, so the envelope sender does not match your From address. The CNAMEs are what buy you alignment. The include just spends one of your ten SPF lookups.

The failure we find most often on client domains: somebody added the SPF include years ago, ticked the box mentally, and never added the DKIM CNAMEs. SPF passes, nothing aligns, and the day DMARC moves off p=none the newsletter starts bouncing.

One more thing worth separating. Mailchimp Transactional, the product that used to be Mandrill, is configured on its own, with its own sending domains. Fixing the marketing side does not fix receipts and password resets leaving through the transactional side. We check both.

HubSpot: connect the sending domain, then read the strict-mode footnote

HubSpot wants you to connect an email sending domain, which sets up DKIM through two CNAME records, an SPF TXT record, a DMARC TXT record, and a subdomain that carries the return path. HubSpot's documentation explains why that last one matters: bounce messages go to the subdomain you connect as your return path, which is what allows SPF alignment rather than just an SPF pass.

There is a footnote here that costs people a day if they miss it. HubSpot states that under strict DMARC alignment, a custom return path is only supported when your sending domain is a subdomain. Sending as user@mail.company.com works. Sending as user@company.com does not. HubSpot's own guidance is to keep both alignment flags relaxed:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; adkim=r; aspf=r; rua=mailto:dmarc@example.com"

Relaxed is the right default for almost every small business anyway, because it lets a subdomain sender align with the root domain. Strict mode is something you graduate into once you know every sender by name.

There is also a failure that reads as amateurish long before DMARC gets involved. If you send from a domain that was never connected, HubSpot rewrites the address to one of its own managed domains, so the recipient sees something shaped like user=yourcompany.com@hs-domain.com. Nobody replies to that, and when a client shows us that From address we know exactly where to start.

Klaviyo: get off the shared sending domain

Klaviyo accounts start out sending from a shared Klaviyo domain, which already carries valid SPF and DKIM records. The messages are properly authenticated. They are authenticated as Klaviyo. Your From address is not involved in that signature, so the moment your domain enforces DMARC, those campaigns fail.

The fix is a branded sending domain, which Klaviyo also calls a dedicated sending domain. You pick an unused subdomain, something like send for marketing or updates for transactional, and Klaviyo generates the records. There are two routing options and they produce different DNS work:

Dynamic routing uses NS records. You delegate the subdomain to Klaviyo, which then manages the records under it. Klaviyo recommends this option for sending performance.
Static routing uses CNAME records, and is the option to pick when your DNS provider cannot host NS records for a subdomain.

Klaviyo describes the set as up to three CNAME records or four NS records, plus one TXT record to verify ownership. Either way the records cover DKIM and SPF for that subdomain, and propagation can take up to 48 hours, so do not judge the setup twenty minutes after saving.

Two practical notes from client work. First, some DNS providers refuse underscores in a CNAME host name, and Klaviyo's records need them; Klaviyo's own troubleshooting says to ask your provider to create the record. Second, delegating a subdomain by NS record is a real decision, not a formality. It is fine for a subdomain that exists only to send campaigns, and it deserves a conversation if that subdomain does anything else. When a client is uneasy about delegating, static routing reaches the same alignment result.

Klaviyo is also refreshingly clear about the SPF confusion: SPF on the return path will always pass with Klaviyo, and your reports may still show it failing alignment, because the return path domain does not match your From domain. That is the whole article in one sentence, from the vendor.

Seeing all three in your DMARC report

Aggregate reports are where this stops being guesswork. Each row groups messages by source and tells you the SPF result, the DKIM result, and, separately, whether each one aligned. The pattern to look for is a row with SPF pass, DKIM fail, and a volume that matches your campaign size. That is an unaligned platform, every time.

Compare the header_from value against the DKIM domain in the same row. If the DKIM domain is the vendor's, the sending domain setup was never finished. If the DKIM domain is yours and the row still fails, look at whether you set strict alignment on a root-domain From address, which is the HubSpot footnote above.

If the XML is new to you, we wrote a line-by-line walkthrough in how to read a DMARC aggregate report.

Your SPF lookup budget after all this

Here is the quietly good news. None of these three fixes requires you to add an include to your root SPF record. Mailchimp says its include is neither required nor useful for alignment. Klaviyo's branded sending domain records handle SPF for that subdomain. HubSpot's SPF record belongs to the sending domain you connect.

That matters because RFC 7208 section 4.6.4 limits SPF evaluation to ten terms that trigger DNS lookups, and requires a permerror once you cross it. Most receivers treat a permerror the same as having no SPF at all, and a domain that stacked three platform includes plus a mail host plus an invoicing tool is usually already over the line. We cover the counting and the ways out in the SPF too many DNS lookups guide. The posture we aim for is simple: DKIM alignment configured per platform, and a root SPF record that only describes the mail your people send by hand.

What we watch after the records go in

Fixing alignment is a day of work. Keeping it is a habit.

Send a real campaign to a seed address and read the headers again. The green checkmark inside the platform usually only verifies that the DNS record resolves.
Give it two weeks of aggregate reports before tightening the policy. Marketing sends on a monthly rhythm, so a single week can hide an entire sender.
Watch for records left behind. When a company changes platforms, the old CNAMEs usually stay in DNS pointing at a vendor that no longer serves them. Remove them.
Move the policy up in steps rather than in one jump. We wrote the ladder out in moving DMARC from p=none to p=reject.

How Guanacos Tech helps

We do this for small and mid-sized companies in North America and Latin America, in English and Spanish. Typically it starts as one bouncing newsletter and turns into a full inventory: every system sending as your domain, which ones align, which ones only look like they do, and a policy you can actually enforce without breaking invoices. If you want to check your own domain first, the DMARC analyzer and the email troubleshooter are free and need no account. If you would rather hand it over, see how we approach deliverability and how we work, or book a call and bring the bounce message with you.

Vendor documentation for Mailchimp, HubSpot and Klaviyo checked 10 September 2026.

Why Mailchimp, HubSpot and Klaviyo fail DMARC alignment (and the exact fix for each)