How do I fix DMARC issues with Mailchimp and Woodpecker while using O365?
Updated on 16 Oct 2026: We clarified Mailchimp and O365 authentication checks, added message-header examples, and corrected when to use DMARC monitoring mode.
Fix this by treating Mailchimp and Woodpecker as two separate sending paths for the same domain. Mailchimp needs its own custom DKIM records so its campaigns can pass DMARC through a DKIM domain match. Woodpecker, when connected to a Microsoft 365 (O365) mailbox, needs Microsoft 365 SPF and DKIM working because the mail leaves through Microsoft. Keep an existing enforcement policy while fixing the affected sender. Use p=none for a new deployment or a deliberate temporary rollback after confirming that legitimate mail is affected by DMARC enforcement.
The SPF line in this setup should not be used as the main fix for Mailchimp. Standard Mailchimp Marketing campaigns use a platform-controlled Return-Path (envelope sender), so their SPF result does not match your visible From domain. Custom DKIM is the reliable DMARC path for Mailchimp.
For Woodpecker, keep include:spf.protection.outlook.com in SPF if Woodpecker sends through the O365 mailbox. Do not add a separate Woodpecker SPF include for that path. Confirm the two Microsoft 365 DKIM CNAMEs are published in DNS exactly as Microsoft generated them and that DKIM is enabled in Microsoft 365. A CNAME can exist in Cloudflare and still fail if the host name has been entered with the domain duplicated, proxying is enabled, the target belongs to the wrong selector or tenant, or Microsoft has not finished recognizing it.
Mailchimp and O365 authentication checklist
- Separate the senders: Check Mailchimp campaigns separately from Woodpecker and direct O365 mail. Each sender must authenticate with a passing domain match on its own.
- Fix Mailchimp with DKIM: Publish both Mailchimp DKIM CNAME records for the sending domain, then authenticate the domain inside Mailchimp before judging DMARC results.
- Keep Microsoft SPF for Woodpecker: If Woodpecker connects to an O365 mailbox and sends through Microsoft, leave the Microsoft SPF include in the domain's single SPF record.
- Enable O365 DKIM fully: The Microsoft DKIM CNAMEs must be present in DNS and DKIM signing must be enabled for the custom domain in Microsoft 365.
- Choose the monitoring policy deliberately: Use relaxed domain matching where needed. For a new deployment, start with p=none and verify all legitimate sending paths before enforcement. An existing enforcement policy does not need to be lowered to authenticate Mailchimp or enable Microsoft DKIM.
The likely root cause
When Mailchimp shows DMARC failure in this setup, the usual cause is missing or unverified custom DKIM. SPF can pass and still not help DMARC if the SPF-authenticated domain does not match the visible From domain.
Review source-level results before changing enforcement. Suped's DMARC monitoring turns aggregate reports into source-level authentication results, which gives stronger evidence than a single DNS lookup.
How DMARC evaluates this setup
DMARC passes when either SPF or DKIM passes and the passing domain matches the visible From domain. A message can show SPF pass, DKIM pass, and DMARC fail when the authenticated domains belong to the platform rather than your domain.
DMARC checks comparing Mailchimp and O365 SPF and DKIM domains with the visible From domain.
Mailchimp path
Mailchimp often passes SPF using a Mailchimp-controlled return-path domain. That result authenticates Mailchimp's sending infrastructure, but it does not prove a DMARC domain match with your visible From domain.
- Main fix: Publish and authenticate both Mailchimp custom DKIM CNAMEs.
- Expected pass: DKIM passes with a signing domain that matches the visible From domain.
Woodpecker through O365
Woodpecker is the sending interface, but Microsoft 365 is the mail system when the account is connected through O365.
- Main fix: Keep Microsoft SPF and enable Microsoft 365 DKIM for the custom domain.
- Expected pass: SPF or DKIM passes and matches the O365-connected From domain.
A single manual test can be misleading. Inspect a real message from each path: a Mailchimp campaign and both Woodpecker-sent and directly sent O365 messages, plus any other active sending path. In Authentication-Results, compare header.from with smtp.mailfrom for SPF domain matching and header.d for DKIM domain matching.
Read the headers to locate the DMARC failure
Open the full source of a message received at an external mailbox and read the Authentication-Results header added by the receiving service. These simplified examples show the difference between a platform domain mismatch and a successful custom DKIM setup.
Illustrative failure: both checks pass for a different domaintext
From: Newsletter <news@example.com> Authentication-Results: mx.receiver.example; spf=pass smtp.mailfrom=bounce.sender.example.net; dkim=pass header.d=sender.example.net; dmarc=fail header.from=example.com
Both authenticated domains belong to example.net, while the visible From domain is example.com. Adding an SPF include to example.com does not change the envelope sender. For a standard Mailchimp campaign, fix custom DKIM so its signing domain matches the From domain.
Illustrative Mailchimp result after custom DKIM is workingtext
From: Newsletter <news@example.com> Authentication-Results: mx.receiver.example; spf=pass smtp.mailfrom=bounce.sender.example.net; dkim=pass header.d=example.com; dmarc=pass header.from=example.com
The SPF domain still differs, but the passing DKIM signature matches example.com, so DMARC passes. For Woodpecker through O365, check for your custom signing domain rather than relying on an onmicrosoft.com signature. A passing SPF result that matches the From domain also satisfies DMARC.
If DMARC passes but the message lands in spam, investigate reputation and recipient engagement rather than repeatedly changing authentication records. DMARC authentication does not guarantee inbox placement.
Fix the SPF record
The SPF record should authorize active systems that use your domain in the SMTP MAIL FROM address. Publish one SPF TXT record at each domain used for MAIL FROM, which is not always the root domain. Do not paste URL formatting, angle brackets, or rich-text line breaks into the value. Other TXT records can coexist with SPF.
SPF example when Microsoft 365 is the only sender using this MAIL FROM domaindns
v=spf1 include:spf.protection.outlook.com -all
Retain any legacy provider include only while that provider still sends with this domain in MAIL FROM. Keep include:spf.protection.outlook.com because Woodpecker sends through O365. Do not add include:servers.mcsv.net merely because Mailchimp sends standard campaigns. Mailchimp's custom DKIM records provide the dependable DMARC domain-match path for this setup.
SPF cleanup checklist
- One SPF record: The domain should have one TXT record beginning with v=spf1.
- Only active senders: Remove includes for systems that no longer send with this domain in MAIL FROM.
- Lookup limit: SPF permits at most 10 lookup-causing mechanisms and modifiers during an evaluation, including nested includes and redirects. Exceeding the limit produces permerror. This is not a count of all DNS packets.
- Final mechanism: Use -all after the sender inventory is accurate.
If another agency controls DNS, Suped's Hosted SPF can reduce repeated change requests to that team. The DNS team publishes one hosted include, and future authorized-sender changes happen in Suped while the domain retains one valid SPF record.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
Fix Mailchimp DKIM and DMARC
Mailchimp needs authentication for the same domain used in the visible From address. Its current manual flow provides two DKIM CNAME records and one DMARC TXT record. Domain verification proves access to an address, while domain authentication publishes the DNS records needed for DKIM with a matching domain. In Mailchimp, open Account & billing, then Domains, and start authentication for the verified sending domain. Copy the records shown in that account rather than reusing selectors from another account.
Keep one DMARC record
If _dmarc.example.com already has a DMARC TXT record, do not add Mailchimp's suggested value as a second record. Preserve its reporting address and existing enforcement policy unless a deliberate policy change is required. Multiple DMARC records at the same name make policy discovery fail.
|
|
|
|---|---|---|
Two custom DKIM CNAMEs | Matching DKIM domain | |
Microsoft 365 SPF and custom DKIM | Passing SPF or DKIM with a matching From domain | |
SPF and DKIM | Passing SPF or DKIM with a matching From domain | |
Provider DKIM | Matching DKIM domain |
Sender paths and the authentication result to expect.
If Mailchimp says the domain is not authenticated, check the CNAME host fields first. Some DNS panels expect only the selector host, while others accept the full host name. Entering the full host where the panel appends the domain creates a duplicated name, so Mailchimp cannot find the record.
Mailchimp domain authentication screen with DKIM CNAME records and verification status.
- Verify the sending domain: Complete Mailchimp's email-domain verification for the exact domain in the campaign From address.
- Copy both DKIM records: Open Mailchimp's manual domain authentication instructions and copy both CNAME host and target pairs. Keep Microsoft's selectors in place; Mailchimp uses separate selectors, so both providers can sign for the same domain.
- Publish in Cloudflare: Add both CNAMEs as DNS-only records. Do not proxy email authentication CNAMEs.
- Authenticate in Mailchimp: Keep a single DMARC TXT record and complete Mailchimp's authentication check. Mailchimp documents a validation window of up to 48 hours, although many changes validate sooner.
- Send a real campaign test: Inspect the headers and confirm DKIM passes with a signing domain that matches the visible From domain.
After the CNAMEs are live, use aggregate reports to confirm the production result. Suped's DMARC source breakdown shows whether Mailchimp changed from a domain mismatch or failure to a DKIM pass with a matching domain.
Fix Woodpecker through O365
For Woodpecker connected to O365, the important question is where the message is sent. With Woodpecker's Microsoft mailbox connection, Microsoft 365 is the sender for SPF and DKIM purposes. The domain therefore needs Microsoft 365 SPF and custom-domain DKIM, even though Woodpecker is the interface used to create the campaign. If Woodpecker uses a custom SMTP connection instead, confirm the actual outgoing server before applying these Microsoft-specific records.
Follow Microsoft's setup path for Microsoft 365 DMARC and DKIM, then verify with an actual Woodpecker-sent email. A DNS lookup alone does not prove Microsoft is signing the message with the custom domain.
Microsoft 365 DKIM hostnames with tenant-specific targetsdns
selector1._domainkey.example.com CNAME <Selector1CNAME shown by Microsoft 365> selector2._domainkey.example.com CNAME <Selector2CNAME shown by Microsoft 365>
For custom domains added since May 2025, Microsoft can generate targets ending in dkim.mail.microsoft with a dynamic partition value. Older domains can retain targets under the tenant's onmicrosoft.com domain. Do not construct either target manually. Copy the exact Selector1CNAME and Selector2CNAME values shown for the domain in Microsoft 365.
Check DKIM configuration in a connected Exchange Online PowerShell sessionpowershell
Get-DkimSigningConfig -Identity example.com | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME
Replace example.com with the custom sending domain. Microsoft documents Enabled: True and Status: Valid for an enabled configuration. CnameMissing means Microsoft has not detected the required CNAME records. Check both DNS values before enabling signing, then send a fresh message to an external recipient.
Separate CnameMissing from disabled DKIM signing
- Wrong host field: The DNS panel added the domain again, creating a host like selector1._domainkey.example.com.example.com.
- Proxy enabled: Cloudflare CNAMEs used for email authentication must be DNS-only, not proxied.
- Wrong target format: A target was constructed from an old example instead of copied from this domain's Microsoft 365 DKIM settings.
- Signing disabled: If the CNAMEs resolve correctly but DKIM is disabled, enable signing in Microsoft 365. A disabled setting is a separate issue from Microsoft being unable to find the CNAMEs.
If Woodpecker still fails verification after Microsoft DKIM is live, send a message to a mailbox you control and inspect Authentication-Results. Compare header.from with smtp.mailfrom and header.d. If an onmicrosoft.com domain signs instead of the custom domain and SPF also lacks a domain match, DMARC fails.
Choose a DMARC policy while fixing authentication
For a new DMARC deployment, begin with p=none. For a domain already enforcing DMARC, repair the sender under the existing policy unless headers and delivery evidence justify a temporary rollback. Monitoring mode requests no DMARC-based quarantine or rejection, so it provides less protection against unauthenticated use of the domain. Keep ruf only if you have a defined failure-reporting need and controls for message-level data. Aggregate rua reports provide the main operational view for this repair.
Monitoring record for a new deployment or deliberate temporary rollbackdns
Host: _dmarc.example.com Type: TXT Value: v=DMARC1; p=none; rua=mailto:reports@example.com; adkim=r; aspf=r
Replace reports@example.com with an address that accepts and processes aggregate XML reports. When using Suped for DMARC reporting, use the destination provided for your domain and verify any required external reporting authorization. A missing authorization record at the report destination prevents participating receivers from sending reports there.
Relaxed domain matching, shown as adkim=r and aspf=r, is the default and allows the authenticated identifier and visible From domain to share the same organizational domain. Strict matching requires an exact domain match. For example, mail.example.com matches example.com under relaxed matching, but not under strict matching. A sending subdomain still needs its own applicable SPF and DKIM configuration; those records are not inherited from the root.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
If the record needs to be rebuilt, use the DMARC generator and publish one TXT record through whoever manages DNS. When an agency controls DNS, send the full host, type, and value in one request.
When to move back to quarantine
Move from p=none to p=quarantine after reports cover your normal sending cycle and show all legitimate sources passing through SPF or DKIM with a matching domain. Investigate failures belonging to authorized mail; spoofed traffic does not need to pass. Monitor the full quarantine policy after the change. Do not rely on percentage sampling.
Apply the current DMARC standard
RFC 9989 superseded RFC 7489 and RFC 9091 in May 2026. Records still use v=DMARC1. The core pass rule is unchanged: a passing SPF or DKIM domain must match the visible From domain. RFC 9990 defines aggregate reporting, and RFC 9991 defines failure reporting.
- Percentage sampling: pct is historic. Receivers implemented intermediate percentages inconsistently, so use report evidence rather than percentage sampling to plan enforcement.
- Testing flag: t=y requests one policy level less enforcement. Older receivers can ignore the tag, so it is not a dependable safeguard for a repair.
- General-purpose domains: RFC 9989 advises against p=reject for domains used for general-purpose email because indirect mail paths can break authentication. Review those paths before choosing enforcement.
- Monitoring and repair: Use p=none for a new deployment or a deliberate temporary rollback. Keep existing enforcement when repairing a sender does not require a rollback.
Test each sending path in order
Stop changing several records at once. Make one change, send one real message through the affected path, and inspect the result. This avoids the loop where SPF, DKIM, and DMARC are edited together and the effective change cannot be identified.
- Inventory senders: List Mailchimp campaigns, Woodpecker through O365, direct O365 mail, and every other active sender, including transactional and legacy systems.
- Validate DNS: Check the single SPF and DMARC records plus every DKIM CNAME in public DNS, not only inside admin portals.
- Send real tests: Send one message through each path and inspect Authentication-Results headers.
- Compare identifiers: Match header.from against smtp.mailfrom for SPF and header.d for DKIM.
- Read reports: Use aggregate DMARC data to confirm volume, source IPs, and domain-match results over a normal sending cycle. Reports commonly arrive daily and do not provide an immediate result for a single test.
- Apply enforcement: For a domain in monitoring mode, move to quarantine only after authorized sources pass DMARC. Keep an existing enforcement policy unless a confirmed delivery problem requires a deliberate change.
Suped's DMARC reporting shows source IPs and domain-match results with issue-resolution steps. Use it to confirm Mailchimp's custom DKIM and Microsoft 365 authentication. Woodpecker mail sent through O365 can share Microsoft's source IPs and authentication identifiers with direct O365 mail, so use controlled test messages and sending logs to distinguish those paths. When an agency manages DNS, send the exact record host, type, and value with the relevant failure evidence.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Cloudflare DNS checks that matter
Publish these records at the authoritative DNS provider for the domain. Cloudflare dashboard entries have no effect if the domain uses another provider's nameservers. Email authentication CNAMEs should be DNS-only, and their host and target must match the values generated for the sending domain.
|
|
|
|---|---|---|
SPF | Two records | Merge active sources |
DMARC | Two records | Keep one _dmarc TXT |
DKIM | Proxied CNAME | Set DNS-only |
DKIM | Domain doubled | Use the expected host form |
O365 DKIM | Constructed target | Copy tenant values |
Common DNS mistakes that break verification.
Run a domain health check after the agency updates DNS. Check record syntax, duplicate DMARC or SPF records, and SPF lookup limits. For DKIM, check each provider-issued selector explicitly; a domain-only lookup cannot discover every possible selector.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
DNS visibility is only the configuration check. The final proof is a real message where Authentication-Results shows DMARC pass and an authenticated identifier matches the visible From domain.
Views from the trenches
Best practices
Authenticate each authorized sender before tightening the domain policy to quarantine.
Use real sent messages to confirm domain matching, not only DNS or portal checks.
Keep Microsoft SPF when sales tools send through a connected O365 mailbox account.
Common pitfalls
Treating Mailchimp SPF as the DMARC fix leaves DKIM domain matching unresolved later.
Publishing DKIM CNAMEs with the domain doubled causes silent verification failures.
Moving to quarantine before reports are clean can block legitimate campaign mail.
Expert tips
Use relaxed domain matching where a sending path needs it, then verify real messages.
Remove old SPF includes only after confirming the provider no longer sends your mail.
Review Mailchimp and Microsoft sources separately, using test headers to locate failures.
Marketer view
Marketer from Email Geeks says custom DKIM for Mailchimp is the direct fix when campaign mail lacks a DMARC domain match.
2024-08-06 - Email Geeks
Marketer view
Marketer from Email Geeks says Mailchimp SPF is often not the deciding factor because Mailchimp uses its own SPF domain.
2024-08-07 - Email Geeks
Frequently asked questions
No. Keep it if Woodpecker sends through a connected O365 mailbox. Microsoft is the sending system, so SPF should authorize Microsoft. Do not add a separate Woodpecker include for the same path.
Mailchimp DMARC success usually depends on custom DKIM with a matching domain, not an SPF include on your visible From domain. Publish both CNAMEs provided by Mailchimp and authenticate the sending domain.
No. A domain must have one DMARC TXT record. If a record already exists at _dmarc, preserve its policy and reporting destination rather than publishing a second record.
Not automatically. p=none is monitoring mode for a new deployment or a deliberate temporary rollback after confirming legitimate mail is affected. It does not request DMARC-based quarantine or rejection. Keep existing enforcement when you can repair the sender under that policy.
Check the authoritative DNS zone, exact CNAME host and tenant-generated target, DNS-only status, and propagation. In Microsoft 365, distinguish CnameMissing from disabled DKIM signing. The final check is an externally received Woodpecker message with passing custom-domain DKIM or matching SPF.
No. RFC 9989 makes pct historic because receivers applied intermediate percentages inconsistently. For a domain in monitoring mode, repair authorized sending paths before applying and monitoring quarantine. An already enforced domain does not need to switch to monitoring merely to fix one sender.
