Ortto SPF, DKIM and DMARC setup, step by step

To authenticate email in current Ortto, open Settings > Custom domains, add the exact domain used in your From address, and publish the CNAME records generated for that account. Ortto documents three records for email alone and four when tracking is included. Run Verify setup, then check a delivered campaign for your intended From domain, an aligned passing branded DKIM signature and dmarc=pass. An additional SPF TXT edit is recommended but not mandatory in Ortto's current guidance. Ortto custom domains.

Choose the right product, account and domain

This guide covers current Ortto custom email domains, including a sending subdomain. It is not the older Autopilot Journeys domain recipe. A rebrand or unified login does not establish that a domain's old authentication records work in the new product. Ortto explicitly documents re-verification after account unification. Ortto migration troubleshooting.

Identify these separately before making a change:

• Sending domain: the domain in the intended visible From address, such as news.example.com for updates@news.example.com.
• DKIM signing domain: the d= identity in the delivered message's signature. Its public key is located using that domain and the signature's selector, s=.
• Envelope domain: the SMTP MAIL FROM domain, normally reflected in Return-Path, which SPF authenticates.
• Tracking domain: the hostname used for links, activity tracking and widget hosting. Working tracking does not authenticate the From address.

Ortto permits the same domain in multiple accounts, but generates separate authentication records for each. Copy the records from the account that sends this campaign, not from a colleague's verified account. Its current domain limits are five for Professional, ten for Business and fifteen for Enterprise; check the account's current entitlement before planning additional domains. Account scope and limits.

Prepare access and a recoverable change

You need access to Ortto's Custom domains settings, an organizational domain you control, and a DNS administrator who can edit the authoritative zone. The registrar and DNS host may be different companies. A free mailbox address on someone else's domain cannot be authenticated by changing your own DNS.

Save the existing DNS records, the intended From address, account name, feature selection and previous default domain. Identify who can pause campaigns and restore the previous configuration. Reserve a harmless message and a mailbox you control for the acceptance check. Do not use customer data or a large campaign as a diagnostic test.

Keep inbound mailbox MX records, the website and other senders unchanged. If a requested name is already occupied, investigate its owner before replacing it. Preparing these records does not require granting a new service broad DNS access or generating a private DKIM key yourself.

Add the custom domain and retrieve its records

1. Open Settings > Custom domains and select Add domain under Custom domain name.
2. Enter the domain, or the full sending subdomain, and select its DNS provider. Use a bare lowercase name, not an email address, URL, www prefix or trailing slash.
3. Leave optional hosting and activity-tracking options off for email-only setup. If tracking is required, enable activity tracking and widget hosting and provide its separate subdomain.
4. Select Ok and retain every generated record's type, owner and target. Two are DKIM CNAMEs; publish the full email record set, not only the rows containing _domainkey.
5. If knowledge-base hosting is also selected, Ortto documents five records for email, tracking and knowledge base. Treat that additional web-hosting configuration separately from email authentication.

These are the current provider steps, not the legacy Autopilot flow using five mixed DNS changes. The record values displayed in your account are authoritative; no selector or destination in an online example is a reusable tenant value. Current setup, input and migration errors.

Publish CNAMEs at the correct DNS names

A CNAME value is a destination hostname, without https:// or a path. Preserve the issued target exactly, allowing only the DNS host's documented trailing-dot convention. For Cloudflare, Ortto requires DNS only, not proxying. Disable CNAME flattening for authentication aliases if it hides the required CNAME response, or ask the DNS provider how to expose the actual alias. Do not replace an authentication CNAME with an A record. Ortto DNS requirements.

If Cloudflare hosts the relevant authentication records, check DNS only, the record-level Flatten option is off, and the zone-wide CNAME flattening for all CNAME records setting is off. A DNS-only record can still be flattened. Coordinate any zone-wide change with owners of other affected services rather than changing a shared setting blindly. If NS records delegate the sending subdomain or _domainkey to another DNS service, publish the record at that authoritative service and preserve the delegation; do not remove NS records just to make a parent-zone entry visible. Cloudflare CNAME verification troubleshooting.

Cloudflare's flatten-all setting cannot be overridden per record. It also flattens apex CNAMEs by default and same-zone targets regardless of that setting. Check which behavior actually applies to the issued authentication owners and targets. If mandatory behavior or a shared-zone dependency prevents the required literal CNAME answer, stop and coordinate a supported configuration with the DNS owner and Ortto; do not invent a per-record exception, break unrelated services or remove a delegation. Cloudflare flattening controls and limits.

The following examples illustrate owner-name mapping only, not records to publish. Suppose the account's full DKIM owner is SELECTOR._domainkey.news.example.com:

