Article 1.2 of this series asked Caribbean boards whether they were running their business on personal email. This article is the technical follow-up that boards have largely been spared until now: three small entries in the firm’s domain settings — SPF, DKIM, and DMARC — that quietly decide whether the firm’s mailboxes can be impersonated. The board does not need to understand the syntax. It does need to understand what these records do, what failure looks like, and what to ask the IT supplier the next time the firm’s email is reviewed.

The forensic finding the board never saw

Article 1.2 of this series opened with the story of a Jamaican retail group whose bookkeeper paid JMD 4.7 million against an email she believed had come from her managing director of eleven years. The supplier did not exist. The funds cleared three correspondent banks. The investigation concluded that the company had no realistic basis for either prevention or recovery, because the mailbox impersonated was on a service the firm did not own.

That account, told at board level, was complete enough to make the governance point Article 1.2 needed to make. What it did not include was the forensic finding that arrived two weeks later from the firm’s IT consultant. The finding ran to a single technical sentence: the firm’s email domain published no SPF record, no DKIM signature, and no DMARC policy. In plain language, the firm had never told the rest of the internet which servers were authorised to send mail on its behalf, never digitally signed any of its outgoing messages, and never instructed receiving mail systems what to do if they encountered an unauthenticated message claiming to be from the firm.

The attacker had not needed to compromise the firm’s email at all. The firm’s email could be impersonated trivially from any mailbox anywhere in the world, and there was nothing in the firm’s domain that allowed a receiving mail system to tell the difference between a real message from the managing director and a fake one. The bookkeeper paid the invoice because the email looked genuine, and at the level of email authentication, the fake was indistinguishable from the genuine. The firm’s recourse was zero because the firm’s domain had never been configured to make impersonation harder.

Three small records in the firm’s domain settings would have made the impersonation either visible or impossible. None of them existed. The cost to the firm of publishing them, in hindsight, would have been roughly two hours of an IT consultant’s time and no recurring expense. The cost of not publishing them was JMD 4.7 million.

This is the article most Caribbean boards have been spared until now, on the polite assumption that this material was too technical to bring to the board agenda. It is technical. It is also, in the post-DPA-2020 Caribbean, no longer optional, no longer the IT consultant’s exclusive province, and not nearly as complicated as the literature has made it appear.

Three small entries in the firm’s domain settings decide whether the firm’s mailboxes can be impersonated. The board does not need to understand the syntax. It does need to understand what these records do.

1. What the three records do, in plain language

There are three records, in this order. The first two are technical mechanisms. The third is a policy instruction that tells receiving mail systems how strictly to enforce the first two. The three together form the firm’s public statement to the rest of the internet about who is allowed to send mail on its behalf, and what should happen if anyone else tries.

SPF — the list of authorised senders

SPF, the Sender Policy Framework, is a single short entry the firm publishes in its domain. It says, in effect: “the only servers authorised to send mail from this domain are these specific ones — anything else is forged.” When a receiving mail system gets a message claiming to be from the firm, it can read this list and check whether the server that actually sent the message is on it. If the server is on the list, the message is more likely to be genuine. If the server is not on the list, the receiving system has grounds to be suspicious.

SPF is the easiest of the three records to publish and the easiest to maintain. It is also, on its own, weaker than the literature sometimes suggests — there are technical limitations to how strictly receiving systems can enforce it, and SPF alone has not stopped a determined attacker since at least the mid-2010s. SPF is necessary; it is not sufficient.

DKIM — the cryptographic signature on each message

DKIM, DomainKeys Identified Mail, attaches an invisible cryptographic signature to every email the firm sends. The signature is generated by the firm’s mail server using a private key only the firm has access to, and verified by the receiving mail system using a public key the firm publishes in its domain. If the signature checks out, the message was genuinely sent by a server that holds the firm’s private key. If the signature is missing, broken, or wrong, the message is either forged, tampered with, or both.

DKIM is harder than SPF to misconfigure quietly. It either works or it does not, and the firm will find out within hours of going live if it is broken because outgoing mail starts failing visibly. The trade-off is that DKIM requires the firm’s mail platform — Microsoft 365, Google Workspace, or equivalent — to be set up correctly at provisioning time, which is the moment most often skipped in a default deployment.

DMARC — the policy instruction

