[ Email sender guides ]

Adobe Marketo SPF, DKIM and DMARC setup, step by step

By the EmailAuth research team · 11 min read

On this page

On this page: Confirm the sending route before changing DNS · Configure custom DKIM in Marketo · Add SPF only at the intended DNS owner · Decide whether you need a branded return path · Preserve or establish DMARC safely · Verify public records and a delivered campaign · Troubleshooting and frequently asked questions · Completion criteria and review boundary

For Marketo Engage, configure custom DKIM for the actual From domain and validate it in Admin → Email → SPF/DKIM. Adobe documents include:mktomail.com for SPF authorization, but adding that include to your visible From domain does not make a Marketo-owned Return-Path align. Use aligned DKIM for DMARC, or arrange an eligible branded return path with Adobe. Adobe authentication setup.

Confirm the sending route before changing DNS

This guide covers outbound email sent by Adobe Marketo Engage. It does not configure Adobe Campaign, Journey Optimizer, a connected salesperson's mailbox, or every system connected to your CRM. A Marketo landing-page domain or tracking-link CNAME is not the same as its email-signing or bounce domain. Adobe treats those configurations separately. Marketo protocol configuration.

Build a change worksheet before requesting publication:

Item Record for your implementation
Instance and route Marketo instance, campaign type and shared/trusted/dedicated IP arrangement
Visible From Exact domain after the @ sign, including any marketing subdomain
DKIM Selected selector, signing domain and account-generated public TXT value
Envelope sender Current Return-Path domain; proposed branded domain if applicable
DNS control Authoritative DNS provider, responsible administrator, change window
Evidence Before/after records, provider status, message ID and recipient results

Obtain Marketo administrative access and permission to change the relevant DNS zone. Save existing SPF, DKIM, DMARC, MX and CNAME records first. Inventory other senders on the same domain, especially employee email and transactional platforms. Agree who can pause campaigns if a key replacement removes aligned signing.

Configure custom DKIM in Marketo

Marketo signs outbound mail with shared DKIM by default. To configure your domain:

  1. Open Admin → Email → SPF/DKIM → Add Domain.
  2. Enter the exact From domain. Choose an unused selector and key size; Adobe recommends 2048 bits.
  3. Add the domain and copy its Host Record and TXT Value to your DNS change request.
  4. Publish that public TXT value at the specified host. Ensure every authoritative nameserver returns it.
  5. Select the domain in Marketo and run Check DNS. Resolve errors before using the result as an activation checkpoint.

A different From domain can fall back to shared signing. Selector or key-size replacement requires deleting the old entry and publishing/validating the regenerated record, with a potential signing gap. Adobe allows 24–48 hours for the new record to propagate. Schedule that change rather than doing it during a campaign. Adobe custom DKIM instructions.

The record has this shape, not a universal key:

Type: TXT
Owner: <selected-selector>._domainkey.<exact-from-domain>
Value: <complete public TXT value generated by this Marketo instance>

Never paste a private key into DNS, a support ticket or a checker. A selector identifies a public key; it is not itself the key. Copy the complete generated value without introducing spaces inside the encoded key. A DNS console may split a long TXT value into quoted strings: those must remain parts of one TXT record, not separate competing records. DKIM public-key lookup.

For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.

Add SPF only at the intended DNS owner

Adobe's standard setup specifies include:mktomail.com. If you are adding this authorization to an existing policy, insert it before the terminal all mechanism while preserving every legitimate sender and the existing qualifier. Do not copy Adobe's illustrative corporate IP or add mx unless those hosts actually send mail. Adobe SPF instructions.

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

SPF checks the SMTP MAIL FROM domain, usually visible in the delivered Return-Path; it does not authenticate the human-visible From address. A parent-domain policy is not inherited by an arbitrary subdomain. Keep one v=spf1 record at each evaluated owner. Count the evaluated DNS-lookup terms, including nested includes: SPF permits at most ten lookup-causing terms across the evaluation. Exceeding that limit produces permerror; ten vendors is not a safe proxy. RFC 7208.