Apply the same rule to every generated owner. For example, an issued BOUNCE.news.example.com is BOUNCE.news in the parent zone, but BOUNCE in the delegated child zone. Do not append .news again in a child-zone editor, and do not omit it in the parent zone. DNS delegation, not the spelling of the From address alone, determines where the records belong.

A CNAME owner cannot coexist with ordinary TXT, MX, A or another conflicting CNAME record. Preserve existing consumers and ask for an alternative supported name when needed. A root domain can be the email identity while its generated records live beneath it; Ortto's warning about apex CNAMEs does not prohibit using the root domain in From. DNS alias rules, Ortto troubleshooting.

Decide whether an additional SPF edit is relevant

Ortto's custom-domain and Talk guidance recommends include:autopilotmail.com where an additional SPF authorization is appropriate, but expressly says an SPF edit is not mandatory for custom domains or email auto-forwarding. Its complete example also authorizes Google and uses a and mx; do not copy those unrelated permissions into your policy. Ortto's SPF guidance.

First identify the actual envelope domain used by this sending route. SPF does not inherit the root domain's policy into a subdomain. A root SPF include neither changes a provider-owned Return-Path into your domain nor proves DMARC alignment. Publish the account's complete CNAME set, inspect the resulting mail, and resolve an unexplained SPF requirement with Ortto before adding speculative authorization.

Where an SPF edit is justified, merge the required mechanism into the one existing v=spf1 TXT policy at the relevant owner, before its terminal all. Retain other approved senders and the existing qualifier. Do not publish a second SPF record or add TXT beside a provider-issued CNAME.

If the existing SPF policy uses redirect=, reconcile its authorizations with the DNS owner before changing it. An all mechanism makes redirect ineffective regardless of their order; do not append all as an automatic merge step. SPF qualifiers express authentication results, not a guaranteed receiver delivery or rejection decision. SPF all and redirect processing.

SPF allows at most ten evaluated DNS-querying terms across nested include, a, mx, ptr, exists and redirect. It is not a ten-record allowance or simply a count of top-level includes. ip4, ip6 and all do not consume that term budget; additional MX and void-lookup limits also apply. Do not replace a maintained provider include with a one-time list of resolved IPs to make a checker green. SPF limits. For a policy already near the limit, use the SPF evaluation-path guide.

Preserve DMARC and verify alignment

DMARC compares the visible From domain with a passing SPF envelope identity or a passing DKIM d= identity. Either aligned mechanism can satisfy DMARC. Relaxed alignment accepts an organizational-domain match; strict aspf=s or adkim=s requires an exact match for the corresponding mechanism. A subdomain can satisfy strict alignment when both compared domains are that exact subdomain. RFC 9989.

For example, From news.example.com and DKIM d=news.example.com align in either mode. From news.example.com and d=example.com align only in relaxed mode. An unrelated provider domain does not align merely because it signs successfully. These are illustrative identities, not promised Ortto output.

Inspect the effective policy for the actual From domain, including applicable parent-domain policy discovery. Preserve existing enforcement, alignment settings and reporting recipients. If no policy applies and the domain owner approves monitoring, a starter TXT record at _dmarc.FROM_DOMAIN can use v=DMARC1; p=none; rua=mailto:APPROVED_REPORT_ADDRESS. Replace every placeholder, confirm the reporting mailbox works, and approve the report recipient and data-sharing purpose. Do not publish this example over an established policy or add a duplicate record. Aggregate reporting.

For From news.example.com, the full TXT owner is _dmarc.news.example.com: use _dmarc.news in a relative-name editor for the parent example.com zone, or _dmarc in a separately delegated news.example.com zone. For root From example.com, the full owner is _dmarc.example.com, relative _dmarc. A full-name field takes the complete owner. Preserve existing zone authority and do not create a child override of inherited protection.

Compare the Organizational Domain of the aggregate-report URI's host with the Organizational Domain of the domain where the DMARC policy was found, which is 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 the policy domain is excepted; a different hostname alone does not make it external. Follow the reporting service's exact authorization instructions when needed. This protocol check is separate from the domain owner's approval to share report data with that recipient. RFC 9990 section 4.

p=none requests no DMARC enforcement; it does not guarantee delivery. RFC 9989 supersedes RFC 7489 and removes pct, so do not design a new rollout around percentage enforcement. Evaluate all legitimate routes before tightening policy. Its section 7.4 requires valid DKIM for domains publishing p=reject and explains indirect-mail risks. A successful campaign is not an organization-wide enforcement assessment.

Verify DNS, sender status and tracking separately

