How to set up DMARC/DKIM/SPF for Dyspatch
Updated on 6 Oct 2026: We updated the Dyspatch setup steps for current DMARC policy staging, strict domain matching and live-message verification.
Dyspatch does not authenticate a sending domain by itself. It creates, renders, and exports email content, while the connected email service provider (ESP) sends the message. Add the domain, SPF return-path, and DKIM keys in that ESP, then publish DMARC at your DNS host.
The working result has a visible From address on your domain and at least one matching authentication path: either the DKIM signing domain matches the From domain, or the SPF-authenticated return-path domain matches it. Configure both when the ESP supports a custom return-path, because DMARC can still pass when one authentication path fails.
Who owns each setting
Use Dyspatch to select the integration, set supported From metadata, and publish or export the template. Use the ESP to generate SPF and DKIM DNS values and send the test message. Use your DNS host to publish those values and the DMARC TXT record.
Add your sending domain in the ESP
There is no universal email-authentication domain screen in Dyspatch. Start in Dyspatch to identify the ESP that will send the template, then add and verify the domain in that ESP. This matters because the active ESP account determines the DNS records and rDNS hostname recipients see.
- Open integrations: In Dyspatch, open Admin, then Integrations, and locate the ESP integration used by the workspace.
- Confirm the route: For Sendwithus API sends, confirm the esp_account value or the account default. For direct exports, confirm the integration selected during export.
- Choose the domain: Use a domain you control in the visible From address, such as mail.example.com or example.com. Keep marketing and transactional traffic on separate subdomains when their risk or ownership differs.
- Add it in the ESP: Open the sending provider's domain or sender-authentication area, add the chosen domain, and copy every DNS value it generates.
- Publish DNS: Create the TXT or CNAME records at the authoritative DNS host using the supplied hostnames and values. Follow the DNS panel's rules for quotes and automatically appended zone names.
- Verify ownership: Return to the ESP and select Verify. Confirm DKIM is active before sending production traffic, and verify the custom return-path if you configured one.
If more than one integration can send the template, document the production route before editing DNS. Publishing records for an inactive integration will not change authentication on the message that recipients receive.
Dyspatch Admin integrations page showing the production ESP connection
Set the integration's default From address to the verified domain where that setting is available. A template can override it in Dyspatch's Metadata tab; a Sendwithus API call can supply sender.address. Review the final From address on every production send. Check Dyspatch's Sendwithus setup and the Sendwithus API reference for those settings.
Do not copy another account's records
Selectors, CNAME targets, include domains, and verification tokens can differ by ESP account. Use only the DNS values shown inside the production account that actually sends the Dyspatch template.
Set up SPF
SPF checks the envelope sender, also called the return-path or MAIL FROM domain. If your connected ESP supports a custom return-path, enable it there and use a subdomain you control, such as bounce.example.com.
- Open the ESP: Use the integration or esp_account identified in the previous step.
- Create a return-path: Choose a dedicated subdomain under the same organizational domain as the visible From address for relaxed matching. Check aspf before assuming the domains match.
- Copy the exact record: Publish the ESP's specified TXT or CNAME record at each supplied hostname, plus any MX record requested for bounce handling. A CNAME cannot share its hostname with a TXT or MX record. See RFC 1034 for CNAME restrictions.
- Keep one SPF record: If the hostname already has SPF, merge authorised mechanisms into that record. Two SPF TXT records at one hostname cause a permanent error.
- Verify in the ESP: Wait for DNS publication, select Verify, and confirm the custom return-path is active before testing.
Illustrative SPF record onlyDNS
Type: TXT Host: bounce.example.com Value: v=spf1 include:spf.sender.example -all
Do not publish the illustrative value above. Your connected ESP must supply the real include domain or CNAME target. Check the return-path hostname itself, not only the root From domain, because SPF is evaluated against the envelope sender.
SPF permits at most 10 DNS-query terms during evaluation, including nested includes. The limit covers include, a, mx, ptr, exists and redirect; ip4, ip6 and all do not count. Remove unused authorisations and recheck the full include chain before publishing. Never use +all, which authorises every sender. See RFC 7208 for the lookup limit.
Dyspatch Sendwithus integration screen used to identify the sending account
After the ESP reports success, query the published hostname independently. DNS can appear in one resolver before another, and a provider's Verify button can cache an older result.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
A passing SPF result only helps DMARC when the authenticated return-path domain matches the visible From domain under the policy's aspf mode. A provider-owned return-path can pass SPF but still fail the domain match required by DMARC.
When SPF domain matching is unavailable
Some sending sources do not support a custom return-path. In that case, do not invent an SPF include at the From domain. Expect SPF domain-match failures and make DKIM pass with a signing domain that meets your adkim setting.
Set up DKIM
DKIM configuration also belongs to the connected ESP, not the Dyspatch template. Enable domain authentication in the ESP, publish every selector it supplies, and choose a DKIM signing domain that meets the DMARC policy's adkim setting.
- Generate keys: In the production ESP account, add the sending domain and request DKIM records. Prefer 2048-bit RSA keys when the provider and DNS host support them.
- Publish every selector: Providers often issue multiple selectors for rotation. Add each TXT or CNAME record without removing a selector still used by live mail.
- Preserve the host: Some DNS panels append the zone automatically. Avoid publishing example.com twice in the final hostname.
- Activate signing: Select Verify in the ESP, then confirm it marks DKIM active for the domain used by Dyspatch's From address.
- Inspect a message: Read the DKIM-Signature header and confirm the d= domain meets adkim. Use its s= selector to check the DNS key at s._domainkey.d, substituting the actual tag values.
Illustrative DKIM record onlyDNS
Type: TXT Host: selector1._domainkey.example.com Value: v=DKIM1; k=rsa; p=PUBLIC_KEY_FROM_YOUR_ESP
A DKIM pass can still fail DMARC when the d= domain belongs to the provider instead of your domain. Fix the provider's authenticated-domain setting, then resend. Editing the Dyspatch template body or From display name will not change the DKIM signing domain. If there are multiple DKIM signatures, one passing signature with the required domain match is sufficient.
DMARC-ready DKIM
- Signature result: DKIM passes after final message processing.
- Signing domain: The d= value meets the DMARC policy's adkim setting.
- Selector state: The matching DNS key resolves publicly.
- Live test: The production ESP signs the exported template.
DKIM that needs work
- Signature result: DKIM is missing, neutral, or failing.
- Signing domain: The d= value belongs only to the ESP.
- Selector state: The DNS key is missing or truncated.
- Live test: A different ESP account handles the send.
Keep old selectors published during key rotation until no live message can use them. Removing an old selector too early breaks DKIM validation for delayed or retried mail.
Publish only the ESP's public DKIM key or CNAME target; keep private keys out of DNS. For a long TXT value, use multiple quoted strings inside one TXT record if your DNS host requires splitting. Keep the key complete and do not create separate TXT records for its pieces. RFC 6376 defines DKIM key lookup and TXT-string joining.
Set up DMARC
Check the existing DMARC policy for the visible From domain, including any inherited parent policy, before adding a record. For a domain without an applicable policy, publish one DMARC TXT record at _dmarc followed by the From domain and start with p=none to collect reports. If an applicable policy already uses p=quarantine or p=reject, keep that stronger policy while fixing Dyspatch's connected ESP.
- Select the From domain: Use the domain to the right of @ in the address recipients see.
- Choose a report mailbox: Use a monitored mailbox that accepts aggregate XML reports or the reporting address Suped issues for your domain.
- Publish one TXT record: Create it at _dmarc.example.com and replace example.com with the real From domain.
- Check syntax: Keep v=DMARC1 first, use semicolons between tags, and remove any second DMARC TXT record.
- Collect reports: Allow at least several normal sending cycles before judging whether every legitimate source passes DMARC.
Starter DMARC recordDNS
Type: TXT Host: _dmarc.example.com Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com
Replace example.com in the record's hostname with the actual From domain and replace dmarc@example.com with your report address. Use the DMARC record generator if you need tags for subdomain policy or strict matching.
When rua points outside your organizational domain, the report destination must authorise external reporting in its own DNS. Follow Suped's domain onboarding instructions for its assigned reporting address. If reports are missing, check this authorisation as well as the DMARC record; RFC 9990 defines the external-destination check.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
The checker should find one valid record at the applicable _dmarc hostname, including an inherited policy when no record exists at the exact From domain. A DMARC TXT value at the bare root domain does not enable DMARC, and duplicate records at a queried _dmarc hostname invalidate that record set.
Keep an existing enforced policy
Do not weaken p=quarantine or p=reject to add Dyspatch. Authenticate the connected ESP, verify live messages, and keep the existing policy unless report data proves a separate source needs a controlled exception or repair.
Check domain matching and subdomain policy
Relaxed matching is the default: adkim=r and aspf=r allow the authenticated domain and visible From domain to share an organizational domain. Strict matching, adkim=s or aspf=s, requires an exact domain match. RFC 9989 defines these modes.
In these examples, example.com is the organizational domain and SPF or DKIM already passes.
|
|
|
|---|---|---|
example.com | Matches | Matches |
bounce.example.com | Matches | Does not match |
sender.example.net | Does not match | Does not match |
Domain matching for a visible From address on example.com
For From: updates@mail.example.com, check _dmarc.mail.example.com first. Without an explicit record, check the applicable parent policy, including sp or p. Adding p=none on the subdomain overrides inherited enforcement.
Verify SPF, DKIM and DMARC on a live message
Send a real message through the same Dyspatch workspace, template, API route, and ESP account used in production. A preview rendered without the production ESP does not prove SPF, DKIM, or DMARC.
|
|
|
|---|---|---|
SPF | Pass; domain match when supported | Connected ESP |
DKIM | Pass + match | Connected ESP |
DMARC | Pass | DNS owner + connected ESP |
rDNS | PTR hostname resolves to the sending IP | Connected ESP |
Expected authentication results on a production-path test
DMARC passes when either SPF or DKIM passes and its authenticated domain meets the policy's matching mode. Aim for both paths passing and matching when the ESP supports them. rDNS is a separate mail-server check; passing authentication does not guarantee inbox placement.
Illustrative received authentication headerstext
From: Example team <updates@example.com> Return-Path: <bounce@bounce.example.com> Authentication-Results: mx.example.net; spf=pass smtp.mailfrom=bounce.example.com; dkim=pass header.d=example.com header.s=selector1; dmarc=pass header.from=example.com
Use the result added by the receiving mailbox you trust, as specified in RFC 8601. In this example, SPF matches under relaxed aspf and DKIM matches under either adkim mode.
- Publish the template: Complete approval in Dyspatch and publish the current version.
- Export through production: Select Export, choose Export to Integration, select the production integration, then confirm the export. If the integration exports automatically, confirm the current version reached the sending account.
- Set the final sender: Confirm the metadata From address and any API sender override use the domain verified in the ESP.
- Send a diagnostic: Send the exported template through the production ESP or Sendwithus production API, using the correct esp_account, to the unique test address below.
- Read identifiers: Read Authentication-Results added by the receiving mailbox. Compare smtp.mailfrom with header.from, then check DKIM header.d and header.s.
- Repeat after repair: Wait for relevant DNS caches to expire, then send a new message after each repair; existing message headers retain the old results.
Exporting transfers template content; delivery starts with the ESP or production API call. Dyspatch's export documentation describes that handoff. Editor previews and test sends do not prove the production ESP account's authentication.
Dyspatch Export to Integration flow for a production-path test
Use Suped's email tester for an end-to-end check. It reads the received message rather than only DNS, so it can diagnose the actual SPF domain, DKIM signature, DMARC result, rDNS, and message construction produced by the selected route.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
After the report arrives, fix the owner shown in the table above. DNS record errors belong at the DNS host, provider-owned signing or return-path errors belong in the ESP, and an unexpected From address belongs in Dyspatch metadata or the sending API call.
Common failure map
- SPF permerror: Resolve duplicate SPF records, recursive includes, more than 10 DNS-query terms, or excessive empty DNS responses.
- SPF passes but DMARC fails: Check the return-path against aspf. Configure a matching custom return-path, or use passing DKIM with the required domain match.
- DKIM body hash fails: Find a relay or footer system that changes content after signing.
- DKIM passes but DMARC fails: Check the d= domain against adkim and configure a matching signing domain in the production ESP.
- Unexpected rDNS: Trace the selected ESP account and sending IP. Dyspatch does not set the PTR record.
Monitor Dyspatch authentication with Suped
A one-time test cannot catch a rotated DKIM selector, deleted return-path record, new ESP account, or template override introduced later. Suped, our DMARC reporting and email authentication platform, supports continuous DMARC monitoring so you can review the connected ESP's results and investigate failures.
- Add the domain: Add the visible From domain to Suped and use its aggregate-report address in the rua tag.
- Name the source: Match the production route to sending IPs and SPF/DKIM domains in aggregate reports; check rDNS separately.
- Set alerts: Enable notifications for authentication failures detected in incoming DMARC reports. Review DNS after ESP or record changes.
- Review new sources: Treat a new sending IP or signing domain as unverified until its owner and purpose are confirmed.
- Repair by owner: Use automated issue detection and steps to fix the ESP, DNS, or sender-metadata setting that changed.
- Watch reputation: Track blocklist (blacklist) status beside the authentication results.
For several Dyspatch workspaces or customer domains, use Suped's multi-tenant dashboard to review each domain's reports with its assigned owner.
Recommended alert workflow
Send each alert to an owner who can change either the ESP integration, Dyspatch sender metadata, or DNS. Record the expected DKIM domains and return-path for each production route so a new identifier triggers investigation instead of silent acceptance.
Aggregate reports commonly cover daily intervals; Suped's authentication alerts depend on their arrival. Keep weekly summaries and authentication alerts enabled during ESP migrations and DKIM key rotation. RFC 9990 describes receiver report schedules.
Secure your domain with p=reject
Move to p=reject only after normal report data shows every legitimate sender passes DMARC. Use Suped's reports to identify unverified sources, quantify failures, and review each policy change.
- Inventory sources: Classify every sending IP and SPF/DKIM domain seen in aggregate reports. Check PTR hostnames separately when identifying an unfamiliar source.
- Verify Dyspatch traffic: Confirm the production integration consistently passes DMARC across expected message types and regions.
- Fix legitimate failures: Repair DKIM signing and custom return-path settings before changing policy. Do not authorise an entire provider range to hide a domain mismatch.
- Stage quarantine: Use p=quarantine for the selected domain or subdomain, then review reports and repair legitimate failures.
- Stage rejection: Move to p=reject once that domain's legitimate traffic passes DMARC, then continue monitoring receiver results.
- Keep monitoring: Leave reports and alerts active after full enforcement so new integrations cannot fail silently.
Example policy stages, one record at a timeDNS
v=DMARC1; p=none; rua=mailto:dmarc@example.com v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com v=DMARC1; p=reject; rua=mailto:dmarc@example.com
RFC 9989 removed pct; updated receivers ignore it. Treat each stage as a review gate and advance when legitimate failures are resolved. Suped's Hosted DMARC lets you manage policy changes from its dashboard while keeping reporting enabled.
Safe promotion gate
- Traffic map: Every legitimate source has an owner.
- Dyspatch route: Production tests pass through the active ESP.
- Failure review: Legitimate failures are repaired first.
- Rollback plan: The previous valid policy is recorded.
Unsafe promotion gate
- Traffic map: Unknown high-volume sources remain.
- Dyspatch route: Only editor previews have been tested.
- Failure review: Provider-owned identifiers are assumed safe.
- Rollback plan: No owner can restore policy quickly.
With p=reject, participating receivers are asked to reject messages that fail DMARC. Legitimate mail still depends on the connected ESP retaining valid DNS records, DKIM signing, and the expected return-path, so alerts remain part of the control.
Do not use SPF alone as the gate
Forwarding commonly breaks SPF. Require stable DKIM passing with your signing domain before full rejection, even when the connected ESP also provides a matching custom return-path.
FAQ
These checks cover the setup decisions that most often cause confusion when Dyspatch and a connected ESP share responsibility for one mail stream.
No. The connected ESP that sends the message provides the SPF return-path and DKIM DNS records. Dyspatch supplies the rendered content and sender metadata to that ESP.
Authenticate the exact domain used in the visible From address, including a subdomain when applicable. Configure DKIM to meet adkim and, when supported, a custom return-path to meet aspf.
Dyspatch and Sendwithus route production email through a connected ESP, so neither name guarantees one fixed production rDNS suffix. Identify the source with the sending IP, PTR hostname, DKIM d= domain, return-path, and selected esp_account. A dyspatch.io or sendwithus.com reference elsewhere in the message can identify template or API handling without proving which ESP transmitted it.
Yes. DMARC passes when at least one DKIM signature passes and its d= domain meets adkim for the visible From domain. Use this path when the sending source cannot provide SPF domain matching.
Use p=none only when no applicable DMARC policy already covers the domain. Check inherited policy when the From address uses a subdomain. If p=quarantine or p=reject already applies, keep it and repair the connected ESP.
A preview checks rendered content, while production authentication depends on the sending ESP account. Test a published and exported template through the production ESP or Sendwithus production API using the live esp_account.