For example, a passing SPF result for a domain under mktomail.com does not align with news@example.com. Another include at example.com cannot rename that envelope domain. Adobe explicitly recommends DKIM alignment and says strict SPF alignment is unsupported. Adobe DMARC guidance.

Decide whether you need a branded return path

A branded return path is useful when you require SPF alignment as well as DKIM. It is not a prerequisite for a message to pass DMARC with aligned DKIM.

Shared or Trusted IPs: ask your CSM to confirm entitlement before publishing anything. Adobe's dedicated knowledge article describes shared-IP branding as a paid addition. The setup uses an otherwise unused subdomain, an MX target selected for the instance's datacenter and SPF TXT at that subdomain. The documented SPF is v=spf1 include:mktomail.com -all. Adobe Support must complete instance-side activation after publication. Do not infer the region from your office location or copy a region's MX target from another tenant. Shared/Trusted branded return path.

Dedicated IPs: Adobe describes an A record for the dedicated sending IP, MX pointing to its assigned hostname, and SPF TXT at a unique return-path subdomain. Request the exact records from Support and confirm activation. The return-path name must not be your landing-page or tracking-link name. Do not copy the dedicated-IP article's bare all SPF example: bare all is equivalent to +all and authorizes every sender. Ask Adobe to confirm a restrictive policy for your route before making that change. This is an unresolved documentation defect, not a recommendation to weaken SPF. Dedicated-IP instructions, SPF mechanism semantics.

Keep corporate inbox MX records untouched. A return-path subdomain's bounce-handling MX is not a replacement for your organization's normal receiving service.

Before publication or activation, the routing owner must separately approve the complete proposed record set: full owners, MX numeric priorities and target hostnames, and any issued A/AAAA destination addresses. Receiving a provider packet is not approval of its routing consequences. Reconcile it with the authorized design, preserve corporate mailbox and website routing, and compare the complete approved set at authoritative and recursive DNS. Stop on unapproved destinations, extra conflicting records or mismatched priorities; do not accept one matching target as proof of the whole set.

Preserve or establish DMARC safely

DMARC passes when at least one authenticated identifier aligns with the visible From domain: passing DKIM with aligned d=, or passing SPF with aligned MAIL FROM. Relaxed alignment compares organizational domains; strict alignment requires exact domains. For Marketo, prioritize validated custom DKIM and check your existing adkim/aspf settings before assuming a subdomain will align.

Retain an existing policy. If no applicable policy exists and a monitored rollout is appropriate, a starting pattern is:

Owner: _dmarc.<from-domain>
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:<approved-report-mailbox>

Replace every placeholder; inspect parent-domain policy as well as the exact From domain. Do not publish a second DMARC record or weaken enforcement simply to satisfy a setup screen. RFC 9989 removed pct; do not promise percentage-based rollout. Current DMARC standard.

Use an authorized, monitored report destination. An external reporting service may need its own authorization record. Aggregate reports help inventory all senders before enforcement, not just Marketo. Aggregate reporting. Do not add ruf by default: failure reports can disclose headers and message content. Failure-report privacy.

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4. For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names.

Verify public records and a delivered campaign

These are checks to perform in your own approved implementation, not tests performed for this article. Replace the example names before running:

dig +short TXT '<selector>._domainkey.<from-domain>'
dig +short TXT '<actual-mail-from-domain>'
dig +short MX '<branded-return-path-domain>'
dig +short TXT '_dmarc.<from-domain>'
dig +short NS '<dns-zone>'
dig @<authoritative-nameserver> TXT '<selector>._domainkey.<from-domain>'

The DKIM lookup should match Marketo's issued public value. For branded return paths, compare MX and SPF with the Support-approved worksheet. Query each authoritative nameserver if Check DNS disagrees with a public resolver. An empty response or SERVFAIL requires investigation; it is not evidence that the provider is unsupported.

