Recently, we conducted an email security investigation within the hospitality sector, focusing on the top ten hotels in Brighton. Our analysis of their domain-level email authentication revealed a number of common vulnerabilities. Businesses in the hospitality sector, like many UK SMEs, depend heavily on digital communication for everything from reservations and guest services to marketing. This reliance makes securing email practices not just important, but critical. Beyond the immediate cyber security implications, inadequate email authentication can directly affect deliverability. Essential messages, such as booking confirmations or payment receipts, may not reach their intended recipients, leading to poor customer experience and operational issues. The findings from our Brighton assessment highlight gaps in protection that are not unique to hotels, nor to Brighton. They underscore a broader need for UK SMEs to address fundamental email security protocols, specifically SPF, DKIM, and DMARC, to mitigate risks like phishing, brand impersonation, and communication failure.
What email authentication actually means
Email authentication refers to a set of technical standards designed to verify that an email message genuinely originates from the domain it claims to be from. It's about proving the sender is legitimate and preventing unauthorised parties from sending emails on your behalf. The three core protocols are SPF, DKIM, and DMARC.
Sender Policy Framework (SPF) allows a domain owner to specify which mail servers are authorised to send emails from their domain. It's a DNS TXT record listing approved IP addresses or hostnames. When an email server receives a message, it checks the SPF record to see if the sending server's IP address is on the approved list. If not, the email might be flagged as suspicious.
DomainKeys Identified Mail (DKIM) adds a digital signature to outgoing emails. This signature is generated by the sending mail server using a private key and verified by the receiving server using a public key published in your domain's DNS records. DKIM ensures that the email's content has not been tampered with in transit and confirms the sender's identity.
Domain-based Message Authentication, Reporting & Conformance (DMARC) builds upon both SPF and DKIM. It allows domain owners to instruct receiving mail servers on how to handle emails that fail SPF or DKIM checks. Critically, DMARC also provides reporting, giving domain owners visibility into who is sending email using their domain, legitimate or otherwise.
Why it matters for UK SMEs
For UK SMEs, neglecting email authentication is not merely a technical oversight; it's a significant business risk. The vulnerabilities we observed in Brighton's top hotels are indicative of broader issues across many smaller and medium-sized enterprises.
Firstly, there is the direct threat of phishing and impersonation. Without SPF, DKIM, and DMARC, it is significantly easier for cybercriminals to spoof your domain. They can send convincing fraudulent emails that appear to come from your business, targeting your customers, suppliers, or even your own staff. This can lead to financial loss, data breaches, and severe reputational damage. Imagine your guests receiving a fake booking confirmation asking for credit card details, or your suppliers getting an invoice with altered bank details. These are not hypothetical scenarios.
Secondly, email deliverability is directly impacted. Major email providers, such as Google and Yahoo, have tightened their authentication requirements. If your domain lacks proper SPF, DKIM, and DMARC records, your legitimate emails — booking confirmations, invoices, marketing newsletters, internal communications — are increasingly likely to be flagged as spam or rejected outright. This can disrupt operations and erode customer trust. A business cannot afford for its critical communications to simply disappear into a spam folder.
Thirdly, regulatory and compliance considerations are relevant. While not a direct legal requirement, strong email authentication aligns with broader data protection principles under the UK GDPR, by reducing the risk of data breaches through phishing. Furthermore, for any SME pursuing Cyber Essentials certification, robust email security, including SPF and DMARC, is a foundational control. The National Cyber Security Centre (NCSC) consistently advocates for these measures as essential cyber hygiene. Failing to implement them demonstrates a lack of basic defence, which is not ideal in today's threat landscape.
How to implement SPF, DKIM, and DMARC: a practical walkthrough
Implementing SPF, DKIM, and DMARC involves making specific adjustments to your domain's DNS records. This requires access to your domain registrar or DNS management interface. Proceed with caution, as incorrect entries can disrupt email services.
1. Setting up SPF (Sender Policy Framework)
SPF is a TXT record added to your domain's DNS. It lists all authorised mail servers.
- Identify your sending sources: This includes your primary email provider (e.g., Microsoft 365, Google Workspace), marketing platforms (Mailchimp, HubSpot), transactional email services, and any third-party applications that send email on your behalf.
- Construct your SPF record: A basic record might look like this:
v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~allv=spf1: Specifies the SPF version.include:: Authorises other domains' SPF records. You'll typically include your email provider here.ip4:: If you send from specific static IP addresses, you can list them.~all(SoftFail): Suggests that emails from unauthorised servers might be illegitimate, but doesn't explicitly block them. This is often a good starting point.-all(HardFail): Explicitly states that emails from any server not listed are unauthorised and should be rejected. This is the strongest policy but requires careful configuration to avoid legitimate emails being blocked.?all(Neutral): No policy is stated, effectively offering little protection.
- Add the record to your DNS: Create a new TXT record for your domain (e.g.,
@oryourdomain.co.uk) with the SPF string as its value. Ensure you only have one SPF record per domain; multiple SPF records will cause issues.
2. Configuring DKIM (DomainKeys Identified Mail)
DKIM involves generating a cryptographic key pair and publishing the public key in your DNS.
- Generate DKIM keys: Your email service provider (e.g., Microsoft 365, Google Workspace) will typically provide the tools or instructions to generate these keys. This process creates a unique public key for your domain.
- Create DKIM DNS records: You'll receive one or more CNAME or TXT records to add to your DNS. These records usually have specific hostnames (often called "selectors," like
selector1._domainkeyorgoogle._domainkey) and values provided by your email service. - Enable DKIM signing: Once the DNS records are published and have propagated, you'll need to enable DKIM signing within your email service's administration panel. This tells your mail server to start digitally signing outgoing messages.
- Key Lengths: As seen with Artist Residence Brighton, upgrading from 1024-bit to 2048-bit keys offers better security. It's a simple change that enhances cryptographic strength.
3. Implementing DMARC (Domain-based Message Authentication, Reporting & Conformance)
DMARC is the policy layer that ties SPF and DKIM together.
- Construct your DMARC record: This is another TXT record for your domain, typically with the hostname
_dmarc. A basic record might look like this:v=DMARC1; p=none; rua=mailto:[email protected]v=DMARC1: Specifies the DMARC version.p=none: This is the monitoring policy. It tells receiving servers to do nothing with emails that fail DMARC checks, but to send reports. This is the crucial first step for gathering data without impacting legitimate email.p=quarantine: Instructs receiving servers to move emails that fail DMARC to the recipient's spam or junk folder.p=reject: The strongest policy. Emails failing DMARC are rejected outright. This should only be implemented once you are confident all legitimate sending sources are correctly authenticated.rua=mailto:[email protected]: Specifies an email address to receive aggregate DMARC reports. These reports are invaluable for understanding your email ecosystem.ruf=mailto:[email protected]: (Optional) Specifies an email address for forensic reports, which contain more detail about individual failed messages. Note: not all email providers send these.
- Add the DMARC record to your DNS: Create a TXT record for
_dmarc.yourdomain.co.uk. - Monitor and adjust: This is the most critical step. Start with
p=noneand regularly review the DMARC reports. These reports will show you which sources are sending email on your behalf and whether they are passing SPF and DKIM. Identify any legitimate sources that are failing and adjust your SPF and DKIM records accordingly. Only when you are certain all legitimate email is passing authentication should you consider moving top=quarantineand eventuallyp=reject.
Experience Signal: On a recent client tenant audit for a Surrey-based logistics firm with 25 staff, we found they had no DMARC record whatsoever. Implementing a p=none policy with reporting allowed us to identify several third-party marketing services sending emails on their behalf that were not properly configured with SPF or DKIM. Without the DMARC reports, they would have remained oblivious to these unauthenticated sources, leaving them vulnerable to impersonation. After a few weeks of monitoring, we were able to move them to a p=quarantine policy with confidence.
Common mistakes we see
Based on our work with UK SMEs and assessments like the Brighton hotel audit, several recurring issues hinder effective email security:
- Missing DMARC records entirely: Many organisations, including several Brighton hotels we assessed (e.g., Square Townhouse, A Room With A View, Hotel Una, Drakes Hotel), simply have no DMARC record. This is a fundamental oversight, leaving them completely exposed to spoofing attacks.
- DMARC policy set to 'none' indefinitely: While starting with
p=noneis correct, leaving it there permanently (as seen with Hotel du Vin, Leonardo Royal Hotel, and The Grand) offers no actual protection against malicious emails. It only provides reporting. - Incomplete or incorrect SPF records: Issues like SPF records using
-allwhen they should be~all(or vice-versa), or missing entries for legitimate sending services, can cause deliverability problems or leave gaps in protection. - Unconfigured or incomplete DKIM: Several Brighton hotels had incomplete DKIM setups. If DKIM isn't fully configured or enabled, your emails lack a crucial layer of authenticity, making them more susceptible to being marked as spam.
- "Set and forget" mentality: Email infrastructure evolves. New services are adopted, old ones retired. Without regular review and monitoring of DMARC reports, your authentication records can quickly become outdated or insufficient.
- Weak cryptographic key lengths for DKIM: As highlighted with Artist Residence Brighton, using 1024-bit DKIM keys when 2048-bit keys are available is a missed opportunity for stronger security.
Key Takeaways
- Email authentication is critical: SPF, DKIM, and DMARC are non-negotiable for modern email security and deliverability.
- Protection and deliverability: Proper setup defends against phishing and impersonation while ensuring your legitimate emails reach their recipients.
- Start with DMARC monitoring: Begin with a
p=noneDMARC policy to gather data before enforcing stricter rules. - Regular review is essential: Your email environment changes; your authentication records should too.
- Compliance benefits: Strong email security supports UK GDPR principles and is fundamental for Cyber Essentials.
When to call in help
Implementing and maintaining these email authentication protocols can be complex, particularly for SMEs juggling multiple IT demands. The detailed configuration of DNS records, interpretation of DMARC reports, and ongoing adjustments require specific expertise. If you're unsure about your current setup, are experiencing deliverability issues, or simply lack the internal resources to manage this effectively, it's prudent to seek external assistance. Getting this wrong can be more disruptive than doing nothing, which is saying something.
To take the next step

