How to authenticate email for marketing

Every ESP has its own wizard, its own record names, and its own vocabulary for the same three protocols. Strip the branding away and the job is identical everywhere: prove to receiving mailbox providers that mail carrying your domain in the From header was really sent by you. SPF does it by listing permitted sending servers, DKIM by cryptographic signature, and DMARC by telling receivers what to do when both fail.

The part the wizards undersell is alignment. Your ESP's shared infrastructure can pass SPF and DKIM all day using the ESP's own domain; that satisfies the protocol and does nothing for yours. Authentication only counts for DMARC when the passing identity matches your From domain, which is why every step below pushes toward custom domain signing rather than platform defaults. The mechanics of that gap have their own page at /learning/email-questions/why-is-dmarc-failing-but-spf-passes.

This page is the how. If you are still deciding whether DMARC is worth the effort for a marketing program, the why lives at /learning/email-questions/does-dmarc-affect-email-marketing. And if you are here because Mailchimp campaigns are already landing in spam, the troubleshooting path is /learning/email-questions/mailchimp-emails-going-to-spam.

Marketing mail is your highest-volume, highest-complaint stream. Putting it on a subdomain such as send.yourdomain.com or mail.yourdomain.com keeps its reputation ledger separate from the corporate mail your team sends person-to-person, so a rough campaign week cannot drag payroll notifications into spam. Klaviyo's branded sending domain flow is built around exactly this, and its doc names send. as the most commonly used choice; HubSpot's connection flow likewise expects a subdomain like info.domain.com.

The subdomain also simplifies SPF. Your root domain's SPF record already carries your mail provider and whatever else accumulated over the years, and SPF's 10-DNS-lookup ceiling is closer than most teams think. A fresh subdomain starts with one include and stays readable. If your root record is already bumping the limit, that problem has its own page at /learning/email-questions/what-is-spf-flattening.

One thing a subdomain does not do is exempt you from DMARC. By default the organizational domain's policy covers subdomains (the sp= tag can split them; see /learning/glossary/dmarc-sp), and receivers evaluate alignment against the From domain your recipients actually see. Treat the subdomain as reputation isolation, not policy escape.

Most ESPs sign every message with DKIM out of the box, using their own domain as the signing identity (d= tag). That signature is valid and completely useless for your DMARC, because the signing domain does not match your From domain. Custom domain signing, which is what those CNAME records in each wizard exist for, moves the signature onto your domain so DKIM passes aligned.

Aligned DKIM matters more than aligned SPF for marketing mail for one practical reason: forwarding. When a recipient's mail is auto-forwarded, SPF breaks (the forwarder's server is not in your record) but a DKIM signature survives intact. A domain with aligned DKIM keeps passing DMARC through forwarders; a domain leaning on SPF alone does not. Get DKIM aligned first, treat aligned SPF as the second witness.

The CNAME pattern also handles key rotation for you. The record in your DNS points at a host the ESP controls, so the ESP can rotate the underlying keys (Klaviyo's marketing selectors are km1 and km2, per its setup doc) without you touching DNS again. What a selector is, and how receivers use it to find the key, is covered at /learning/glossary/dkim-selector.

Publish a TXT record at _dmarc.yourdomain.com reading v=DMARC1; p=none; rua=mailto:reports@yourdomain.com. The p=none policy changes nothing about delivery yet; the rua address is the whole point at this stage, because it makes every major receiver send you aggregate reports listing which sources sent as your domain and whether they aligned. Reading those XML files is its own skill; the walkthrough lives at /learning/email-questions/what-are-dmarc-aggregate-reports.

Give the reports two to four weeks. Marketing domains almost always surface surprises: the ESP you knew about, plus a survey tool, a billing system, and a sales-engagement platform someone connected in 2023. Each legitimate source needs SPF or DKIM aligned before you tighten policy, or its mail starts failing when you do.

Then ramp: p=quarantine (optionally staged with pct=), then p=reject. Enforcement is where the anti-spoofing value lives; a p=none record is a monitoring subscription, not a defense. The full migration sequence, including the pct staging and rollback tells, is at /learning/email-questions/how-to-move-from-dmarc-p-none-to-p-reject.

The records you published today describe today's stack. Marketing stacks churn: a new landing-page tool starts sending, an agency connects its own platform, an ESP migration changes selectors. Each change is a fresh chance for unaligned mail, and a p=none record will report the drift without ever stopping it.

The end state worth reaching is DMARC at p=reject with every legitimate sender aligned, and something watching the reports so the next tool someone connects becomes a task instead of a deliverability incident. Palisade's AI agent does that walk for you: hosted SPF, DKIM, and DMARC records, continuous report analysis, and enforcement to p=reject executed rather than recommended.

Marketing domains are the tenant domains most likely to have senders you were never told about, because marketing teams connect tools without opening tickets. Standardize the pattern across clients: one sending subdomain per tenant, custom DKIM per ESP, DMARC with rua on every organizational domain, and a policy ramp you can show in the QBR. Palisade hosts and manages the SPF, DKIM, and DMARC records per client domain, reads the aggregate reports continuously, and walks each domain to p=reject automatically, with ConnectWise, HaloPSA, and Autotask integrations so new-sender alerts land in your PSA queue. Pricing is per domain ($9/month, $7 at 100+ domains, $5 at 1,000+), and your own MSP domain is a free NFR domain to run the play on first.