Bring your domains into compliance, and find out who writes in your name
Any server can send a message under your domain name: nothing in the original protocol prevents it. SPF, DKIM and DMARC, declared in your DNS, give receiving servers a way to verify that identity — and the rule to apply when it does not hold. This is DMARC policy management, usually handled by third-party tools. And because we like to stay ahead, e-securemail is already prepared to implement DMARCBis and DKIM2.
Request a demoWhat happens between sending and delivery
DMARC — Domain-based Message Authentication, Reporting & Conformance — adds two things to SPF and DKIM: an instruction for the receiving server when authentication fails, and a report telling you what it actually saw.
1. Two messages, one domain
Yours, sent by your legitimate servers. And an impersonator's, sent from elsewhere but signed with your domain name.
2. The recipient queries your DNS
Google, Microsoft, Yahoo and the rest check MX, SPF and DKIM, then read the DMARC policy you published.
3. Delivery, then reporting
The legitimate message arrives. The other is left alone, quarantined or rejected according to your policy. An XML report — the RUA — goes back to the address you declared.
Three policies, to be adopted in that order
These are not three options to pick from, but three stages of the same setting. Observe first, block later.
p=noneObserve without blocking anything
No message is set aside. You receive aggregate reports, which contain only volumes, IP addresses and authentication verdicts — no message samples, and therefore no personal data. This is the stage where you find out who sends in your name.
p=quarantineQuarantine
Unauthenticated messages are treated as suspicious and quarantined rather than delivered. They remain viewable: this is the safety net that lets you catch a legitimate source you forgot.
p=rejectReject
The receiving server refuses the message. Nobody can present themselves under your domain any more. That is the goal — but only once all your legitimate sources are identified and aligned.
The order matters
Publishing p=reject without an inventory of your senders — CRM, invoicing tool, emailing platform, newsletter provider — means having your own messages rejected by your customers. Reports exist precisely to build that inventory before you tighten the policy.
A publisher of reports, not just a reader
As well as feeding DMARC reports into the e-securemail administration console, Secuserve is the first French SaaS email security vendor to become a DMARC report sender.
The domains we protect therefore issue reports of their own to the domains they receive mail from. The feedback loop does not stop at our customers: their correspondents benefit too.
From raw XML to something readable
A DMARC report is an XML file sent by the major mail operators. e-securemail collects them, enriches them and presents them as tables and charts.
- SPF alignment and DKIM alignment, as a proportion of compliant messages
- The action recipients actually applied: none, quarantine or reject
- Reporters — which operators send you these reports, and for what volume
- The geographic origin of messages sent under your domain
- Volume by sending domain
Who sends in your name
The by-source view lists every sender using your domain names. For each row: the date, the reporting organisation, sender and recipient, country, IP address, and the SPF, DKIM and DMARC verdicts.
This is where you spot the unknown IP address sending under your domain — and, above all, where you tell a misconfigured legitimate provider, to be fixed, from an impersonation attempt, to be blocked. Both produce the same authentication failure; only context separates them.
Reports without personal data
Aggregate reports can be requested without message samples. What comes back is then limited to volumes, IP addresses and authentication verdicts.
The absence of DMARC makes compliance harder to demonstrate for organisations handling personal or sensitive data. But the reverse deserves just as much attention: collection set to detailed failure reports would bring back extracts of real messages. The type of report you request is not a technical detail.
DNS sits at the heart of your deliverability
SPF, DKIM and DMARC are not the only records at play. The platform monitors a domain's DNS compliance as a whole, and the scope widens with each release.
e-securemail modifies the messages it relays — warning banners, legal notices, rewritten links. Modifying a message in transit normally breaks the original signatures, so the solution implements the ARC protocol, which preserves the authentication result observed before relaying.
Monitoring comes with alerts and configuration guidance, with our teams on hand to help put the records in place.
Ready to test e-securemail on your current mail platform?
Our experts review your current setup and run a demonstration tailored to your mail platform.