DMARC, Domain-based Message Authentication, Reporting and Conformance, is the third record and the one that ties the other two together. It is not a technical mechanism in its own right; it is a published instruction to receiving mail systems that says: “if a message claims to be from us and it fails the SPF and DKIM checks above, here is what we want you to do with it.”

There are three options the firm can specify. The instruction can be set to “none,” meaning “do nothing — let the message through and just tell us about it.” It can be set to “quarantine,” meaning “send it to the spam folder.” Or it can be set to “reject,” meaning “refuse the message outright and bounce it back to the sender.” The default that ships with most platforms is “none.” Most Caribbean firms that have any DMARC record at all are running on this default. “None” is, for practical purposes, the same as having no DMARC at all — the receiving mail system is being told that the firm does not care about impersonation. The defensible enforcement level is “quarantine” at minimum, ideally “reject.”

The chain reads, end-to-end: SPF tells the world who is allowed to send mail from the firm’s domain; DKIM proves that any given message actually came from one of those authorised senders; DMARC tells the world what to do when those proofs fail. All three are needed. Two of three is a partial defence. One of three is theatre. None of three is the JMD 4.7 million story above.

 

2. The four failure modes a director should be able to recognise

Following the diagnostic structure used in the first three articles in this series, the failure modes we encounter when reviewing email authentication at Caribbean firms fall into four patterns. Every Caribbean board should be able to confirm that none of these describes the firm it governs.

Failure A — No records at all

The firm has published no SPF, no DKIM, and no DMARC. The domain is silent on the question of email authentication. Any mailbox anywhere on the internet can claim to be from the firm and receiving mail systems have nothing to check against. This is the configuration of the Jamaican retail group at the start of this article. It is also the configuration of a surprisingly large number of Caribbean firms whose IT consultants set up the domain and the website but never returned to complete the email-authentication pass.

The forensic signature of Failure A is that the firm has been operational for years without any complaint about deliverability, and without any visible problem. Email authentication is asymmetric — when it is missing, nothing visibly breaks, until the day a determined impersonation arrives.

Failure B — SPF only, DKIM and DMARC missing

The firm published an SPF record at some point in the past, probably during the original mailbox provisioning. The SPF record is correct or close to correct. But DKIM was never enabled on the firm’s mail platform, and DMARC was never published at all. This is a partial defence — SPF alone reduces some categories of impersonation — but it is not the modern standard, and large mail providers (Microsoft, Google, Yahoo) now actively downgrade or reject mail from domains that publish only SPF without DKIM or DMARC.

The forensic signature of Failure B is that the firm’s mail is increasingly landing in counterparties’ spam folders, and the firm has noticed but cannot work out why. The cause is almost always that the firm’s authentication posture has fallen below the threshold that the receiving systems now require.

Failure C — All three records, but DMARC at “none”

All three records are published. SPF is correct. DKIM is signing outgoing mail correctly. DMARC is at the default “none” policy, which instructs receiving systems to take no action when authentication fails. The firm’s IT consultant or platform vendor delivered the records as a checklist item and never returned to switch DMARC enforcement to “quarantine” or “reject.”

This is the most common failure mode we encounter across Caribbean firms that have undertaken any email-authentication work at all. The firm has the appearance of being authenticated; on closer inspection it has authenticated nothing, because the instruction it has given to receiving mail systems is to ignore authentication failures. The forensic signature is that the firm believes itself to be compliant and protected, and an external review reveals that it is neither.

Failure D — Records correctly configured, but no monitoring

All three records are published. SPF is correct. DKIM is signing. DMARC is enforcing at “quarantine” or “reject.” But the firm has not configured the reporting endpoint that DMARC offers — the daily summary that tells the firm what is happening with its outgoing mail, which servers are sending on its behalf, and whether legitimate mail is being blocked alongside the forgeries. The firm is enforcing blind.

This is the most sophisticated failure mode, and it sometimes turns out to be more costly than the simpler ones. Without monitoring, the firm cannot tell whether its DMARC enforcement is blocking legitimate mail — for example, mail sent through a third-party marketing platform or a fundraising tool that was never added to the SPF list. The firm finds out about the misconfiguration when an important counterparty mentions, weeks later, that they never received a particular email. By that point the audit trail is gone.

 

3. The four questions to ask the IT supplier

