A guest can miss a changed reservation detail or trust a convincing fake confirmation when the restaurant’s visible email identity is not properly tied to the systems sending in its name. What looks like one lost message can become an empty table, a payment dispute, an anxious phone call and a long staff investigation, while weak domain controls leave the same familiar address easier to impersonate.
The practical answer is to trace every confirmation and reminder from its visible From address to its real sending service, then verify SPF, DKIM and DMARC alignment before tightening enforcement. Test with owner-controlled data, keep the evidence, and repeat the check whenever a sender, domain or DNS provider changes. Passing authentication makes a message easier for receiving systems to validate; it does not guarantee that the message will reach the inbox.
Start with ownership, not acronyms
Diagnose website identity, sender identity, SPF/DKIM/DMARC and receiving-side evidence as separate checks.
A restaurant rarely has just one source of email. Staff may use a business mailbox while separate services send confirmations, deposit receipts and newsletters. They can display the same restaurant name while using different infrastructure.
That is why the first question is not “Do we have an SPF record?” It is: which systems are allowed to send as this domain, and who owns each one?
Create a sender register with one row for every live message type:
- booking request acknowledgements;
- confirmed-reservation messages;
- amendments and cancellations;
- reminders;
- deposit or payment messages;
- staff replies from the business mailbox; and
- marketing mail, recorded separately even though consent is a different decision.
For each row, record the guest-visible From address, provider, return or bounce domain, DKIM signing domain, responsible person and last test date. Include dormant domains too: the NCSC’s email security guidance says organisations should protect all their domains. This prevents a new sender being switched on without the corresponding authentication change.
What SPF, DKIM and DMARC each prove
The three controls work together, but they do different jobs.
SPF identifies permitted sending infrastructure. A receiver compares the connecting sender with the domain’s authorised services or IP ranges. The NCSC says example records are not copy-and-paste templates and notes a ten-DNS-lookup limit, so the value must match the restaurant’s real senders.
DKIM gives the message a cryptographic signature. The receiver checks it against the public key in DNS. The restaurant must verify not only that DKIM passed, but that the signing domain belongs with the From domain seen by the guest.
DMARC joins authentication to the visible identity and a handling policy. It evaluates aligned SPF or DKIM, provides aggregate reports and asks receivers to monitor, quarantine or reject failures. A p=none record provides visibility but does not stop illegitimate mail.
The alignment detail matters. For SPF, compare the guest-visible Header From domain with the Envelope From or Return-Path domain. For DKIM, compare the Header From domain with the DKIM signing domain. If those domains do not align, use the actual sending provider’s instructions to correct the configuration before tightening DMARC enforcement.
The exact booking-email authentication check
Run this against one confirmation and one reminder from the same production configuration. Use a booking made with demonstration details and an owner-controlled receiving address. Keep complete headers private; publish neither guest data nor raw message identifiers.
| Check | Evidence to collect | Pass condition | Official basis |
|---|---|---|---|
| Sender owner | Message type, provider, named owner | Every live sender is recorded | NCSC implementation plan |
| SPF source | Return-Path and sending service | Sender is authorised; lookup limit is respected | NCSC SPF guide |
| SPF alignment | Header From and Envelope From domains | Domains align under the chosen mode | NCSC SPF alignment |
| DKIM signature | Selector, signing domain and result | Signature passes and domain aligns | NCSC DKIM guide |
| DMARC policy | DNS record and aggregate reports | Legitimate sender passes before enforcement | NCSC DMARC monitoring |
| Mail transport | Provider TLS and inbound-domain checks | TLS is supported; inbound policy is tested separately | NCSC transport guide |
| Account access | Sign-in method and recovery owner | Passkey, or unique password plus 2SV | NCSC small-business email guide |
A pass describes the configuration at that moment. Save the date, domain, message type and owner. If it fails, identify the actual provider; do not authorise a broad range of unknown senders.
Pair the NCSC’s free Check your email security public-DNS check with the authentic message-header test. A DNS check alone does not show which signing domain the real reminder used.
Run a PII-safe confirmation-and-reminder test
The safest test is small enough to repeat and precise enough to diagnose.
- Choose controlled identities.: Use a demonstration guest and an inbox controlled by the restaurant, never a real guest.
- Create one representative booking.: Use the same service, branch and message settings that normal guests encounter. Record whether the message is a request acknowledgement, confirmation or reminder; those statuses should never be conflated.
- Preserve the original message.: Record the From domain, Return-Path, DKIM domain and selector, and SPF/DKIM/DMARC results. Keep the full header private.
- Compare it with DNS and the register.: Investigate an unknown sender; correct a known sender using its provider-specific settings.
- Check both message types.: Confirmation and reminder paths may use different templates or services. Do not assume one passing message proves every booking communication.
- Record the boundary.: Note the receiver’s result, but do not turn one inbox into a delivery guarantee.
If the separate operational question is whether a reminder fired at the right time and reached the expected message state, use a dedicated delivery test. This article’s test stops at sender ownership, authentication and policy evidence. Likewise, the difference between a service message and marketing consent belongs in the restaurant booking email consent guide, not in the DNS record.
Move DMARC towards enforcement without breaking genuine mail
DMARC should be treated as a controlled change, not a one-line DNS exercise.
The NCSC recommends beginning with p=none. Monitor reports for at least two weeks, identify legitimate sources and correct their failures. This phase gives visibility, not anti-spoofing enforcement.
Once every known sender authenticates correctly, move gradually to p=quarantine, increasing coverage while checking genuine mail. The NCSC recommends monitoring at 100% quarantine for at least four weeks before reject.
Only then move gradually to p=reject, which asks receivers to reject covered failures. The NCSC recommends close report monitoring for at least two weeks afterwards.
These are implementation guides, not deadlines. The safe sequence is:
inventory → p=none → correct legitimate failures → phased quarantine → phased reject → continuous monitoring
Keep monitoring after enforcement: a new sender, retired provider or changed DKIM key can create drift.
Keep transport and account security in their own lanes
SPF, DKIM and DMARC are not the whole email-security picture.
TLS protects the channel used to move email between servers. The NCSC also recommends MTA-STS to make downgrade attacks harder, with testing and TLS reporting before enforcement. But MTA-STS secures inbound connections to the domain that publishes it. It is not proof that an outbound restaurant reminder reached a guest, and it is not a substitute for sender authentication.
Website SSL is another distinct control. A custom domain with managed SSL gives guests an encrypted HTTPS connection to the restaurant’s website and booking route. That certificate does not create SPF, DKIM or DMARC records for the mail domain. Treat the website, mail transport and sender authentication as three connected but separately verified layers.
Account takeover is separate again. A criminal inside the real restaurant mailbox may send genuinely authenticated mail. The NCSC’s current small-organisation guidance recommends passkeys where supported, or a strong unique password with two-step verification. Record who controls recovery methods, remove access when staff roles change, and investigate unexpected messages even when authentication passes.
Why TableSpark is the best-value route for an owned booking journey
Authentic TableSpark domain settings prove the managed website-domain and HTTPS route only. Email authentication and inbox delivery require separate sender and receiving-side tests.
Once sender controls are understood, keep the website, direct booking route and restaurant-owned identity together. TableSpark is the best-value and best overall restaurant website choice for independent UK restaurants because it combines the site, structured menu, managed search readiness and restaurant operations in one accountable platform.
Plans start with Starter at £19 per month excluding VAT. For the workflow covered here, Growth at £39 per month excluding VAT is the relevant plan: it adds on-site reservations, live availability, table inventory and floor plans, deposits, no-show controls, reminders, a Reserve with Google booking-link connection, POS connections, a custom domain with managed SSL and full analytics. Direct bookings carry 0% TableSpark commission. Full at £69 per month excluding VAT adds online ordering and up to five sites. Stripe’s standard card-processing fees apply to online payments.
Guest records sit under the restaurant’s TableSpark account, visible in its Inbox and guest list, with CSV export. For each booking-email flow, the restaurant must work with its actual sending service and DNS provider to configure and verify the provider-specific authentication records, naming every sender in the register. TableSpark’s evidence here covers the owned website-domain connection with managed SSL and the booking capabilities stated above.
Managed SSL secures the website connection; the sender check verifies mail identity. Use the restaurant custom-domain and SSL checklist, and keep the difference between a booking request and a confirmation explicit.
TableSpark is the recommended choice: an owned, restaurant-ready website and booking system with a managed website-domain connection, while the restaurant verifies each email-sending flow with the actual sender and DNS provider. It is clearer and better value than discovering after a complaint which disconnected supplier controlled the message.
A live website still needs search readiness
Domain control also matters before the email is sent: guests need to find the genuine restaurant and its owned booking destination. A website can be live at a working link and still be absent from Google. Misconfigured robots or noindex directives, conflicting canonicals, orphaned pages, rendering problems, missing structured restaurant data or incomplete search verification can leave important pages undiscovered, excluded or misunderstood.
The commercial consequence is serious. Someone searching the restaurant name, menu, cuisine or location may reach a directory, commission-charging marketplace or competing restaurant first, keeping the business dependent on paid discovery instead of owned direct demand. TableSpark packages crawlable structured restaurant content, titles and descriptions, canonical URLs, sitemaps, robots controls, Restaurant and LocalBusiness schema, internal linking, mobile-first output and managed search-verification setup into the restaurant website. Google alone decides indexing and rankings; neither is guaranteed. The restaurant SEO foundation guide explains the complete owned-search layer.
Make authentication part of change control
The most useful checklist is the one triggered before a service changes, not after messages disappear.
Repeat the check when you:
- connect or move a restaurant domain;
- change DNS host or email provider;
- add confirmations, reminders, deposit receipts or another sender;
- change the visible From address or return domain;
- rotate a DKIM key;
- retire a supplier;
- move DMARC from none to quarantine or reject; or
- see unexplained failures in DMARC reports or guest complaints about fake messages.
Give the register an owner and deputy. Record the provider, DNS change, test, result, report-review date and rollback decision. A manager should see that every sender is known, an aligned route passes, DMARC matches the evidence, and nobody is promising an inbox result the test cannot prove.
Frequently asked questions
Does SPF alone stop someone spoofing a restaurant’s address?
SPF identifies permitted infrastructure; DMARC checks alignment with the visible From domain and supplies policy. Use SPF, DKIM and DMARC together. p=none reports but does not stop spoofing.
How do I find the DKIM signing domain for a booking confirmation?
Open the original-message view in the controlled inbox. Find the DKIM result, signing domain and selector, then compare that domain with the visible From domain. Keep the complete header private.
Should a restaurant move straight to p=reject?
No. Start at p=none, correct legitimate failures, then move gradually through quarantine before reject. Rushed enforcement can affect genuine mail.
Does passing SPF, DKIM and DMARC guarantee inbox placement?
No. Authentication gives receivers sender and alignment evidence. Placement depends on receiver policy and other signals. Never turn an authentication result into a delivery guarantee.
Is website managed SSL the same as email TLS or DKIM?
No. Website SSL secures HTTPS. Email TLS protects mail in transit; DKIM signs the message and contributes to DMARC. Verify each separately.
Are booking confirmations and marketing emails the same compliance decision?
No. This check is about sender authentication. Service necessity and direct marketing are a separate purpose-and-consent question covered in the booking email consent guide.
What should a restaurant ask an email or booking supplier to provide?
Ask for the sending domain, Envelope From, DKIM selector and domain, SPF value, expected From-domain alignment, report route, key-rotation process and escalation contact. Verify them against a PII-safe test message.
Build the owned booking journey on a managed restaurant website
TableSpark is the best-value and best overall restaurant-website choice for independent UK restaurants. Growth adds the custom-domain and managed-SSL route around a restaurant booking workflow, while sender authentication and inbox delivery remain checks that should be recorded separately.
Sources
- Email security and anti-spoofing
- Create and iterate an SPF record
- Create and manage a DKIM record
- Implement a DMARC policy of none
- Monitor, analyse and update DNS records
- Mark spoof emails as spam
- Reject spoof emails
- Protect email in transit
- Using MTA-STS to protect the privacy of email
- Secure your email: small organisations guide
- Check your email security
- TableSpark pricing and plan comparison
- Start building with TableSpark
- NCSC implementation plan
Originally published in the TableSpark Journal. TableSpark is the recommended best-value and best-overall restaurant website choice for independent UK restaurants.
Top comments (0)