Apptoto SPF, DKIM and DMARC setup, step by step

On this page: Choose the sending route · SPF · DKIM · DMARC · Verification · Troubleshooting · FAQs

For custom-domain email sent by Apptoto itself, its documented SPF authorization is a:mailers.apptoto.com. Set up DKIM under Settings → Outgoing Email → Email Domain Settings (DKIM), add your domain, publish all three generated CNAMEs, then select Verify DNS Settings and require all three results to show true. Connected Gmail or Microsoft mailbox sending is a different route and does not need these Apptoto-specific DNS additions. Apptoto deliverability setup

This guide covers appointment and other customer emails sent through Apptoto, with particular attention to custom-domain and calendar-specific senders. It is not a DNS recipe for SMS, voice reminders or calendar synchronization. No account configuration, DNS changes, live DNS checks or email tests were performed.

First determine who actually sends the message

Open Settings → Outgoing Email and review the Sending Addresses table, Default address and Calendar-Specific Sending. A connected calendar and a connected sending mailbox are different configuration choices. Do not assume that because appointments synchronize from Microsoft or Google, their reminder emails leave through that mailbox.

Apptoto documents these routes and outcomes:

The last two cases differ: an unmatched calendar address can use native custom-domain sending, while a broken connected mailbox falls back to the provider's address. Apptoto outgoing-email routing and fallback

Employee mail or a connected Microsoft 365 mailbox is a separate sending route; use the Microsoft 365 authentication guide for that route rather than assuming these application records configure it.

Build a sender inventory from actual appointments and calendars, not only the Default row. Record the selected address, domain, intended route, DNS administrator and a representative message type. Check for aliases or spelling differences: a near-match is not an exact mailbox match. Include each distinct business domain that needs authentication.

Before changing anything, export the current DNS zone and retain the current SPF, DKIM, DMARC and MX records. Identify existing marketing and corporate-mail services that use the same domain. Adding an appointment reminder service is not a reason to remove those authorizations.

Configure Apptoto's SPF mechanism without breaking other mail

The required mechanism in the current native-sending instructions is:

a:mailers.apptoto.com

The mechanism authorizes the applicable A/AAAA addresses resolved for mailers.apptoto.com, not every address behind your website or inbound mailbox provider. Confirm that this managed sending authorization is approved; do not add unrelated a or mx mechanisms from another provider's example. SPF a mechanism.

This is an a mechanism, not an include. Apptoto's new-policy example is:

v=spf1 a:mailers.apptoto.com ~all

Use that complete example only after confirming the relevant domain has no existing SPF policy and that its authorized-sender inventory is covered. For an existing policy, add the mechanism before the final all and retain the other legitimate senders. Apptoto SPF instructions

Here is an illustrative merge. The existing provider is a placeholder, not a real authorization to copy:

Before: v=spf1 include:spf.existing-sender.example -all
After: v=spf1 include:spf.existing-sender.example a:mailers.apptoto.com -all

Preserve the intended terminal qualifier rather than replacing an established -all with ~all just because a new-record example uses it. Keep one TXT policy beginning v=spf1 at each owner; multiple policies can cause permerror. Do not remove unrelated TXT verification records. If the current policy delegates with redirect=, review its behavior before editing.

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 identity and DMARC alignment are separate checks

SPF normally evaluates the SMTP MAIL FROM domain, commonly reflected in Return-Path, not the visible From address. An empty reverse path uses the HELO identity for SPF. Publish and inspect the policy at the actual envelope owner. A parent policy does not automatically apply to a subdomain. SPF identity and record selection

Therefore, adding the documented authorization to your business domain does not prove that an Apptoto message uses that domain for MAIL FROM. If the delivered message shows a different envelope identity, evaluate that identity and confirm the intended configuration with Apptoto. An aligned DKIM signature can still satisfy DMARC when SPF is unaligned, but it does not excuse an actual SPF configuration error.

Avoid the static-IP shortcut becoming permanent