The board’s job is not to write the records. The board’s job is to confirm that someone competent has written them, that they are at the right enforcement level, that they are being monitored, and that there is a process for keeping them current. The four questions below are designed to be asked of the firm’s IT supplier — internal or external — in a single sitting. The supplier’s answers, given without notes or preparation time, tell the board everything it needs to know.

 

#	Question for the IT Supplier	A Confident, Specific Answer Looks Like
1	Can you show me the current SPF, DKIM and DMARC records for our domain, retrieved live from the public domain settings rather than from your internal documentation?	The supplier runs a live check in front of the board, reads the actual records, and confirms all three exist. Hesitation here is itself the answer.
2	What is our DMARC policy set to — none, quarantine, or reject — and when did we last change it?	“Quarantine” or “reject,” with a date that is recent enough to be remembered. “None” with no plan to move is Failure C from §2.
3	Where do the daily DMARC monitoring reports go, who reads them, and when was the last anomaly identified?	A named mailbox is receiving them, a named individual is reading them, and at least one anomaly can be described from recent memory. If not, this is Failure D.
4	If we added a new third-party tool that sends mail on our behalf — a CRM, a payroll system, a fundraising platform — what is the process for updating our records, and who owns it?	A written process, a named owner, and a service-level commitment (e.g., “within five business days of platform notification”). If the answer is “we’ll handle it when it comes up,” the firm is one platform addition away from a deliverability incident.

 

A good supplier will welcome these questions and answer all four in five minutes. A supplier who deflects, asks to come back next week, or starts a long explanation about why these questions are too technical for the board to assess is, in our experience, the more important finding than the answers themselves.

 

4. The Six-Question Email Authentication Audit

As with the first four articles in this series, the questions below are designed to be put on the next board agenda. They take under thirty minutes to ask honestly. Three are addressed to the directors themselves; three are addressed to the firm’s IT supplier, with the directors witnessing the answers.

 

#	Question for the Board	What “Pass” Looks Like
1	Has any director on this board seen, in the last twelve months, written confirmation that SPF, DKIM and DMARC are all published on the firm’s email domain?	Yes — dated written confirmation in the board pack or the firm’s IT documentation.
2	Is the firm’s DMARC enforcement set to “quarantine” or “reject” — not “none”?	Yes — confirmed by live query, not by supplier assertion.
3	Is a named individual at the firm or its supplier receiving and reading DMARC monitoring reports on a regular cadence?	Yes — name known to the board, cadence at least weekly.
4	Is there a documented process for updating the records when the firm adds a new third-party platform that sends mail on its behalf?	Yes — written, named owner, agreed service-level.
5	If the firm operates more than one email domain — for a subsidiary, a brand, or a defensive registration — is each domain configured independently?	Yes — every domain the firm owns has its own records, even defensive registrations that never send mail.
6	Has the firm rehearsed what would happen if a Business Email Compromise attempt reached the finance team this week — and would the authentication records described above make a difference?	Yes — tabletop exercise within twelve months; out-of-band verification procedure from Article 1.2 §5 is in force.

 

Together with the audits from Articles 1.1, 1.2 and 1.3, this gives every Caribbean board a twenty-four-question digital-foundations readiness check. The combined result tells the firm whether it controls its digital identity, whether it runs on appropriate infrastructure, whether its public identity sends the right signal, and — completed here — whether the identity it broadcasts can be trivially impersonated by anyone with a free email account.

 

5. What the Data Protection Act 2020 implies

Article 1.2 of this series introduced the Jamaican Data Protection Act 2020 in the context of professional email as a governance question. The Act has a specific implication for email authentication that is worth surfacing here, because most Caribbean firms have not yet absorbed it.

The Act requires data controllers — every Jamaican firm processing personal data — to demonstrate “appropriate technical and organisational measures” to protect that data. Email authentication is now, in the consensus view of regulators and counsel internationally, one of those appropriate measures. A Caribbean firm that has not published SPF, DKIM and DMARC records on its mail domain is in a difficult position if asked to demonstrate appropriate technical measures in a regulator’s enquiry, an audit, or — most consequentially — in litigation following a Business Email Compromise incident.

The position is not yet settled in Jamaican case law, and the Office of the Information Commissioner has not yet issued specific guidance on email authentication. Comparable EU and UK enforcement actions, on which Caribbean regulators are likely to draw, have repeatedly cited the absence of basic email authentication as a contributing failure in adverse findings. The trajectory of regulatory expectation is clear, and the trajectory of regulatory tolerance for firms operating without these basic measures is in the opposite direction.

