Establish which venue and notification need testing
A missing booking email can begin with a diary setting, an incorrect sender address, or a receiver decision. Treat those as different investigations. Record the venue, area, notification type, intended From address, and the time of the affected booking before changing authentication records. For a restaurant group, maintain separate evidence for each venue instead of assuming a central domain gives every diary the same configuration.
ResDiary’s January 2026 SPF guidance says its email uses SendGrid and identifies spf.resdiary.com as its published sending authorization. That is ResDiary’s supported instruction, not a reason to create your own SendGrid account or borrow DNS values from another SendGrid customer. ResDiary SPF configuration
The current public sources reviewed here do not establish a ResDiary-specific custom-DKIM provisioning procedure or a supported custom-envelope configuration. This is a source-scope hold, not proof that either capability is absent. Before describing a complete DMARC implementation as ready, obtain provider confirmation for the exact venue and inspect a received message. Do not invent selectors, record targets, or a hidden authentication menu.
Make sure a message is actually being generated
ResDiary documents area-level notification controls under Settings > Areas and identifies separate notification settings for reminders and post-dining messages. Its sender-address instructions use Settings > Venue and Dish Cult Listing Details, under venue contact details. Check the intended setting without treating account-login details as the email sender identity. ResDiary notification troubleshooting
Have the venue owner approve the test arrangement. A booking can affect capacity, staff preparation, and automated follow-up, so use a designated test procedure and clean up the reservation through the normal operational process. Use an authorized test mailbox and harmless details. Avoid using a real diner’s booking as an authentication experiment or triggering an unexpected reminder to a customer.
Run the specific notification being investigated. Check whether it was enabled, whether the booking met its conditions, and whether the destination address was correct. Record the send time and any available message or event reference. If no message was generated, resolve that condition before interpreting a DNS edit as a fix. If the message was generated, separate rejection, quarantine, spam-folder placement, and non-receipt with no available explanation.
Choose a sender address on a domain the venue controls and a reply destination staff actually monitor. ResDiary recommends a private domain rather than using a personal mailbox-provider address for its automated messages. Changing to an owned address is only the start: it still requires the appropriate authentication and a real-message check. ResDiary notification troubleshooting
Prepare the SPF change against the actual route
The provider’s documented mechanism is include:spf.resdiary.com. Its guide explains merging this into an existing policy. Do not replace the venue’s complete SPF record with a one-provider example, because staff mail, website forms, and other legitimate applications may already depend on it. ResDiary SPF configuration
Ask the DNS administrator to capture the current policy and identify the envelope domain being evaluated. Publish at the intended owner using the DNS host’s current controls. Preserve existing authorized senders and evaluate the resulting lookup budget. SPF is not a check of the display name or Reply-To address; multiple applicable SPF records at one owner are also an error rather than a way to add services. SPF RFC 7208
Save the proposed and previous values in the change ticket. Record the authoritative nameservers, publication time, TTL, and independent lookup time. Confirm that the DNS editor has not appended the domain twice. Do not copy receiving-mail records or unrelated SendGrid branding records into this change. None of those actions is established by the ResDiary SPF article.
If a receiver shows SPF pass for a service-owned envelope domain, adding another authorization at the visible From domain may not change that result. First establish which domain the receiver evaluated. This distinction prevents repeated DNS edits that leave the actual message identity unchanged. Ask ResDiary to clarify the supported envelope behavior rather than guessing from an IP address alone.
Close the DKIM and alignment evidence gap
Send an approved booking confirmation to a mailbox where complete headers can be inspected. Preserve the receiver’s trusted Authentication-Results, visible From domain, envelope domain, and every DKIM signature’s d= and s= values. Those signature fields identify the signing domain and selector. Keep the original evidence securely; use a redacted copy in routine review notes. DKIM RFC 6376
Compare the passing domains with the visible From domain under the applicable alignment mode. DMARC requires at least one passing aligned path; two passing results for unrelated domains do not supply it. Use RFC 9989 for the protocol assessment, rather than inferring success from the vendor name in a dashboard. DMARC RFC 9989
If neither path aligns, ask the provider to confirm whether customer-domain signing is supported for this venue’s route. Request the exact DNS records, activation steps, and expected signing identity if it is. If not, ask which supported sender arrangement preserves delivery and accurately represents the venue. Record the answer without generalizing it to other ResDiary products or future versions.
Repeat the check for reminders and post-dining messages that the venue uses. A confirmation test cannot close an untested reminder route. Do not promise inbox placement after authentication succeeds, and do not reduce the organization’s DMARC enforcement just to bypass an unresolved venue configuration.
Fictional diagnosis: the SPF record was not the first problem
In a fictional venue, a manager reports that confirmations work but reminders never arrive. The first suggestion is to add another SPF record. A controlled review instead finds reminders disabled for the tested workflow. After the owner enables the intended behavior, a new test produces a message. Its headers can then be assessed for authentication. This scenario is invented and is not a ResDiary customer finding.
Suppose that message also has a passing signature under an unrelated provider domain, with no aligned SPF path. There are now two distinct findings: the workflow setting explains why the earlier message was absent, while the received message identifies a separate alignment question. The investigator retains both findings and asks for supported domain-authentication instructions instead of declaring the reminder toggle a complete security fix.
Venue implementation worksheet
- Operational scope: venue, area, notification type, business owner, and approved test procedure.
- Sender configuration: visible address, reply handling, domain owner, and date of the setting check.
- Generation evidence: workflow enabled, test booking reference, send time, destination, and observed outcome.
- DNS change: existing SPF, proposed merged policy, authoritative lookup, TTL, and rollback value.
- Message evidence: From domain, envelope domain, all DKIM d=/s= pairs, trusted results, and alignment conclusion.
- Provider clarification: custom-DKIM and envelope support, account-specific records, activation evidence, and unresolved questions.
- Closure: confirmation and reminder retests, booking cleanup, reviewer, and next review trigger.
Keep the worksheet with the venue’s change history. Revisit it when the sender domain, group ownership, booking workflow, or provider instructions change. Retire obsolete authorization only after checking that another active venue does not still depend on it.
Release status
The manuscript has first-party evidence for venue controls and SPF guidance, but not a complete custom-domain signing procedure. Tenant inspection, live DNS, received-message validation, visual review, human SME approval, and publication remain pending. The product-specific signing hold must be resolved or retained explicitly in the final scope.
Preserve the enforcement decision while merging SPF
Use the provider mechanism within the single applicable TXT policy after reviewing the actual SMTP identity. The sample softfail ending is not permission to weaken an existing policy. Keep the DNS owner decision and the unresolved custom-signing question separate from whether a booking notification was enabled.
Separate message acceptance from policy rollout
A passing aligned SPF result can satisfy a message evaluation, but does not alone justify moving an entire domain to reject. RFC 9989 Section 7.4 requires valid DKIM for domains publishing p=reject and warns about indirect-mail interoperability. Inventory all legitimate senders and indirect routes before the policy owner approves enforcement. No DNS change, tenant operation or received-message test was executed for this article.