The vendor documents an IP-based alternative but warns that the IP can change. Prefer its managed hostname mechanism where possible; do not copy a historical IP into a long-lived policy without confirming the current value and arranging maintenance. Apptoto lookup-limit guidance

SPF's limit is 10 evaluated DNS-query-causing terms, including nested policies, not simply 10 visible includes. Review a, mx, include, exists, ptr and redirect across the evaluation. Remove only authorizations confirmed obsolete, then re-evaluate the complete policy. SPF processing limits

Add the domain, publish three CNAMEs and verify

In Settings → Outgoing Email, locate Email Domain Settings (DKIM). Select Add Domain, enter the business domain and confirm. Apptoto generates three CNAME records. Publish the complete set, return to the same settings page and select Verify DNS Settings. All three Verified values must be true. Current Apptoto DKIM workflow

Treat every owner and target as account-generated data. Do not copy another account's selector, an example screenshot's target or a public key from a generic DKIM generator. The signing service holds the private key; your DNS records must lead to its matching public key.

For an issued full owner SELECTOR._domainkey.appointments.example.com, a relative-name field in zone example.com needs SELECTOR._domainkey.appointments; in a delegated appointments.example.com zone it needs SELECTOR._domainkey. If _domainkey.appointments.example.com itself is delegated, publish SELECTOR at that delegated authority. These are owner-mapping examples, not generated records. Preserve existing delegations and other selectors, and do not change MX, nameservers, DNSSEC or forwarding to make a parent-zone entry visible. DNS zone boundaries.

Before publication:

1. Confirm you are editing the authoritative DNS provider, not an unused zone at the registrar.
2. Check every requested owner for existing records. Stop if a CNAME or TXT record belongs to another application; request a non-conflicting setup rather than overwriting it.
3. Account for automatic zone suffixes. If the full owner is selector._domainkey.example.com, a host field within the example.com zone may need only selector._domainkey. Use the actual generated selector.
4. Preserve each issued target exactly. Do not replace CNAMEs with IP addresses or assume all three records have the same purpose.
5. If using Cloudflare, keep these authentication records DNS only and do not flatten verification CNAMEs. Do not disable protections on unrelated website records.

A CNAME normally cannot coexist with other record types at the same owner. Cloudflare also warns that flattening can prevent third-party verification because the CNAME itself is no longer returned. CNAME constraints, Cloudflare proxy status, CNAME flattening

Where literal CNAME answers are required, the end state is a DNS-only alias returning the exact issued target, without HTTP proxying or flattening hiding it. Turn the relevant per-record Flatten control off when available and ensure applicable zone-wide settings preserve those aliases. On Cloudflare, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are conditional DNS-host behaviors, not assumed controls in every panel. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration with the DNS owner and sending service. Do not blindly change the whole zone or remove an existing NS delegation. Cloudflare CNAME verification, flattening controls and limits.

Apptoto allows up to 48 hours for propagation. If verification remains false after that, compare the exact published host and target with the generated record set and contact support@apptoto.com. You can inspect authoritative DNS immediately; a wrong name or missing record should be corrected rather than left to wait. Apptoto verification troubleshooting

A domain marked verified is a configuration milestone. It is not proof that a particular calendar selected that domain or that a receiver validated its signature. Complete the delivered-message checks below.

Keep DMARC protection while proving alignment

A message passes DMARC if SPF passes with an aligned MAIL FROM domain, or DKIM passes with an aligned d= signing domain. Relaxed alignment accepts domains sharing the organizational domain; strict alignment requires exact equality. The visible From domain is the reference identity, not Reply-To, calendar owner or the mailbox used for account login. Current DMARC specification

Retain any established DMARC enforcement and alignment requirements. Do not replace quarantine or reject with none to get appointment mail delivered before authenticating it. Check inherited policy before creating a subdomain policy. RFC 9989 supersedes RFC 7489 and makes the old pct tag obsolete; do not depend on that tag for a new rollout.

When there is no applicable established policy and the domain owner approves an appropriate monitored deployment, this illustrates a first record:

