Five Tips for Email Security Every Business Should Implement

Email remains the primary vector for phishing, spoofing, and business email compromise. Yet the technical controls that stop most of these attacks are well-known, standardised, and free to implement. The challenge is not knowledge - it is execution. Many organisations have partial setups: an SPF record with no DMARC policy, or a DMARC policy stuck at none for years. This post walks through five concrete steps that, taken together, build a genuinely robust email security posture.

1. Publish and Maintain an SPF Record

Sender Policy Framework (SPF) is the foundation. It lets you publish, in DNS, a list of all IP addresses and mail servers authorised to send email on behalf of your domain. When a receiving mail server checks an incoming message, it looks up this list and verifies that the sending server is on it.

Publishing an SPF record is straightforward: add a TXT record to your domain's DNS. A minimal example looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Maintenance is the harder part. Every time you add a new email service provider - a CRM, a marketing platform, a transactional mailer - you need to update your SPF record to include it. Forgotten senders are one of the most common causes of email deliverability problems. A few things to watch for:

• The 10-lookup limit. SPF allows at most 10 DNS lookups during evaluation. Exceed this and the result is a permerror, which counts as a failure. Flatten your record or use a managed SPF service if you have many senders.
• Only one SPF record per domain. If two TXT records starting with v=spf1 exist, receiving servers return a permerror. Merge them into one.
• End with -all once ready. The softfail (~all) is fine during initial rollout, but move to a hard fail when you are confident all legitimate senders are covered.

Use the SPF Checker to inspect your current record, identify missing senders, and verify your lookup count.

2. Implement DKIM Signing

DomainKeys Identified Mail (DKIM) takes a different approach from SPF. Instead of listing authorised IP addresses, DKIM attaches a cryptographic signature to every outgoing message. The receiving server looks up the public key in your DNS and uses it to verify the signature. If the signature is valid, the message has not been tampered with in transit and genuinely originates from a server holding the corresponding private key.

DKIM has one major advantage over SPF: it survives email forwarding. When a message is forwarded, the sending IP changes, which breaks SPF. The DKIM signature, however, travels with the message headers and remains verifiable at the final destination. This makes DKIM the more resilient of the two mechanisms for satisfying DMARC.

Key rotation is an important operational practice that many organisations neglect. Your DKIM private key should be rotated at least annually - more frequently if you handle sensitive data or operate in a regulated industry. The rotation process involves:

1. Generating a new key pair.
2. Publishing the new public key in DNS under a new selector.
3. Configuring your mail server or ESP to sign with the new key.
4. Waiting for DNS propagation and confirming the new key validates correctly.
5. Removing the old key from DNS after a suitable overlap period.

Check your current DKIM configuration with the DKIM Checker. You can verify that the correct public key is published and that signatures from your mail server validate against it.

3. Deploy a DMARC Policy

DMARC - Domain-based Message Authentication, Reporting and Conformance - is the control layer that sits on top of SPF and DKIM. It tells receiving mail servers what to do when a message fails both SPF and DKIM alignment, and it instructs them to send you reports about what they see.

A DMARC record is published as a TXT record at _dmarc.yourdomain.com. The key tag is p=, which sets the policy:

The recommended path is none → quarantine → reject. Start at none to gather reports without affecting delivery. Once you have reviewed the data and confirmed that all legitimate sending sources pass SPF or DKIM alignment, move to quarantine. When you are satisfied with that, advance to reject. Skipping steps or rushing this progression is the most common cause of accidentally blocking legitimate email.

A minimal starting record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Verify your current DMARC setup with the DMARC Checker. It will show your current policy, alignment settings, and any configuration issues.

4. Monitor Your DMARC Reports

Publishing a DMARC record with a rua tag starts the flow of aggregate reports. Every major mail provider - Google, Microsoft, Yahoo, Apple - sends these reports to the address you specify, typically once per day. Each report is an XML file containing authentication results for every IP address that sent email using your domain during that period.

The problem is that raw DMARC XML is not designed for human consumption. A single busy domain can receive dozens of reports per day, each containing hundreds of records. Reading them manually to understand which senders are failing and why is impractical.

This is where a dedicated monitoring tool becomes essential. DMARCFlow ingests your aggregate reports automatically - you simply add a reporting address provided by DMARCFlow to your DMARC record - and presents the data in a readable dashboard. Specifically, DMARCFlow helps you:

• Identify unauthorised senders. If someone is spoofing your domain, their sending IPs will appear in reports alongside your legitimate sources. DMARCFlow flags unknown senders and shows you how much volume they represent.
• Track alignment pass rates. You can see exactly what percentage of your email passes SPF alignment, DKIM alignment, or both - broken down by sending source.
• Get actionable recommendations. Instead of staring at XML, DMARCFlow tells you in plain language which senders need configuration changes and what those changes are.
• Monitor policy progression. DMARCFlow assigns a DMARC maturity level from 0 to 5 and a security score out of 100, so you have a clear picture of where you stand and what to do next.

Without monitoring, a DMARC record at none provides no protection and no insight. Reports are the mechanism that makes the entire system actionable. Do not skip this step.

5. Add BIMI to Build Brand Trust

Brand Indicators for Message Identification (BIMI) is the newest of the five standards covered here. Once your domain has a DMARC policy at quarantine or reject, you can publish a BIMI record that instructs supporting mail clients to display your brand logo next to your messages in the inbox.

BIMI works by pointing to an SVG version of your logo stored at a public URL. Mail clients that support BIMI - including Gmail, Apple Mail, and Yahoo Mail - fetch the logo and display it alongside the sender name. The visual effect is significant: recipients see your verified logo rather than a generic avatar, which increases recognition, trust, and open rates.

To qualify for BIMI with a Verified Mark Certificate (VMC), your logo must be a registered trademark in the relevant jurisdiction. For the basic level of BIMI (supported by some providers without a VMC), the requirements are simpler: a properly formatted SVG Tiny P/S logo file and a valid DMARC policy at enforcement level.

A BIMI record is published as a TXT record at default._bimi.yourdomain.com and looks like this:

v=BIMI1; l=https://yourdomain.com/logo.svg; a=https://yourdomain.com/vmc.pem

The l= tag points to your SVG logo and a= to your VMC certificate (optional but required for Gmail). Check your BIMI setup and eligibility with the BIMI Checker.