The expensive failure mode is therefore not the impersonation itself. It is the impersonation followed by the regulator’s enquiry, followed by the discovery that the three small records that would have made the impersonation harder were never published. The firm’s defence in that conversation — that the records are technical, that the IT consultant never mentioned them, that the board could not be expected to understand the syntax — is materially weaker after this article has been published than it was before.

 

6. Technical reference — for the supplier, not the board

The table below is included for completeness and is addressed to the firm’s IT supplier rather than to the directors. It is the minimum technical checklist that should be reviewable in a single page of the IT supplier’s documentation. Directors do not need to read or understand it; the supplier should be able to walk through it on request.

 

Record	What the supplier checks	Where the record lives
SPF	That the SPF record exists, is syntactically valid, lists all servers and platforms that legitimately send mail for the firm, and is not over the ten-DNS-lookup limit.	A single TXT record at the apex of the domain. Typically reviewed via a public SPF-checking tool.
DKIM	That a DKIM selector exists for each platform sending on the firm’s behalf, that the public key is published correctly, and that outgoing test messages are being signed and verified.	Multiple TXT records at platform-specific subdomains (e.g., selector1._domainkey.firm.tld). Reviewed via DKIM-checking tools or by sending a test message.
DMARC	That the DMARC record exists, that the policy (p=) is set to quarantine or reject (not none), that a reporting endpoint (rua=) is configured, and that reports are arriving.	A single TXT record at _dmarc.firm.tld. Reviewed via DMARC-checking tools and by confirming receipt of daily aggregate reports.

 

Every meaningful element of email authentication is captured in those three rows. The remaining detail — selector rotation, BIMI, ARC, the specifics of mail platform configuration — is the supplier’s territory, and is genuinely too technical to belong in a board article. What belongs in a board article is the recognition that those three rows exist, that they have been completed, that they are being monitored, and that a competent supplier can demonstrate all of this in five minutes.

 

7. Where to go from here

If after reading this article the board cannot, with confidence, return six “pass” answers to the questions in §4, the firm is operating its email under one of the four failure modes in §2 — and the firm’s exposure to Business Email Compromise, to deliverability degradation, and to a regulator’s enquiry under the Data Protection Act 2020 is materially higher than it should be.

The technical work to move a Caribbean firm from any of the four failure modes to full compliance is, in our experience, a single focused two-day exercise, with no recurring cost beyond the supplier’s monitoring time. The board’s work is materially simpler: ask the four questions in §3, witness the answers, and confirm the firm has not been quietly exposed for years through a configuration nobody ever returned to complete.

 

WHERE TO GO FROM HERE Publish the three records. Move DMARC off “none.” Through Dawgen Global Technologies, the firm offers five Caribbean-tailored web-services bundles built on the SecureServer platform. The Professional Firm, Business Pro, E-Commerce and Enterprise/Regulated bundles all include full SPF, DKIM and DMARC configuration at provisioning time, DMARC enforcement set to quarantine or reject from the first day of service, and a named monitoring contact reading the daily aggregate reports. The three records are not an add-on — they are the standard configuration of every email mailbox the firm provides. dawgentechnologies.com Or write to [email protected] to arrange an Email Authentication Audit through your Dawgen Global engagement team.

Author

Dr. Dawkins Brown is the Executive Chairman and Founder of Dawgen Global, an independent integrated multidisciplinary professional services firm headquartered in New Kingston, Jamaica, operating across 15+ Caribbean territories. Dawgen Global Technologies is the firm’s web-services line, delivering domains, hosting, professional email, Microsoft 365, SSL, websites, security and backups across the region.

About The Caribbean Digital Foundations Series

The Caribbean Digital Foundations Series is a 30-article thought leadership programme published by Dawgen Global on its blog (dawgen.global/blog) through 2026. The series is organised into five pillars — Foundations, Trust & Security, Presence & Performance, Productivity & Collaboration, and Commerce & Growth — and is designed to bring the same governance lens Dawgen Global applies to audit, tax and advisory engagements to the web-services decisions every Caribbean SMB must now make.

This is Article 1.5 of the series, completing the technical detail referenced by Step 5 of Article 1.4’s eight-step checklist. Article 1.6, “From Personal Inbox to Professional Brand: A Migration Playbook for Caribbean Family Businesses,” concludes the Foundations pillar.

About Dawgen Global