Tipalti domain registration uses an ownership TXT record followed by an account-issued DKIM CNAME. Do not copy an example selector or add an SPF include to your main domain merely because Tipalti uses Amazon SES. The default envelope sender and an optional custom MAIL FROM are different configuration paths.
This guide covers existing Tipalti Hub branded notification domains, not bill-collection mailbox access or payment administration. No customer account, DNS zone or delivered message was tested for this article.
Decide which identity you are configuring
The visible From address is the identity people see. DKIM signs with a domain in the signature's d= field. SPF evaluates the SMTP envelope sender, normally visible as Return-Path after delivery, rather than automatically evaluating the visible From domain. Those identities can differ legitimately.
Tipalti's FAQ describes a default Amazon SES Return-Path and a support-enabled custom MAIL FROM alternative. Registration enables branded DKIM; custom MAIL FROM is a separate choice. Static-IP reception is another option, not an SPF or DKIM shortcut. See Tipalti's domain setup FAQ.
Before starting, record the intended From domain, the existing DMARC policy and the people authorized to approve DNS changes. Export the relevant DNS records, including values and TTLs. Do not move nameservers, disable DNSSEC, replace normal mailbox MX records or connect an inbox for this task. The domain registrar is not necessarily the authoritative DNS operator.
Register the domain in Tipalti Hub
Use a Technical admin, or a custom role with Payer Administration and Edit Templates permissions. Open Administration > Communication > Domain registration, choose New Domain, enter the domain and continue. Copy the issued TXT owner and value into authoritative DNS. This proves ownership; it is not an SPF policy or a DKIM key.
Wait for Ownership verified, then select Continue registration. Publish the displayed CNAME exactly. Complete registration within the documented 72-hour window; use Retry registration if the attempt expires. The expected final status is Registered, not merely ownership verified. Tipalti's current domain registration instructions show both stages and their separate statuses.
Use the records in your own current account. The documentation's screenshots contain demonstration domains and development-looking targets; they are illustrations, not reusable production values. Copy every required field from the issued packet, including type, full owner and target. If your account differs from this documented flow, stop and obtain the applicable instructions instead of guessing an equivalent control.
Publish the DKIM CNAME at the correct owner
A DNS editor may ask for a full name or append its zone automatically. Always inspect the resulting fully qualified name before saving. The following is a naming example, not a Tipalti selector or target:
Issued owner example: SELECTOR._domainkey.billing.example.com
Zone example.com: SELECTOR._domainkey.billing
Delegated zone billing.example.com: SELECTOR._domainkey
Delegated zone _domainkey.billing.example.com: SELECTOR
Use the server authoritative for the actual owner. An existing _domainkey delegation may place that responsibility somewhere other than your normal website DNS panel. Preserve delegations and other selectors; never remove NS records just to make an entry fit.
A CNAME owner must not already contain conflicting TXT, A, AAAA, MX or another CNAME record. Inspect a collision with the DNS owner and Tipalti before changing anything. A record used by another sender is not disposable. Keep the new target exactly as issued; do not replace it with the public TXT key found by following the alias.
The alias must remain visible as the required DNS CNAME. On Cloudflare, use DNS-only rather than HTTP proxying. Where available, turn off the relevant record's Flatten option and ensure zone-wide flattening does not suppress that alias. Apex and same-zone behavior can override ordinary settings; if mandatory behavior prevents the required answer, coordinate a supported solution rather than making a global change. These are conditional checks, not instructions to disable flattening across a working website. See Cloudflare's current CNAME-flattening controls.
Configure SPF only for the actual MAIL FROM path
For a custom MAIL FROM, contact Tipalti Support, agree the subdomain and obtain its MX and TXT packet. Publish only the authorized records, then have Tipalti verify and activate that route. Its FAQ does not provide a universal customer-specific packet. Keep ordinary inbound mail separate; replacing the main domain's MX records could redirect business email. Tipalti's custom MAIL FROM procedure is support-mediated, not a self-managed SES configuration tutorial.
At the actual SPF owner, there must be one v=spf1 policy, not a second competing SPF TXT record. If a policy already exists, merge only the authorized change while preserving other legitimate senders and qualifiers. Do not blindly add mx, change ~all to -all, or authorize broad infrastructure just to clear a warning. The evaluation limit is ten DNS-dependent terms, including nested processing, not ten includes in the visible record. An all mechanism makes redirect in the same policy irrelevant. Qualifiers do not guarantee a particular recipient's delivery decision. See RFC 7208.
Mapping a support-issued owner follows the same zone rule: for bounce.billing.example.com, enter bounce.billing in the example.com zone, or bounce in a separately delegated billing.example.com zone. Use the actual packet, not these placeholders. Confirm MX routing consequences with the mail owner before publishing.
Preserve DMARC protection and check alignment
Do not weaken an existing DMARC policy to register Tipalti. Inspect both a direct policy and any applicable inherited policy. Changing DNS syntax is not permission to reduce protection, add report recipients or switch sending identities.
DMARC needs a passing aligned SPF or DKIM identity. Relaxed alignment compares Organizational Domains; strict alignment requires an exact domain match. adkim governs DKIM and aspf governs SPF independently. For example, From billing.example.com and a passing DKIM d=billing.example.com match strictly. An envelope domain bounce.billing.example.com may align relaxed with that From but is not a strict SPF match. Do not promise that a branded subdomain automatically meets both strict modes. RFC 9989 explains alignment; Tipalti asks customers with strict settings to contact support before changes.
Only if no applicable policy exists and the domain owner approves a monitoring plan, an initial policy can use the following value:
TXT owner: _dmarc.billing.example.com
Value: v=DMARC1; p=none
This is a conditional example for the example From domain, not a replacement for existing enforcement. In a parent example.com zone the relative owner is _dmarc.billing; in a delegated billing.example.com zone it is _dmarc. Use the policy location appropriate to your domain, without creating duplicates.
Add aggregate-report destinations only with an approved recipient and privacy decision. A destination in a different Organizational Domain requires the receiving report generator to check DNS authorization; a destination within the same Organizational Domain is excepted. A different hostname alone does not establish an external destination. RFC 9990 section 4 defines that distinction. DNS authorization does not replace consent to share reporting data.
Verify DNS, registration and a real notification separately
DNS resolution, the Tipalti status and delivered-message authentication are three different checks. Start with read-only queries using the actual issued names:
dig TXT OWNERSHIP_OWNER
dig CNAME ISSUED_DKIM_OWNER
dig TXT ISSUED_DKIM_TARGET
dig MX CUSTOM_MAIL_FROM_OWNER
dig TXT CUSTOM_MAIL_FROM_OWNER
Run the last two only for an approved custom MAIL FROM configuration. These are command templates, not results from a customer domain. Confirm answers at authoritative DNS, then public resolution after relevant caches expire. Check the exact CNAME target and full TXT values; a generic DNS lookup of the website's root is insufficient.
After Registered and any custom MAIL FROM activation, send an authorized test notification through the intended Tipalti route to a controlled recipient. Do not initiate payments or change real payee records merely to manufacture a test. Arrange an approved non-production or otherwise safe test with the account owner if necessary.
Use the receiving service's authentication output produced inside its documented trust boundary. Confirm how that service strips or disregards externally supplied Authentication-Results. A familiar authserv-id, header position or attacker-inserted dkim=pass line is not proof. RFC 8601 explains that trust requirement.
For the branded DKIM goal, require the intended Tipalti signature to pass and its d= domain to align with the intended From under the existing policy. Require the trusted receiver's DMARC pass too. SPF-only DMARC success does not demonstrate that DKIM works. Record the actual envelope domain and investigate SPF fail, temperror or permerror separately even when DKIM passes. EmailAuth's raw versus aligned DKIM guide explains why a valid signature and an aligned signature are different findings.
Troubleshoot without weakening security
- Ownership still pending: compare the issued TXT name and value with authoritative answers. Check wrong-zone edits and an accidentally repeated domain suffix before restarting.
- Ownership verified but registration pending: inspect the issued CNAME, collisions, proxying and flattening. Ownership alone does not complete signing setup.
- Registration expired: use the current retry flow and recopy its instructions. Do not assume a previous packet remains applicable after a restart.
- DKIM passes for the wrong domain: capture the intended From and each signature's
d=ands=values. Ask support to confirm the registered identity used by that notification. Do not accept an unexpected provider-From rewrite as branded success. - DMARC fails despite an SPF pass: compare the envelope domain with From under
aspf; then check the intended DKIM path. Publishing SPF at From does not fix a different envelope owner. - No message arrives: separate authentication from rejection, suppression, recipient address and transport problems. Give support the redacted timestamp, message identifier and failure evidence, not passwords or private keys. A successful DNS change does not guarantee inbox placement.
Rollback should restore only the exact changed records from the approved snapshot, with the mail owner's agreement. Do not delete an active Tipalti registration as a casual diagnostic: it can stop sending on behalf of that domain. Investigate dependencies before removing DNS records after retirement.