Appian Cloud SPF, DKIM and DMARC setup, step by step

For Appian Cloud's native email service, authenticate your custom From domain with Email Sender Authentication, publish the DKIM TXT record issued by your environment, and complete verification in Appian. Do not assume that adding an SPF include to your company domain will authenticate this route: Appian's documented custom-sender headers normally retain an Appian environment Return-Path even after custom DKIM is enabled. A passing, aligned DKIM signature is therefore the important DMARC acceptance check. Appian sender authentication and custom-sender header behavior.

This guide covers Appian Cloud email-as-a-service with a customer-owned From domain. It is not a configuration recipe for self-managed Appian, Appian Government Cloud, or an external SMTP service. No Appian account, customer DNS zone or delivered message was tested.

Understand the sending route before editing DNS

Appian Cloud supplies outbound email for system notifications and process-generated messages. Appian-owned domains have default DKIM signing; your own domain needs its own authentication setup. Private-access environments require additional planning, and a customer SMTP service is a separate delivery route. Email on Appian Cloud.

Keep a short inventory of the environment, application/process, From address, DNS zone owner and person responsible for the change. Repeat the inventory for development, testing and production. A successful test from one environment is not evidence for another.

Prepare the domain and access you need

Before starting, have:

• Access to the environment's Admin Console email settings and permission to configure its sender domain.
• DNS-management access for the domain or subdomain you intend to use.
• The exact From address, such as alerts@ops.example.com, rather than only a display name.
• A copy of the existing DNS records, including other DKIM selectors, SPF and DMARC policies.
• An approved test process and recipient mailbox where your mail administrator can inspect the raw message.

For alerts@ops.example.com, record ops.example.com as the intended sender domain. Do not assume authenticating example.com automatically provisions the exact child-domain signing identity you require. Account acceptance and message-level alignment are separate checks.

Changing a Reply-To address only changes where replies are directed. It does not configure DKIM, change the SPF identity, or establish DMARC alignment. The comparison is with the message's actual From domain, not its display name or Reply-To. DMARC identifiers.

Create and activate Appian custom-domain DKIM

1. Open Admin Console > Integration > Email in the intended environment.
2. Choose Email Sender Authentication, then New Sender Domain Authentication.
3. Enter the domain, select Authenticate, and retain the generated DNS record.
4. Publish the issued TXT record at its exact DNS name. Use the account's value, not a selector or public key from an example.
5. Select VERIFY NOW after publication. Successful verification updates the domain status and enables signing for mail from that domain. VERIFY LATER postpones this step; reopen the domain when ready.

If using a DKIM management service that delegates records, Appian requires the generated TXT record to be created and verified directly in your zone before delegation. Official Appian activation procedure.

Record the verified domain, environment and date. DNS publication alone is not completion: retain evidence of Appian's successful verification as well as a subsequently received message.

Select the authenticated address in the process

In the Send E-Mail Smart Service setup, choose Custom Sender in the From field, then enter the sender display name and sender email address. The email address must use the domain you intended to authenticate. Finish the rest of the activity configuration through your normal process-change controls. Configure an Appian custom sender.

Do not treat a successful process validation, preview, or DNS check as a delivery test. Check that outbound email is enabled for the environment before investigating an activity that never produces a message. Appian outbound email control.

Publish the DKIM record safely

The generated record is the source of truth for its owner, type and value. There is no universal Appian selector or reusable public key in this guide.

For an illustrative issued owner issued-selector._domainkey.ops.example.com, the DNS form may expect:

If your DNS host expects the complete name, enter the complete name instead. Check the final public owner to catch accidental names such as ...example.com.example.com. The selector above is illustrative, not an Appian default.

Preserve the entire public-key value, including tags and punctuation. Long TXT data can consist of multiple quoted character strings within one TXT resource record; the verifier joins those strings. Do not split the key into independent TXT records or add spaces to the key material. DKIM DNS key storage.

Keep other services' selectors. If the exact owner is already occupied, identify its purpose before replacing anything. A CNAME at the same owner cannot simply coexist with the new TXT record. Resolve that collision with the DNS owner and the relevant service rather than deleting records blindly. DNS alias restrictions.