Next send an authorized low-volume message through the actual campaign route to an external mailbox you control. Use a harmless subject and no customer data. Inspect the receiving system's trusted Authentication-Results, not an arbitrary header inserted earlier in transit. Authentication-Results trust boundary.

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

Record the visible From domain, smtp.mailfrom, DKIM d= and s=, and the receiver's SPF, DKIM and DMARC results. Success means custom DKIM passes and aligns; if branded SPF was requested, SPF also passes for the intended envelope domain and aligns. dmarc=pass is expected when either aligned method succeeds. A Marketo green status alone does not establish this. Investigate an actual SPF failure even when DKIM allows DMARC to pass: check the evaluated MAIL FROM domain, sending IP, DNS errors and any forwarding hop. A passing but unaligned SPF result is a different diagnosis from failed SPF authentication.

Acceptance requires the intended Marketo branded DKIM signature itself to pass and align under the effective adkim setting, and the trusted receiver to report dmarc=pass for the unchanged intended visible From. An SPF-only DMARC pass cannot complete this DKIM setup. Keep each signature’s d= and s= together; EmailAuth’s DKIM selector guide explains how to derive its exact lookup owner.

Diagnose the actual smtp.mailfrom result independently: fail or softfail calls for checking the connecting sender against the approved authorization; temperror is a transient evaluation failure, often DNS; permerror requires checking malformed or duplicate policies and the evaluated lookup budget. An aligned DKIM pass does not repair these SPF faults. Do not change an unrelated apex policy to fix a provider-controlled envelope domain. SPF result definitions.

Troubleshooting and frequently asked questions

Why is DKIM valid in DNS but Marketo still reports an error?

Compare the exact host and key against the instance's current values. Check for a duplicated zone suffix, truncated TXT, a stale selector and inconsistent authoritative answers. Adobe says propagation can delay validation. Avoid regenerating the key repeatedly while caches update. Custom DKIM validation.

Why does SPF pass but DMARC fail?

Compare identifiers, not just pass/fail labels. A provider-owned envelope domain can pass SPF without aligning. If DKIM also uses a shared domain, neither method authenticates your visible From identity for DMARC. Correct the exact From-domain custom DKIM setup and retest.

Can I use the same host for DKIM and another service?

Do not replace another service's selector record. Choose an unused selector during setup. A CNAME cannot coexist with ordinary TXT data at the same owner, so a conflicting alias must be resolved rather than supplemented. DNS alias rules.

Is branded return path required, and is it included in every plan?

No. Aligned DKIM can satisfy DMARC. Entitlement and the activation procedure depend on the Marketo IP arrangement and subscription; get confirmation from Adobe for your instance. Do not treat a generic setup guide as a current commercial quote.

Does authentication guarantee inbox placement?

No. Passing authentication does not establish permission to contact recipients, healthy engagement, sender reputation or placement in a particular folder. Diagnose bounces and filtering separately after checking the actual message identities.

Completion criteria and review boundary

Keep the change open until DNS matches the worksheet, Marketo validates the domain, and a representative delivered campaign passes the intended alignment checks. Store timestamps and sanitized headers. Repeat after selector changes, new From domains, IP migrations or return-path changes. Review aggregate reports across all legitimate senders before tightening DMARC.

This guide is based on public documentation, not hands-on testing in a Marketo account or DNS zone. No message-delivery or inbox-placement test was performed. Authentication does not guarantee inbox placement.

[ Sources ]

Sources

  1. Adobe authentication setup
  2. Adobe custom DKIM instructions
  3. Marketo protocol configuration
  4. Shared/Trusted branded return path
  5. Dedicated-IP instructions
  6. RFC 7208
  7. DKIM public-key lookup
  8. Current DMARC standard
  9. Aggregate reporting
  10. Failure-report privacy
  11. DNS alias rules
  12. Authentication-Results trust boundary

Enterprise provenance

Why top financial institutions and governments retired their email security dashboards.

Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.

EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard, with human-in-the-loop auditability.

Governments Large enterprises Tier-1 financial institutions

SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption

Knowledge Base