TDMARC Email Authentication & Anti-Spoofing Consultant

What is TDMARC?

TDMARC is an email authentication and anti-spoofing platform, and the first thing worth stating clearly is that it is a product of Threatcop. The brand name does not reveal that on its own, and it is a common enough assumption in a shortlist that TDMARC and Threatcop are two separate vendors. They are not. Knowing that changes the evaluation, because Threatcop's wider people-security range also includes security awareness training, phishing incident response and a learning management system, so TDMARC is often presented inside a bundle rather than as a single purchase. That is one honest sentence and no more, because this page is about TDMARC.

What TDMARC itself does is scoped and verifiable. You connect multiple sending domains and monitor all of them from one dashboard. You see passing and failing percentages for DMARC, SPF and DKIM. You can inspect the domain records that matter, covering DMARC, SPF, DKIM and MX. And you manage policy in order to prevent domain misuse and business email compromise, meaning the impersonation, false invoice and CEO fraud patterns that depend on a recipient trusting a sender name. I would rather describe that accurately than pad it with capabilities I have not confirmed, so the rest of this page is mostly about the problem domain, because that is where these projects are actually won or lost.

Start with what the three records really do, because they are constantly conflated. SPF is an authorisation list published as a DNS TXT record, naming the IP addresses and hosts allowed to send mail for your domain, and a receiving server compares the connecting IP against it. Crucially SPF checks the envelope sender, the address used during the SMTP conversation, which is not the address a human sees. DKIM is a cryptographic signature: the sending system signs selected headers and the body with a private key, publishes the matching public key in DNS under a selector, and the receiver verifies it. That proves the message came from a system holding your key and that the signed content was not modified. Neither record, on its own, says anything about the From address the recipient reads.

DMARC closes that gap through alignment: the domain that passed SPF or DKIM must match the domain in the visible From header. It then publishes a policy telling receiving servers what to do when nothing aligns, and requests reports back so you can see who is sending as you. The policy values are the whole journey. p=none monitors and blocks nothing. p=quarantine asks receivers to treat unaligned mail as suspicious, usually junk-foldering it. p=reject asks them to refuse it outright. Only quarantine and reject are enforcement, and a domain sitting at p=none has visibility with no protection. A great many organisations that believe they have implemented DMARC are in exactly that state, which is why a dashboard showing pass and fail percentages is more useful than it first sounds: it tells you whether the record is doing anything.

Two tags exist to make the move off p=none survivable, and both are underused. The pct tag applies your policy to a stated percentage of failing mail, so you can enforce on a slice of traffic, see what breaks and raise the number in stages instead of switching the entire estate in one change. The sp tag sets subdomain policy independently of the parent, which matters because subdomains inherit the parent policy by default. That default catches people out in both directions: an aggressive parent policy can quietly break a subdomain a business unit depends on, and a permissive sp value can leave attackers a subdomain to spoof while the parent domain looks protected on paper.

Two technical realities cause more failed projects than anything else. The first is the SPF ten DNS lookup limit. Every include, redirect, a, mx, ptr and exists mechanism costs a DNS lookup, and those nest, so a single cloud provider include can quietly consume several. Exceed ten and the record returns a permanent error, at which point SPF fails for your legitimate mail, not just for attackers. Estates with many third-party senders hit this fast, because every new SaaS platform that sends on your behalf wants another include. The fix is consolidation, moving senders onto their own subdomains, or leaning on DKIM for sources that cannot be accommodated. The second is the reports. DMARC aggregate reports, the RUA feed, arrive as compressed XML from every receiving provider, several times a day, describing message counts by source IP and authentication result. That is machine output, and reading it by hand across even a modest estate is not realistic. Filling that gap is precisely what a platform such as TDMARC is for. Without tooling, most organisations publish a RUA address, collect XML in a mailbox nobody opens, and stop.

Why TDMARC for UAE Organisations?

The regional case for email authentication is unusually concrete. Business email compromise and invoice fraud are among the most damaging attack types against UAE and GCC organisations, and they are damaging precisely because they involve no malware and no exploit. A supplier payment is redirected, a beneficiary account is changed, an urgent transfer is requested by someone who appears to be an executive, and the money leaves through a legitimate banking channel with every control technically working as designed. DMARC at enforcement removes the most convincing version of that attack, because it stops mail that appears to come from your own domain. Impersonation of banks and government entities is a live problem in this market, and every one of those campaigns depends on the recipient trusting the sender they can see.

The compliance picture supports the same conclusion without needing to be overstated. The NESA information assurance standards expect controls over electronic messaging and the protection of information in transit. CBUAE requirements push regulated financial institutions towards controls that reduce customer-facing fraud, and a bank whose domain can be spoofed is handing attackers a working phishing template. DESC in Dubai sets comparable expectations for entities in its scope, and the data protection regimes in ADGM and DIFC, together with the federal PDPL, rest on an obligation to apply appropriate technical measures. None of these frameworks names DMARC as a line item, and I will not pretend otherwise, because a control mapping that does not exist falls apart the moment an assessor reads the source document. The argument that does hold is the exposure one: domain spoofing is a direct route to both fraud loss and personal data compromise, and once you show an assessor a report of unauthorised mail sent in the organisation's name, the relevance is obvious without any framework citation.

Then there is the commercial forcing function. The Google and Yahoo bulk sender requirements apply to senders exceeding roughly five thousand messages a day to their users, and they require SPF and DKIM authentication, a published DMARC record, alignment between the visible From domain and the authenticated domain, one-click unsubscribe on marketing mail, and a spam complaint rate kept below threshold. Be precise about what that means: the published minimum policy is p=none, so the rules make DMARC mandatory in the sense of having it, not enforcing it. Enforcement remains your security decision. But for UAE retail, banking, telecom, hospitality and government-facing services, where a large share of the customer base sits on consumer mailboxes, an unauthenticated domain is now a deliverability problem as well as a security one. For the wider picture of how authentication fits alongside gateway controls and awareness training, see my email security services.