Appointedd SPF, DKIM and DMARC setup, step by step

To authenticate your own email domain in Appointedd, open app.appointedd.com → Setup → Edit business profile, enter your send-from address under communication details, and publish the three customised CNAME records Appointedd generates. Return to the same screen and click Authenticate. Then test a real booking-email route: DNS verification alone does not prove that the intended branded message passes DKIM and DMARC.

This procedure covers Appointedd's documented native booking-email workflow. It is not the new Hub's custom domain setup for a microsite or booking widget, and it does not require a guessed SPF include at your root domain.

The controlling [Appointedd email-authentication guide](https://support.appointedd.

On this page

• Before you change anything
• Get the account records
• Publish CNAMEs safely
• Understand SPF
• Preserve DMARC
• Check DNS and authenticate
• Test actual booking-email identity
• Troubleshooting
• Frequently asked questions

Before you change anything

You need access to the business profile in the Appointedd account that sends the messages, an organization-owned send-from domain, and permission to edit its authoritative DNS. The public email guide does not establish a particular paid tier or named administrator role; confirm that your account exposes the documented controls rather than assuming a plan entitlement.

Record the intended From address, existing authentication records and the relevant DNS authority. Your registrar and authoritative DNS host may be different companies. If the sending subdomain or _domainkey namespace is delegated, its records belong at that delegated authority, not automatically in the parent zone.

Also check whether another application in the business already sends through SendGrid. Appointedd explicitly requires its support team to generate custom CNAMEs in that situation. Request those before changing existing records. Do not overwrite another application's selectors because the Appointedd screenshot happens to show the same names.

If you use Gmail, Outlook or another public email domain

You cannot authenticate a domain you do not control. Appointedd's current guide offers its default noreply.bookings@appointedd.com address when you do not use a custom domain. It also warns that replies to this address bounce because there is no associated inbox.

An older delivery article recommends Gmail or Outlook impersonation. Do not use that older workaround in place of the August 2026 instructions. For branded sending, use an owned domain and complete its authentication; otherwise understand the default address's reply limitation before choosing it.

1. Get the three records from the correct account

Follow the current setup instructions:

1. Sign in at app.appointedd.com.
2. Open Setup → Edit business profile.
3. Find communication details and the send-from email setting.
4. Enter the address Appointedd should use for your customer emails.
5. Copy all three customised DNS records, retaining each full host, record type and target.

The published screenshot contains one sender-domain CNAME and two DKIM-selector CNAMEs. Its tenant identifiers, selector names and targets are examples, not reusable records. Use the current account's values, including any custom records supplied to avoid a SendGrid conflict.

A safe worksheet is:

Sender-domain CNAME: FULL_ACCOUNT_ISSUED_OWNER -> EXACT_ACCOUNT_ISSUED_TARGET
DKIM CNAME 1: FULL_ACCOUNT_ISSUED_DKIM_OWNER_1 -> EXACT_ACCOUNT_ISSUED_TARGET_1
DKIM CNAME 2: FULL_ACCOUNT_ISSUED_DKIM_OWNER_2 -> EXACT_ACCOUNT_ISSUED_TARGET_2

These are placeholders, not records to publish. Keep both issued DKIM aliases, but do not expect both selectors to sign every message. The signature on an actual message identifies the selector used for that message.

Do not confuse the new Hub's website domain with email authentication

Appointedd's separate Hub custom-domain guide concerns microsite or booking-widget URLs and cancellation links. Its website CNAME, certificate and deployment workflow does not authenticate an email From domain. The website feature's paid-add-on note is not evidence of an email-authentication fee or entitlement.

If your account only exposes the new Hub and not the email controls described here, obtain the supported email-authentication path from Appointedd. Do not reuse the website CNAME or invent a matching Hub menu.

2. Publish the CNAMEs without disrupting other senders

At the DNS provider that actually serves each owner, create the three records with their issued CNAME type and exact targets. A target is a DNS hostname, not a URL, IP address or TXT value.

Map full names to your DNS editor carefully. For example, an illustrative full owner SELECTOR._domainkey.bookings.example.com would normally be entered as:

• SELECTOR._domainkey.bookings in the example.com zone;
• SELECTOR._domainkey in a separately hosted bookings.example.com zone;
• SELECTOR in an existing delegated _domainkey.bookings.example.com zone.

Some editors accept the full name instead. Confirm the resulting full owner so the editor does not append the domain twice. Preserve existing NS delegations rather than deleting them to make a record fit.

At each CNAME owner, inspect existing records first. Do not add a CNAME alongside TXT, A, AAAA, MX or another conflicting CNAME. If a selector is occupied, retain the working record and resolve the conflict with Appointedd and the DNS owner. This is an alias restriction under RFC 1034 section 3.6.2, not a reason to remove another sender's key.

Keep the issued aliases visible

For Cloudflare, set these records to DNS only, not HTTP-proxied. Turn Flatten off for each issued alias where a per-record control is available. Check applicable whole-zone flattening, apex handling and same-zone-target behavior as well, because they can conceal a CNAME even when proxying is off.

Ensure the required literal CNAME answers remain visible. If that requires a shared-setting change or affects a delegated namespace, coordinate a narrow solution with the DNS administrator and Appointedd. Do not disable unrelated global features or remove delegations blindly. See Cloudflare's proxy status and flattening controls.

3. Understand what SPF does, and what not to add

Appointedd's current native setup provides three CNAMEs, not a universal root-domain SPF include. Do not add a generic SendGrid include merely because the account targets contain SendGrid hostnames.

SPF evaluates the actual SMTP MAIL FROM domain, usually reflected in the received Return-Path, rather than automatically evaluating the visible From address. Appointedd's public procedure does not establish a fixed runtime envelope domain or a user-controlled custom-envelope setting. Inspect the actual message before deciding that root SPF needs a change.

Where an SPF policy genuinely needs maintenance, preserve one v=spf1 TXT record per evaluated owner, along with existing legitimate sender authorizations and the chosen qualifier. Do not publish a second policy. Review the full evaluation against the 10 DNS-dependent-term limit, including nested mechanisms, not merely ten written include entries. An all mechanism makes a redirect modifier unused, so blindly merging an all-ending template can remove another sender's authorization. These rules are defined in RFC 7208.

A child envelope domain can align with a parent From domain under relaxed SPF alignment but not strict alignment. Do not promise strict SPF alignment from the presence of the sender-domain CNAME. SPF fail, softfail and policy qualifiers also do not determine delivery by themselves.

4. Preserve DMARC and plan monitoring safely

Discover the policy that applies to the intended visible From domain before adding or changing DMARC. Check its direct record and any applicable inherited policy using current policy discovery, including an existing _dmarc alias if present. Keep established enforcement, alignment settings and authorized report recipients. Appointedd authentication is not a reason to replace p=quarantine or p=reject with p=none.

Under RFC 9989, DKIM alignment compares the signature's d= domain with the visible From domain. Relaxed alignment uses the Organizational Domain; strict adkim=s requires exact equality. SPF has its own aspf setting. A passing aligned path can produce DMARC pass, but this new DKIM setup should be accepted only after the intended branded DKIM signature itself passes and aligns.

Only if there is no applicable policy

If there is no direct or applicable inherited DMARC policy, and the domain owner approves an initial monitoring plan, a first record can use this structure:

Type: TXT
Full owner: _dmarc.FROM_DOMAIN
Value: v=DMARC1; p=none

Replace FROM_DOMAIN with the actual visible From domain. For bookings.example.com, the full owner is _dmarc.bookings.example.com: enter _dmarc.bookings in the parent zone or _dmarc in a separately authoritative child zone. Do not add this TXT at an existing CNAME owner or alongside another DMARC policy. p=none requests no DMARC enforcement and, without rua, requests no aggregate reports; it is not a completed monitoring program or a deliverability fix.

Add a rua destination only after approving the reporting service, recipient and data-sharing purpose. When the report URI host has a different Organizational Domain from the domain where the DMARC policy was found, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain is excepted, even if the hostnames differ. See RFC 9990 section 4. Use the reporting provider's exact authorization instructions; DNS authorization does not replace privacy approval. Do not copy a tutorial's report address or send customer message content to an unapproved analyzer.

5. Check DNS, then click Authenticate

Replace the placeholders below with the actual authoritative server, a recursive resolver and each full issued owner. These are diagnostic commands, not observed results:

dig @AUTHORITATIVE_SERVER FULL_ISSUED_OWNER CNAME +noall +answer
dig @PUBLIC_RESOLVER FULL_ISSUED_OWNER CNAME +noall +answer
dig @PUBLIC_RESOLVER FULL_ISSUED_DKIM_OWNER TXT +noall +answer

Repeat the CNAME checks for all three records. Require exact owners and targets from the current Appointedd packet. Follow each DKIM alias to its complete public-key TXT record; a nonempty but wrong tenant target is not a match. If the answer is empty, inspect the full response without +noall +answer to distinguish a negative answer from a resolver or delegation failure.

Return to Edit business profile and click Authenticate. The current screenshot shows verified status for each matching record. If validation fails, resolve the discrepancy rather than repeatedly replacing records. The email-authentication guide gives no fixed propagation guarantee; authoritative publication, recursive caching and Appointedd's check are separate stages.

6. Test the actual booking-email identity

After the organization has approved implementation and testing, use controlled recipients and an authorized test booking that does not disrupt a real customer's appointment. Exercise each relevant confirmation, reminder and follow-up path. A generic message from another SendGrid application does not test Appointedd.

For each delivered sample, confirm:

1. The visible From is the intended company address, including any message-specific override.
2. The intended Appointedd DKIM signature has a receiver-confirmed dkim=pass and an aligned d= under the current policy.
3. The receiver reports dmarc=pass for that intended From domain. A pass caused by SPF alone does not prove this DKIM setup works; a rewritten provider-owned From does not prove your brand was authenticated.
4. SPF is assessed separately at the actual smtp.mailfrom identity. Investigate fail, temperror and permerror even if aligned DKIM supplies DMARC pass.

Use receiver-controlled authentication diagnostics, or have the receiving administrator establish which Authentication-Results fields were produced inside the service's known processing boundary. Confirm its documented handling strips or reliably distinguishes externally supplied fields, and ignore untrusted or attacker-supplied results. A familiar authserv-id or header position alone is insufficient. If provenance cannot be established, repeat the controlled test at a receiver with trustworthy diagnostics. See RFC 8601 section 7.1.

For a DKIM failure, read d= and s= from the same signature and inspect s._domainkey.d. EmailAuth's guide to finding a DKIM selector explains that lookup. Keep private keys private; DNS contains public verification material. A successful sample is evidence for that route, not every Appointedd message or guaranteed inbox placement.

Troubleshooting booking emails

Appointedd's delivery troubleshooting page makes an important distinction: Customers → customer record → Communications shows whether a customer message was triggered to send. It does not prove the receiving server accepted it.

• No communication entry: inspect whether that email type is enabled and whether the customer record has a valid address. DNS cannot fix a message that was never triggered.
• Entry exists but no message arrives: verify the address, relevant folders and receiver rejection evidence. Review the actual From and authentication results rather than assuming the log proves delivery.
• Only reminders or follow-ups fail: check their send-from overrides. Authenticating the business profile does not establish that every configured override uses the same domain.
• CNAMEs already exist: check for another SendGrid sender and request Appointedd's supported custom records. Do not repoint shared selectors.
• Authenticate fails: check authoritative DNS, full owner spelling, exact targets, CNAME conflicts, proxying, flattening and cached answers.
• DKIM passes but DMARC fails: compare the passing d= with the actual From and its alignment policy. Do not weaken DMARC to conceal an identity mismatch.
• Replies bounce from the default sender: this is the documented no-inbox behavior, not an SPF failure.

If support is needed, share only approved details relevant to the incident: sender, recipient, time and booking reference. Redact unnecessary customer information. Do not change parent nameservers, MX or DNSSEC just to make this CNAME-only procedure work.

For rollback, pause the affected automation or route under an approved operational plan, retain the issued packet and previous configuration, and restore only a known working, authorized sender configuration. Removing selectors can break other applications or queued messages. Retest after restoration and cache expiry; switching to the default sender changes identity and reply behavior and should be a deliberate decision.