Only if a supported managed-DKIM arrangement uses a CNAME: in Cloudflare, preserve the issued target, choose DNS only, keep the record-level Flatten option off where available, and check that zone-wide CNAME flattening for all CNAME records is off. A zone-wide flatten-all setting cannot be overridden per record. Cloudflare always flattens apex CNAMEs by default and flattens same-zone targets regardless of the selected flattening setting. If mandatory behavior cannot retain the literal CNAME required by the supported arrangement, stop and coordinate a supported layout; do not assume an off switch can fix it. These controls concern CNAMEs, not the native TXT record. Cloudflare CNAME verification and flattening controls.

Coordinate any shared setting change with the DNS owner and affected services first. Preserve legitimate child-zone and _domainkey delegations; publish at their authoritative DNS provider rather than removing or repointing NS records just to make one sender verify. Follow the actual supported account instructions.

Use your DNS team's normal TTL. When comparing results, distinguish the authoritative zone from recursive caches and allow existing positive or negative cached answers to expire. Waiting does not fix an incorrectly named or truncated record.

Understand SPF and the Appian Return-Path

SPF checks the SMTP envelope identity, usually shown as smtp.mailfrom in receiver results. It does not directly authenticate the visible From address. An SPF policy also does not inherit from a parent domain. SPF identity selection.

Appian's custom-sender documentation shows that enabling DKIM changes the Sender header to the custom sender, while the Return-Path usually remains the environment notification address. A receiver can affect the displayed Return-Path, so the trusted SPF result is the stronger diagnostic evidence. Appian's before-and-after header tables.

For a company From domain and an unrelated Appian envelope domain:

• SPF may pass for the Appian envelope identity.
• That pass does not align with your company domain.
• Editing your company's SPF record does not change the envelope identity.
• An aligned custom-domain DKIM pass can supply the DMARC pass instead.

Appian says its native sending addresses are covered by maintained SPF records and that its IP addresses can change. The reviewed native workflow does not provide a universal customer-domain SPF include to paste here. Do not invent one, copy an IP from a sample header, or infer an underlying vendor's include. If your account requires a different mail route, confirm its exact requirements first. Appian Cloud outbound email.

Preserve SPF used by Microsoft 365, Google Workspace or other legitimate senders. Where an authorized change is actually needed, maintain one v=spf1 policy per exact owner, retain existing approved senders, and evaluate the complete policy against SPF's ten DNS-lookup-causing-term limit, including nested includes. Do not replace a shared policy with a single-provider example. SPF publication and limits.

An all mechanism suppresses redirect, and mechanisms after all are unreachable. Preserve the existing redirect-based authorization and final semantics through any reviewed merge; do not append an all terminator by rote. SPF failure from -all does not guarantee receiver rejection. SPF all and redirect behavior.

Retain the right DMARC policy

DMARC passes when at least one authentication method both passes and aligns with the From domain. For this native custom-sender route, verify the intended custom DKIM signature. Strict DKIM alignment requires an exact domain match; relaxed alignment uses the same Organizational Domain. The current DMARC standard defines Organizational Domain and policy discovery using a DNS tree walk. RFC 9989 alignment and policy discovery.

For example, an intended passing signature with d=mail.ops.example.com and visible From alerts@ops.example.com aligns in relaxed mode when both share Organizational Domain example.com, but not in strict mode. A passing d=ops.example.com matches that From domain in both modes. These are illustrative identities, not a claim about a tested Appian message.

Use these DNS-owner mappings when inspecting the policy:

In a delegated ops.example.com zone, that child's relative host is _dmarc. A missing child record does not establish that DMARC is absent: investigate the applicable inherited policy before creating a child override.

Keep existing enforcement and reporting intact. In particular, do not replace p=quarantine or p=reject with p=none, remove sp or np, or relax alignment to hide a signing error. Do not add a second DMARC policy at the same owner. A new child policy can override inherited protection, so involve the domain's policy owner.

For a genuinely new policy with no applicable protection to preserve, an approved monitoring starting point could look like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