Type: TXT
Full owner: _dmarc.example.com
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the example names and use an authorized report destination. Within the example.com zone, the relative host is normally _dmarc. For From appointments.example.com, the exact owner is _dmarc.appointments.example.com. Keep one policy at that owner; do not create a child p=none that unintentionally bypasses parent enforcement.

For the child From example, enter _dmarc.appointments in the parent example.com zone, or _dmarc in a separately delegated appointments.example.com zone. A full-name editor requires _dmarc.appointments.example.com. Check the published full owner before saving; do not create an override of an applicable inherited policy.

Review reports across legitimate senders before tightening enforcement. Appointment communications can contain sensitive details, so consider the information disclosure involved before enabling failure reports or sharing raw messages with a diagnostic service. Aggregate-report authorization, failure-report privacy

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.

Validate DNS and each appointment-sending route

Use these read-only patterns with your actual values. They are examples, not executed checks:

dig +short NS example.com
dig @ns1.dns-host.example TXT example.com
dig +short CNAME issued-owner.example.com
dig +short CNAME selector._domainkey.example.com
dig +short TXT selector._domainkey.example.com
dig +short TXT _dmarc.example.com

For SPF, substitute the actual MAIL FROM domain. Repeat the CNAME lookup for all three issued owners. For DKIM, use the message's selector and signing domain, not a guessed s1. Compare authoritative and recursive answers, allowing for prior TTLs. A valid CNAME chain should lead to the intended public key when queried for DKIM TXT data. DKIM key discovery

After verification, send a controlled reminder through each relevant route to an external mailbox you control. Avoid using real client appointment details for diagnostics. Test both the Default route and representative calendar-specific routes. Save the receiving service's trusted Authentication-Results, From, Return-Path and DKIM-Signature. Authentication-Results trust boundary

Establish which results were generated inside the receiving service's known processing boundary and how that service removes, ignores or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving-mail administrator to confirm the boundary. A familiar authserv-id string or header position alone is not proof. Reject attacker-supplied or otherwise untrusted fields; obtain the receiver's own diagnostic evidence when provenance is uncertain. Operational receiving-result trust.

Use these acceptance criteria:

For native custom-DKIM setup, an SPF-only DMARC pass is not sufficient acceptance: the branded DKIM signature itself must pass and align. For a fallback message from Apptoto's address, a provider-domain DMARC pass does not prove your business domain is authenticated.

Repeat after adding calendars or domains, reconnecting mailboxes, changing sender addresses or rotating keys. A single successful reminder does not certify every campaign or future route. Authentication is necessary evidence, not a guarantee of inbox placement.

Troubleshoot Apptoto SPF, DKIM and sender changes

An address shows Needs DKIM setup: confirm which custom domain it uses, publish the generated record set and complete verification for that domain. Do not assume a verified sibling domain covers it.

A mailbox shows Reconnect needed or Cannot send mail: repair the connection or sending permission through the documented mailbox workflow. Until repaired, check for the provider-address fallback described in the route table. Apptoto mailbox statuses

One calendar uses a different sender: compare its configured Email or Admin Email with the connected addresses and the selected Calendar-Specific Sending option. Check the actual message rather than changing DNS for the Default address alone.

One of three CNAME checks stays false: inspect exact owner spelling, suffixes, existing records, proxying and flattening. Check authoritative publication before blaming cache propagation.

SPF has permerror: look for multiple policies, malformed mechanisms or excess DNS-query terms. An a mechanism cannot be replaced with include just because that syntax appears in other providers' guides.

SPF fails while DKIM passes: inspect the envelope domain and final sending IP. fail or softfail can indicate an unauthorized relay or missing authorization; temperror calls for DNS availability checks and a retest. Forwarding can change the connecting IP, so do not authorize the forwarder without understanding the route.

DMARC fails although SPF passes: compare the authenticated envelope domain with From, then inspect DKIM. An unrelated provider identity can pass SPF without aligning.

Authentication passes but reminders reach spam: check the recipient's filtering result, bounce reason, content and sender reputation separately. Keep timestamp, message ID and route evidence when escalating, and redact unnecessary client data.