How to set up DMARC/DKIM/SPF for Adobe Marketo
Published 5 Aug 2026
Updated 5 Aug 2026
12 min read
Summarize with
Adobe Marketo Engage needs a custom DKIM signature for every visible From domain, one valid SPF record that authorizes Marketo, and a DMARC TXT record covering the From domain. I recommend DKIM as the primary DMARC pass path because it remains attached to the message and directly matches the domain recipients see.SPF alignment also works when Adobe provisions a branded Return-Path. Without that provisioning, SPF can pass for a mktomail.com envelope domain but fail DMARC alignment. That result is acceptable when custom DKIM passes and its signing domain matches the From domain.
Add your domain
Marketo does not have a separate ownership-verification workflow for sending domains. Adding a domain creates its custom DKIM configuration, and Marketo verifies it after the generated public key appears in DNS.
Use the exact domain after the @ sign in the From address. If campaigns send as news@marketing.example.com, add marketing.example.com, not example.com and not the tracking-link domain.
- Inventory the From domains: Open representative approved emails and record every domain used in their From fields.
- Open email administration: In Marketo Engage, go to Admin, select Email, and open the SPF/DKIM tab.
- Create the domain entry: Click Add Domain, enter the full From domain, choose a unique selector, select 2048 bits, and click Add.
- Verify after DNS: Copy the generated Host Record and TXT Value, publish them in DNS, return to the SPF/DKIM tab, select the domain, and click Check DNS. Finish only when Marketo shows the domain as verified.
Adobe Marketo Engage SPF/DKIM tab with the Add Domain control.
Use a dedicated sending subdomain
I prefer a domain such as marketing.example.com when the organization wants Marketo traffic isolated from employee mail. Use a new sending subdomain, not an existing landing-page or tracking-link subdomain, and make sure its From addresses can receive replies or route them correctly.
Set up SPF
Adobe's SPF and DKIM guide specifies include:mktomail.com. Add it to the one SPF TXT record for the domain Adobe tells you to use. Never publish a second SPF record beside an existing one.
Basic SPF authorization and DMARC SPF alignment are different. The include authorizes Marketo infrastructure. Under relaxed mode, DMARC SPF alignment requires the Return-Path domain and visible From domain to share the same organizational domain.
- Read the current record: Query the intended SPF domain and confirm whether a TXT value beginning with v=spf1 already exists.
- Merge Marketo once: Insert include:mktomail.com before the final all mechanism. Keep every authorized sender in the same record.
- Count DNS lookups: SPF permits at most 10 DNS-causing lookups during one evaluation. Includes and redirects can expand into more lookups.
- Request branded Return-Path: For a dedicated IP, open an Adobe support request. For eligible shared sending, ask the Adobe account team about its supported branded Return-Path route. Use only the DNS targets supplied for your subscription.
New and merged SPF examplesDNS
New: v=spf1 include:mktomail.com ~all Merged: v=spf1 ip4:192.0.2.10 include:mktomail.com ~all
Run the check against the exact hostname where the SPF record was published. A valid result must show one SPF record, valid syntax, and no PermError caused by excess lookups.
If messages still use a mktomail.com Return-Path, expect SPF alignment to fail even when SPF itself passes. Keep custom DKIM passing while Adobe provisions the branded Return-Path.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
After DNS updates, allow for resolver caching and check again. Do not keep editing a correct record during propagation because each change resets part of the cache window.
Treat an SPF pass as one signal. The final proof is a delivered Marketo message whose Authentication-Results header shows the expected envelope domain and DMARC result.
Set up DKIM
Custom DKIM is the dependable DMARC path for Marketo. Under relaxed alignment, the d= domain in the DKIM signature and the visible From domain must share the same organizational domain. Strict alignment requires an exact match. Marketo otherwise signs with a shared domain that does not satisfy DMARC for your From domain.
The generated public key is tenant-specific. Copy it from Marketo instead of using an example value, and publish it at every authoritative nameserver for the From domain.
- Choose the selector: Use a clear value such as m1 and select a 2048-bit key when adding the domain.
- Publish the key: Create a TXT record at the Host Record shown by Marketo and paste its TXT Value without adding quotes inside the value.
- Check every nameserver: Confirm that each authoritative server returns the same key. Marketo validation can fail if only some servers have it.
- Activate signing: Return to Admin, Email, SPF/DKIM, select the domain, and click Check DNS. Wait for the verified status before a production send.
- Repeat per From domain: A key for example.com does not custom-sign mail sent as marketing.example.com unless that exact From domain is configured in Marketo.
Adobe Marketo Add Domain dialog with selector and 2048-bit key settings.
Plan DKIM changes carefully
Marketo requires deletion and republication when changing a selector or key size. Adobe states that propagation can take 24 to 48 hours, and custom signing is unavailable during that gap. Schedule the change outside major sends and remove the Marketo entry before changing its corresponding DNS record.
A green verification state proves that Marketo can find the key. It does not prove that every email uses the intended From domain, so send a real sample after activation.
If verification remains pending, compare the hostname one label at a time. DNS control panels often append the zone automatically, which can accidentally create m1._domainkey.marketing.example.com.example.com.
Adobe Marketo DKIM values and successful Check DNS status.
Set up DMARC
DMARC belongs in DNS, not in Marketo. Publish it for the visible From domain. For mail from marketing.example.com, use _dmarc.marketing.example.com when you want an explicit policy and reporting stream for that sending subdomain.
Start at p=none while collecting reports. If the domain already has an effective p=quarantine or p=reject policy, keep that policy and fix Marketo authentication under it. Do not weaken an enforced domain merely to complete setup.
- Check the current policy: Look up the exact From domain and its organizational parent before publishing anything. There must be only one applicable DMARC TXT record at a hostname.
- Choose the report mailbox: Create a mailbox that can receive aggregate XML reports, or use the reporting address issued by the monitoring workflow.
- Generate the record: Use the DMARC record generator and replace the example reporting address with the real mailbox.
- Publish one TXT record: Use the host _dmarc for the selected zone and the exact value below.
Initial DMARC recordDNS
v=DMARC1; p=none; rua=mailto:dmarc@example.com
The DMARC checker should return the policy, reporting destination, and valid syntax. It should not find multiple records or a DMARC record incorrectly placed at the bare domain.
Use relaxed alignment unless the organization has tested strict mode across every sender. Adobe specifically recommends DKIM-based DMARC for Marketo and does not recommend strict SPF alignment.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
A valid record only confirms publication. DMARC passes on a message when SPF or DKIM passes and the passing domain has the required relationship to the From domain.
Adobe's protocol setup recommends staged enforcement and custom DKIM for the From domain. I would not advance the policy until production-shaped samples and aggregate data agree.
Verify and troubleshoot
Send a fresh Marketo sample after DNS and Marketo both show the DKIM domain as verified. Use the same From domain, workspace, subscription and sending route as the real campaign. A forwarded old message does not test the new configuration.
Inspect the received Authentication-Results header. The target state is dkim=pass with header.d equal to the From domain, dmarc=pass, and either aligned SPF or a documented SPF alignment failure caused by the unbranded Marketo Return-Path.
- DKIM pass: Confirm that header.d is your From domain and header.s is the selector configured in Marketo.
- DMARC pass: Confirm that header.from is the expected domain and at least one aligned authentication path passes.
- SPF result: Record both the pass or fail result and the smtp.mailfrom domain. SPF can pass without satisfying DMARC alignment.
- Production path: Repeat the test for each From domain and any materially different Marketo sending route.
Target authentication resultstext
spf=pass smtp.mailfrom=marketing.example.com dkim=pass header.d=marketing.example.com header.s=m1 dmarc=pass header.from=marketing.example.com
The email tester is the quickest end-to-end check. Send the generated address a Marketo email, then review the authentication result, domain relationship, headers and configuration findings in one report.
Use a normal campaign template rather than a bare text test. Tracking rewrites, the selected From token and workspace configuration need to match the real send.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Save the test report beside the DNS change record. It provides a baseline when a later Marketo, DNS or Return-Path change breaks authentication.
When results disagree, troubleshoot the failing identifier instead of republishing every record. The table maps the most common Marketo symptoms to the next action.
|
|
|
|---|---|---|
DKIM pending | Partial DNS propagation | Check every nameserver |
DKIM fail | Wrong key or selector | Copy Marketo values again |
DMARC fail | Shared signing domain | Verify custom DKIM domain |
SPF unaligned | Default Return-Path | Request branded Return-Path |
SPF PermError | Duplicate or excess lookups | Merge and reduce lookups |
Common Adobe Marketo authentication failures
Get alerted when it breaks
A one-time test cannot detect a later selector deletion, SPF lookup overflow, new unauthorized source or sudden DMARC failure. Aggregate reports expose those changes, but raw XML does not turn them into an operating queue.
Suped is our DMARC platform and the best overall practical choice for most teams that need ongoing DMARC monitoring. It detects authentication issues automatically, sends real-time alerts, and gives specific steps to fix each affected source.
Manual report handling
- Parse XML: Normalize receiver-specific files and group source IPs.
- Resolve sources: Work out which IPs belong to Marketo and which do not.
- Track regressions: Compare current results with previous reporting periods.
- Notify owners: Route each failure to DNS, marketing or security staff.
Suped monitoring
- Detect changes: Flag new sources and authentication regressions automatically.
- Explain fixes: Show tailored repair steps for each affected source.
- Unify signals: Combine DMARC, SPF and DKIM with blocklist and deliverability data.
- Scale access: Manage multiple domains and clients in one MSP dashboard.
Configure alerts for any new source, a drop in Marketo DKIM pass rate, an SPF PermError and an unexpected policy change. Send each alert to an owner who can change either Marketo or DNS.
Suped also monitors blocklist (blacklist) status and broader deliverability signals beside authentication. That context helps separate a DNS break from an IP reputation event without switching reporting systems.
Minimum Marketo alert set
- New source: Alert on the first appearance of an unverified sender using the domain.
- DKIM regression: Alert when Marketo volume stops passing with the custom signing domain.
- Policy change: Alert when the effective DMARC policy or reporting address changes.
- Reputation event: Alert when a sending IP or domain appears on a relevant blacklist.
Secure your domain with p=reject
Move to p=reject only after every legitimate source passes DMARC consistently. For Marketo, that normally means custom DKIM is verified for every From domain and seen passing in real aggregate traffic.
Suped makes this change safer through verified-source inventory, automated issue detection, tailored repair steps and Hosted DMARC policy staging. It also keeps the final record under monitoring after enforcement.
- Inventory all sources: Classify every source in aggregate reports as approved, unknown or unauthorized. Resolve unknown volume before enforcement.
- Fix legitimate mail: Require DMARC pass for Marketo and every other approved source. Do not count an unaligned SPF pass as DMARC success.
- Cover low-frequency sends: Observe at least two complete business cycles and include seasonal, billing and incident mail before changing policy.
- Apply quarantine first: Set p=quarantine, keep reporting enabled, and confirm that no legitimate source shifts into failure.
- Enforce rejection: Set p=reject only after quarantine is stable at full coverage. Continue real-time monitoring after the DNS change.
Quarantine stageDNS
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
Keep quarantine at full policy coverage long enough to capture normal campaign variation. If legitimate Marketo mail fails, pause the rollout and repair custom DKIM or the affected From domain.
When all approved sources remain clean, change only the policy tag. Keep the same aggregate reporting destination so the before-and-after data remains comparable.
Reject stageDNS
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Ready for p=reject
Proceed when all known Marketo streams pass DMARC, no approved source depends on an unaligned result, unknown traffic has an owner or is confirmed unauthorized, and alerts are active. Suped's hosted policy controls and issue workflow keep these checks visible during the change.