This is an example, not a required Appian record. Replace the reporting address with an authorized, monitored destination. p=none requests monitoring rather than enforcement; it does not turn a failed message into an authenticated one.

When the report destination has a different Organizational Domain from the domain where the policy was found, the report-generating receiver must check external-destination DNS authorization. A destination in the same Organizational Domain as the policy domain is excepted, even if its hostname differs. For example, a policy at ops.example.com reporting to reports@collector.example.net requires authorization at ops.example.com._report._dmarc.collector.example.net, normally published by the report-service operator. Follow the operator's actual instructions and share reports only with an approved recipient. Aggregate reports expose sending domains, IP addresses and message counts; review access and retention before enabling a new destination. RFC 9990 external-report authorization.

Verify DNS and a newly delivered Appian message

Check public DNS

Replace the illustrative selector and domain below with the issued values. These commands read DNS; they do not configure it.

dig +short TXT issued-selector._domainkey.ops.example.com
dig +short TXT _dmarc.ops.example.com
dig +short TXT _dmarc.example.com

Compare the DKIM response with the complete generated value. Query the authoritative nameserver and at least one public resolver if answers differ. Record the effective DMARC policy, not just whether one lookup returns text.

If DNS VPN is enabled, Appian documents a potential resolution problem for a DKIM name routed through the tunnel. Have the network team correct the resolution path or work with Appian Support on an exemption. Appian DNS VPN caveat.

Check the actual process route

After approval to send, produce a new message from the intended process and custom sender to a controlled recipient. Start with direct delivery before testing forwarding or mailing-list paths. Ask the recipient administrator for the raw headers or message trace if necessary.

Use the Authentication-Results added by the trusted receiving system, not an arbitrary result string in the message. Have the receiving-domain administrator identify its trusted authentication service and confirm that the receiving system strips or clearly distinguishes externally supplied Authentication-Results. Otherwise, use receiver-controlled authentication logs or message-trace diagnostics. Multiple gateways can add results, and untrusted senders can forge header text; neither a familiar service name nor header position alone proves trust. Authentication-Results trust boundary.

An illustrative successful result might look like this; it is not a captured test:

From: Operations <alerts@ops.example.com>
Return-Path: <admin@environment.appiancloud.com>
Authentication-Results: mx.receiver.example;
 spf=pass smtp.mailfrom=admin@environment.appiancloud.com;
 dkim=pass header.d=ops.example.com;
 dmarc=pass header.from=ops.example.com

Read that result as three separate observations: Appian's envelope identity passed SPF; your intended domain passed DKIM; and the receiver found an aligned authentication path for DMARC. The SPF pass is not the aligned path in this example.

Also inspect the actual DKIM-Signature d= and s= values. Query s._domainkey.d using those values, not a selector guessed from a DNS scan. If several signatures exist, identify a passing aligned signature. A provider-domain signature alone is insufficient for your custom From domain.

Completion requires all three observations: the intended From domain is used, its intended branded DKIM signature reports dkim=pass and aligns under the effective adkim mode, and the trusted receiver reports dmarc=pass. Do not accept DNS verification, an unrelated passing signature or an illustrative header as a substitute.

Separately investigate actual SPF fail or softfail results against the evaluated identity and connecting IP, permerror for invalid/duplicate policies or lookup-limit errors, and temperror for temporary DNS failures. Check whether delivery was direct or forwarded. A provider-domain spf=pass that is merely unaligned is different from an SPF evaluation fault. Do not dismiss a real SPF error because aligned DKIM supplies DMARC success; an Appian-envelope problem is not repaired by blindly editing your company's SPF. SPF result meanings.

Retest each material sending path and environment. Authentication success does not guarantee inbox placement, and one sample does not validate all system notifications or process activities.

EmailAuth's raw-versus-aligned DKIM guide explains why a cryptographically valid signature and DMARC alignment are separate checks.

Troubleshoot the failing layer

For escalation, retain the environment, process name, timestamp, sender domain, DNS owner, verification status and trusted authentication results. Share message contents and recipient details only through approved support channels.