Mailhardener Email Authentication & MTA-STS Consultant

What is Mailhardener?

Mailhardener is an email security and authentication monitoring platform. Its published scope covers SPF, DKIM, DMARC and MTA-STS, together with TLS reporting, plus a features catalogue, published pricing, an MSP offering for managed service providers, a substantial knowledge base and a set of free diagnostic tools. That last part is worth noticing before you buy anything, because you can check the current state of a domain without an account.

The distinguishing feature is the standard set, not the dashboard. A great many products in this category are DMARC report parsers with a nice chart on the front. Mailhardener covers the full modern email hardening list, and MTA-STS with TLS-RPT is the part most competitors treat as an afterthought. That matters because MTA-STS addresses a completely different threat from DMARC, and conflating the two is the most common misunderstanding I meet in this space.

Start with what the authentication records actually do, because they are constantly confused with each other. 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 it checks the envelope sender used during the SMTP conversation, not the address a human reads. 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 parts were not altered. Neither record, on its own, says anything about the From address the recipient sees.

DMARC closes that gap by introducing alignment. The domain that passed SPF or DKIM must match the domain in the visible From header, which is what stops an attacker passing SPF using their own domain while still displaying yours. DMARC then publishes a policy telling receivers what to do when nothing aligns, and requests reports back. The policy values are the whole journey. p=none monitors and blocks nothing. p=quarantine asks receivers to treat unaligned mail as suspicious. p=reject asks them to refuse it outright. Only the last two are enforcement, and a great many organisations that believe they have implemented DMARC are sitting at p=none with visibility and no protection. Two tags decide more than people expect: sp= sets the policy for subdomains, and leaving it unset means subdomains inherit the organisational policy, which is either exactly what you want or a surprise depending on whether anyone thought about it. pct= applies enforcement to a percentage of traffic, and it is the safest way to test a policy change on real mail.

MTA-STS is the other half, and it points the other way. Everything above concerns mail claiming to be from you. MTA-STS concerns mail being delivered to you. SMTP encryption is opportunistic by design: a sending server asks whether STARTTLS is available and uses it if the answer is yes. An attacker positioned on the network path can strip that advertisement from the conversation, and the sending server, having no expectation to the contrary, simply delivers in plaintext. MTA-STS removes the ambiguity. You publish a policy file over HTTPS at a well-known location on a dedicated subdomain, plus a DNS record pointing at it, and that policy states which mail hosts are valid for your domain and that TLS with a validating certificate is required. A sending server that honours MTA-STS will then refuse to deliver rather than downgrade. TLS-RPT is the accompanying feedback channel: sending providers post back daily JSON summaries of successful and failed TLS sessions, so you can see certificate mismatches, expired certificates and policy fetch failures before you switch the policy from testing to enforce. DMARC stops spoofing of your domain. MTA-STS stops silent downgrade of mail into it. Neither substitutes for the other, and a project that does only the first has left the second wide open.

Two operational 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 costs a lookup and they nest, so one cloud provider include can consume several. Exceed ten and the record returns a permanent error, which fails SPF for your legitimate mail rather than for an attacker. 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. TLS reports arrive as JSON on a similar rhythm. Both are machine output, and reading either by hand across even a modest estate is not realistic. This is precisely the gap the platform fills. Without tooling, most organisations publish a RUA address, collect XML in a mailbox nobody opens, and stop there.

Why Mailhardener for UAE Organisations?

The regional case for email hardening 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 removes the most convincing version of that attack, the one where the mail genuinely appears to come from your own domain. 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 a sender name they can see.

The transport side deserves its own argument rather than being folded into the first one. Mail arriving at a UAE organisation routinely carries contract terms, bank details, passport scans, salary data and health information. Without MTA-STS, delivery of that mail relies on opportunistic TLS, which an attacker on the network path can strip so the message arrives in plaintext with nobody being told. That is a confidentiality failure with a straightforward personal data consequence, and it is the kind of exposure an assessor understands immediately once you show them a TLS report with failures in it. It is also cheap to fix relative to almost anything else in a security programme, which is what makes leaving it undone hard to defend.

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 or MTA-STS as a line item, and I would not claim otherwise. The argument runs through fraud exposure and personal data risk instead, which is a stronger argument anyway because it survives contact with a finance director. On top of that sits 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 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. For the wider picture of how authentication fits with gateway controls and awareness training, see my email security services.