Replace uppercase placeholders with exact account-issued names. These are reader-run checks, not results collected for this guide:

dig +short NS AUTHORITATIVE_ZONE
dig @AUTHORITATIVE_NAMESERVER DKIM_OWNER_FQDN CNAME +noall +answer
dig DKIM_OWNER_FQDN CNAME +noall +answer
dig DKIM_TARGET_FQDN TXT +noall +answer
dig ENVELOPE_DOMAIN TXT +noall +answer
dig _dmarc.FROM_DOMAIN TXT +noall +answer

Repeat the CNAME query for every issued owner. The authoritative and recursive answers should converge on the exact issued targets after caches expire. Follow DKIM aliases to the published public key. An absent answer, NXDOMAIN or SERVFAIL is not a pass; check delegation, owner spelling and resolver status. Do not infer live signing from the existence of a key. DKIM verification.

Return to Custom domains > Verify setup. Ortto advises allowing up to 24–48 hours for DNS verification, but waiting cannot repair the wrong owner or target. Interpret its status labels precisely:

These are the documented states, not observations from your account. If certificates are the remaining issue, inspect the tracking domain and existing CAA restrictions with IT; Ortto identifies ZeroSSL (sectigo.com). Do not remove organizational CAA restrictions indiscriminately. Statuses and certification.

Accept a delivered campaign, not just a green status

After approved setup, send a harmless campaign or automation to a controlled recipient through the intended route. Open its raw source and use the receiving mailbox provider's trusted Authentication-Results, not a same-named header inserted by an upstream sender. Match the receiving system's documented authentication-service identity and delivery trace; header position alone is insufficient. Receiver trust boundary.

Establish provenance through receiver-controlled evidence: the mailbox service's documented handling of authentication results, its trusted administrative logs, or confirmation from its mail administrator. A familiar authserv-id, a copied Received line or header position alone can be forged and is insufficient. Ignore results supplied from outside that established trust boundary unless the receiving administrator has explicitly configured a trusted relationship for them. If provenance is unclear, obtain the receiver's own verdict before accepting the test. RFC 8601 section 7.1.

Record the account and workflow, timestamp, actual From, Return-Path or smtp.mailfrom, SPF result, each DKIM d= and s= with its result, DMARC result and applicable alignment modes. Accept this custom-domain setup only when:

• The received From is the intended brand, not Ortto fallback.
• The intended Ortto signature uses an account-issued selector, passes DKIM and aligns its branded d= with From under the effective mode; an unrelated passing signature is not enough.
• The trusted receiver reports dmarc=pass; any unexpected SPF failure is explained or repaired.
• Account verification and published DNS match, and tracking works separately if requested.

Requiring branded DKIM here verifies the signing configuration you just commissioned. It does not change the DMARC rule that either aligned mechanism can pass. Repeat for materially different domains, accounts and workflows. No DNS lookup, green account status or inbox placement alone satisfies this acceptance test.

Troubleshoot and recover without disrupting other mail

Duplicated domain detected: compare the full queried owner with the requested one. Remove only the accidentally doubled suffix, respecting parent versus delegated-zone mapping.

Failed to lookup CNAME: check the authoritative zone, proxy/flattening settings, conflicting records and exact target. Escalate with the issued and observed public values if they match but verification remains pending.

CNAME rule has invalid or missing value after Autopilot unification: Ortto recommends deleting and re-adding the custom domain to obtain current CNAMEs. Schedule this as a controlled interruption, save the previous setup, pause affected campaigns, then publish and verify the new set. Do not repeatedly regenerate records while an earlier set is still propagating. Official troubleshooting.

SPF permerror: inspect the actual smtp.mailfrom owner for duplicate policies, malformed syntax, recursive includes, exceeded term budget or excessive void lookups. SPF temperror: investigate transient DNS errors and retry after recovery. SPF fail or softfail: compare the sending IP with the applicable policy and confirm the route; forwarding can change the connecting IP. Do not use +all, weaken DMARC or authorize unrelated infrastructure as a shortcut.

DKIM passes but DMARC fails: compare d= with the actual From and alignment mode. DKIM fails: follow the message's s=._domainkey.d= lookup, confirm account activation, then investigate message modification in transit. A root SPF edit cannot repair a broken DKIM signature.

Domain was verified and now is not: compare current DNS with the saved account records before changing anything. Ortto can fall back to a default domain, ultimately autopilotmail.com; deleting the domain also causes fallback. Decide explicitly whether that temporary sender identity is acceptable. Restore a known-good approved configuration or keep the affected sending paused. Retain old DKIM keys until queued mail and the provider's transition requirements are accounted for.