Email security FAQ for UK businesses

If your domain sends email, you should normally publish SPF. SPF tells receiving mail systems which servers are authorised to send mail for the envelope-sender domain. SPF on its own is not enough to stop spoofing of the visible From address, so it should be used with DKIM and DMARC.

SPF is a DNS TXT record that lists authorised sending sources for a domain. A receiving mail server can compare the connecting sender with that policy. SPF validates the SMTP MAIL FROM or envelope sender, not necessarily the From address the user sees.

No. A domain should have one SPF policy. If you have several email services, their authorised sources need to be combined into one valid SPF record. Publishing multiple competing SPF records can cause SPF to return a permanent error.

Common causes include a legitimate sender missing from the record, forwarding, too many DNS lookups, incorrect includes, sending from an unexpected envelope domain, or duplicate SPF records. SPF has a limit on DNS-querying mechanisms, so overly complex records can fail.

Yes, in most modern business email setups you should enable DKIM for every domain that sends mail. DKIM adds a cryptographic signature to outgoing messages so receiving systems can verify that signed parts of the message were not altered and that the signing domain authorised the signature.

Yes, if your business uses its own domain for email, DMARC should normally be part of your email security baseline. DMARC checks whether SPF or DKIM passes in alignment with the visible From domain and tells receiving systems what policy you want applied to unauthenticated mail.

DMARC alignment means the domain authenticated by SPF or DKIM matches, or is appropriately related to, the domain shown in the visible From address. This matters because a message can technically pass SPF or DKIM for an attacker's own domain while still pretending to be another brand in the visible From field.

p=none asks receiving systems to monitor DMARC results without requesting quarantine or rejection. It is commonly used while discovering legitimate senders. It is not an enforcement policy, so it should normally be a stage on the way to a stronger policy once legitimate mail is understood.

Once you have identified and correctly authenticated legitimate senders, a stronger DMARC policy can materially reduce direct spoofing of your domain. p=quarantine asks receivers to treat failing messages suspiciously; p=reject asks them to reject them. Roll out enforcement carefully and monitor reports.

The rua tag specifies where aggregate DMARC reports should be sent. These reports help you see which systems are sending mail claiming to use your domain and whether SPF, DKIM and alignment are passing.

They are strongly recommended. DMARC reports help discover forgotten marketing platforms, scanners, websites, CRM systems and other legitimate senders before you enforce a stricter DMARC policy. They can also reveal unauthorised attempts to use your domain.

If a domain genuinely never sends email, publish an explicit no-mail posture rather than leaving it ambiguous. Common practice is an SPF record that authorises no senders and a DMARC policy requesting rejection. Check the domain's actual use first, including web forms, scanners and third-party services, before enforcing it.

BIMI is optional. It can allow participating mailbox providers to display your brand logo beside authenticated mail, but it is not a replacement for email authentication. Treat BIMI as a brand and trust enhancement after SPF, DKIM and DMARC are correctly implemented.

At minimum you need DMARC alignment and a sufficiently enforced DMARC policy. You then publish a BIMI DNS record that points to a compliant SVG logo. Some mailbox providers also require a Verified Mark Certificate or Common Mark Certificate before they will display the logo.

No. Supporting mailbox providers decide whether and when to display a BIMI logo, and they can apply their own reputation and certificate requirements. A technically valid BIMI record does not guarantee display.

Check both the sending IP address and the domain with reputable reputation services such as the Spamhaus IP & Domain Reputation Checker. Also review rejection messages from recipient mail systems because they often state which reputation system or policy caused the block.

An IP blocklist records IP addresses associated with spam, malware, compromised systems or policy problems. A domain blocklist records domains with poor or abusive reputation. Email delivery can be affected by either, depending on how the receiving provider evaluates a message.

First fix the underlying cause. Check for compromised accounts, malicious website forms, infected devices, poor mailing-list hygiene, unauthorised SMTP sending, DNS errors and incorrect mail-server configuration. Only request delisting after the cause has been removed, otherwise the listing can quickly return.

Start with the real sender address, not just the display name. Check the From domain, Reply-To address, links, message context and authentication results. In the full message headers, look for SPF, DKIM and DMARC results and whether the authenticated domains align with the visible From domain.

No. Passing authentication means the message was authorised by the domains involved; it does not prove the sender is trustworthy. A criminal can register a convincing lookalike domain and configure SPF, DKIM and DMARC correctly. You still need to assess the domain, message, links, request and business context.

Display-name spoofing is when an attacker puts a trusted person's or company's name in the friendly display-name field while sending from a different address. Users often notice the name first, so always inspect the full sender address when a request is unusual.

A lookalike domain is deliberately registered to resemble a trusted domain, for example by adding a word, changing a letter, using a different top-level domain or using visually similar characters. These domains can pass their own email authentication, so spelling and domain context still matter.

A suspicious message may show one From address but direct replies to another domain or mailbox. A mismatch is not automatically malicious because legitimate platforms sometimes use different reply handling, but it is a useful warning sign when combined with an unusual request.

Most email clients provide an option such as 'View source', 'View message details' or 'Show original'. Look for the Authentication-Results header, From, Return-Path, Reply-To and Received headers. Headers can be complex, so treat them as evidence rather than relying on one line in isolation.

Domain registration data can help, but for generic top-level domains RDAP is now the modern authoritative access method and has replaced legacy WHOIS as the definitive ICANN service. Look for the domain's registration or creation event, registrar and status information.

No. Legitimate businesses launch new domains every day. But a domain registered very recently can increase suspicion when it is impersonating an established supplier, requesting an urgent payment or using a name very similar to a known business.

Compare its exact spelling with the genuine organisation's domain, registration age, registrar information where available, DNS records, website history and whether the organisation publicly uses that domain. Also check whether links in the email actually lead to the same domain shown in the message.

Both platforms include strong security capabilities, but security depends on configuration, licensing, monitoring and business risk. Email authentication, MFA, anti-phishing controls, safe-link and attachment protections, user reporting, account monitoring and finance verification procedures all contribute.

Do not reply, click links, open unexpected attachments or call numbers supplied in the message. Report it through the business's approved security route. If the message requests payment, password changes or bank-detail changes, verify the request using a trusted contact method obtained independently.

Use SPF, DKIM and DMARC for your domains; strong MFA for users and administrators; anti-phishing and malware protection; restricted privileged access; secure account recovery; monitored sign-in and mailbox activity; staff training; and an independent verification process for payments and bank-detail changes.