EmailAuth DMARC & BIMI Consultant

What is EmailAuth?

EmailAuth is an email authentication platform focused on DMARC and BIMI. Its published capabilities cover DMARC deployment and reporting, DKIM setup with a DKIM record checker, SPF, BIMI, a DMARC record generator, DMARC setup guides, and a compliance checker for the Google and Yahoo bulk sender requirements. That is a tightly scoped product set, and the scope is the point: this is a tool for getting email authentication right, not a mail gateway and not a phishing defence suite. I would rather describe honestly what it does than pad the list, so the rest of this page is mostly about the problem, because that is where projects actually succeed or fail.

Start with what the three records really do, because they are constantly conflated. SPF is an authorisation list published as a DNS TXT record. It names the IP addresses and hosts allowed to send mail for your domain, and a receiving server compares the connecting IP against that list. Crucially, SPF checks the envelope sender, the address used during the SMTP conversation, which is not the address a human sees in the message. 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 the signature. 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 is the layer that closes that gap. It introduces 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 it 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 receivers to refuse it outright. Only quarantine and reject are enforcement. A domain sitting at p=none has visibility and no protection, and a great many organisations that believe they have implemented DMARC are in exactly that state.

Two technical details 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 in your SPF record costs a DNS lookup, and those nest, so one cloud provider include can quietly consume several. Exceed ten and the record returns a permanent error, at which point SPF fails for legitimate mail, not just for attackers. Large estates hit this quickly because every new SaaS platform that sends on your behalf wants another include. The fix is flattening, consolidation, moving senders onto 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. They are machine output, and reading them by hand across even a modest estate is not realistic. This is precisely the gap a DMARC platform fills: parsing, source identification and trending. Without tooling, most organisations publish a RUA address, collect the XML in a mailbox nobody opens, and stop there.

BIMI is the brand payoff and it sits at the end of the road, not the start. To display your logo in supporting inboxes you need DMARC at enforcement, a logo in the specific square SVG Tiny Portable/Secure profile, a BIMI record in DNS, and for the major mailbox providers a Verified Mark Certificate from an approved authority, which normally requires a registered trademark and an organisational verification process with an annual cost. It is worth wanting, but it is not a shortcut and no platform can grant it without the underlying enforcement being real.

Why EmailAuth 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. DMARC at enforcement is the control that stops an attacker sending mail that appears to come from your own domain, which removes the most convincing version of that attack. Brand 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 name 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 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 name DMARC as a line item, and I would not claim otherwise, but domain spoofing is a direct route to both fraud loss and personal data compromise, so it is a control an assessor understands immediately once you show them the reports.

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, and that is what moved this off the backlog. For the wider picture of how authentication fits with gateway controls and awareness training, see my email security services.