Custom DMARC, DKIM, SPF and DNSSEC monitoring
Setting up SPF, DKIM and DMARC takes an afternoon. Knowing who sends on behalf of your domain is another matter. The reports that answer that question arrive daily as XML from dozens of receiving parties, and as long as nobody reads them, your policy stays at p=none and protects nothing.
Why p=none remains the end state
The three email standards work together. SPF states which servers may send on behalf of your domain, DKIM places a signature on the message, and DMARC determines what a recipient should do if either of those fails. DNSSEC additionally signs the DNS responses themselves so they cannot be forged in transit. They appear on the list of open standards to which the 'apply or explain' principle applies, and internet.nl tests them publicly.
Setting it up is not the problem. The problem is the step from p=none to quarantine and eventually reject. As long as you do not know which systems send on your behalf, that step is a gamble: if you tighten the policy too early, invoices, password reset emails or newsletters from a marketing platform that nobody had on the list will disappear.
The only source that makes this visible is the DMARC reports. Receiving parties send a daily overview of what they have seen on behalf of your domain, in XML, per sending server. With ten domains, that is hundreds of files a week. Opening them by hand happens for two weeks, and then stops. That is why the policy stays at p=none. You can have your domain publicly tested at internet.nl.
How we build this
The order is: see first, then tighten. Any proposal to tighten the policy before the senders have been mapped is a proposal to lose post.
Not only your main domain but also the domains you once registered and never used. Those are precisely the ones that get abused, because no policy is in place and nobody is watching them.
Setting up addresses where the reports arrive and letting that flow run, without changing anything in the policy yet. After a few weeks you have a picture on which you can base a decision.
Each sprint ends with something you can verify yourself, and we start with processing and making the reports readable. Without that view, tightening is a gamble.
Per domain, from p=none to quarantine and then to reject, with a percentage you increase. At each step you see what would have been rejected before it actually happens.
What the integration actually does
Processing reports is the core; monitoring DNS records is what prevents things from quietly breaking again.
Reports processed and readable
The daily XML from receiving parties is read and brought together into one picture: which sender, which domain, how many messages, and whether SPF and DKIM passed. That is the information on which you base a policy decision.
Unknown senders singled out
A sending server you don't recognise is either a marketing package a department bought itself, or someone abusing your domain. The distinction between the two is exactly what you want to see before you tighten.
Effect of a policy change in advance
What would have been rejected had you been on reject now. You ask that question before the change, not after, and the answer determines whether you are ready.
Monitoring your DNS records
An SPF record that an administrator modifies and that becomes too long, or a DKIM key that expires, breaks your email without warning. Continuous checking with an alert the moment it happens.
DNSSEC status per domain
Whether the zone is signed and whether the signature remains valid. An expired or broken signature makes your domain unreachable for some resolvers, and you only notice when customers start calling.
History for accountability
Which policy was in place when, on which domain, and what the traffic looked like at the time. For an audit or a test against open standards, that is the justification; in the event of an incident, it is the timeline.
Who we build for
The number of domains and the number of departments buying things themselves determine how messy it gets. Four situations.
Government and public organisations
Here the open standards apply through the principle of apply or explain, and internet.nl makes the score public. That makes it visible in a way that is missing elsewhere. If a broader security assessment is also under way, see ICT security assessment.
Organisations with many domains
Brands, campaigns and old domains that were never decommissioned. The unused domains are the greatest risk, because often no policy is in place there at all. If a broader risk register is also in place, see IT risk management.
Financial services and healthcare
Where phishing in your name causes direct damage. Here the step to reject is not a compliance question but a damage-limitation question, and therefore more urgent. If you fall under the reporting obligation of the Cyber Security Act, an incident belongs there; see incident reporting portal.
Managed service providers and agencies
You manage domains for multiple clients and need the same monitoring for each one, with a hard separation between them. Off-the-shelf packages are usually built around a single organisation.
Technology and integrations
Reports arrive in varying quality, so ingestion has to tolerate malformed data. And DNS checks need to run from multiple locations, because a record that resolves correctly from your office may be answered differently elsewhere.
Why Appfront
Visibility comes before tightening
Anyone can set p=reject. The question is whether you know what will stop working as a result. We build the insight first and only then take the step.
The surprises come from your own departments
In practice, the unknown sender is more often a marketing platform than an attacker. You want to see both, and the distinction matters for what you do about it.
It quietly breaks again later
An administrator changes an SPF record, a key expires, a zone is migrated. Without ongoing monitoring, you only notice when clients start calling.
Honest about what this doesn't solve
DMARC protects your domain against misuse of your name. It does not protect you against phishing from lookalike domains or against a compromised account. Those require other measures.
Security and privacy
DMARC reports contain more than technical data. Aggregate reports are aggregated and fairly harmless, but forensic reports can include fragments of individual messages, including sender, recipient and subject. That is personal data, and many receiving parties therefore don't send them, or send them only in limited form. Enable them only when you know why you need them, and retain them for a shorter period than the aggregate reports.
In addition, this file is itself of interest to an attacker: it describes exactly which systems send on your behalf, which domains are weakly configured and which policies are still at p=none. That is a map for an attack. We therefore keep access tight and role-based, and for managed-service providers strictly separated per client. We also record, per domain, which policy change was made when and by whom, because in an incident the first question is what changed shortly before. How we handle security internally is set out in our information security policy; reports from outside reach us via our CVD policy.
Frequently asked questions about DMARC and DNSSEC
SPF specifies which servers may send on behalf of your domain. DKIM attaches a cryptographic signature to a message so the recipient can verify it was not altered in transit. DMARC ties the two to your domain name and tells the recipient what to do if the checks fail: nothing, quarantine, or reject. Without DMARC, the first two are optional in practice.
Because nobody reads the reports. That is no reproach: they are daily XML files from dozens of parties, and with several domains there are hundreds each week. Without processing you don't know which systems send on your behalf, and then tightening carries the risk of mail disappearing. Insight is the precondition, not the setting.
That legitimate mail gets rejected without anyone noticing. Think of invoices from an accounting package, password resets from an application, or a newsletter from a tool a department bought itself. That is why we build a simulation: you see what would have been rejected before it actually happens.
They are on the list of open standards for which the apply-or-explain principle applies to government bodies, and internet.nl checks them publicly. For other organisations they are not legally required but are common practice, and receiving parties are becoming stricter. Whether and how this applies to you is for you to determine with your own adviser; we build the monitoring.
SPF, DKIM and DMARC are all held in DNS. Anyone who can forge DNS responses can bypass them. DNSSEC signs the responses so that this cannot happen. It is therefore not a separate topic but the foundation beneath them. Do note, however: an expired or broken signature makes your domain unreachable for some resolvers, so monitoring is more important here than for the other three.
We can, but we advise keeping monitoring and management separate: the system that checks whether something is correct is better not to be the same system that changes it. In practice, we build the monitoring and the simulation, while changing records remains with your own administrator or provider, with an alert from the system when something needs attention.
Yes, and that is usually the reason to build it. Each client keeps its own domains and reports, with an overview on top of which client has which policy and where it is weak. Separation between clients is a design requirement: this file describes exactly where someone is vulnerable. The link with your own systems runs via integrations.
That depends on the number of domains, whether forensic reports must be handled, and whether multiple clients need to run separately. Processing the aggregate reports with the sender overview is generally quick to become useful and delivers the most value; DNS monitoring and simulation cost more. We will give a reasoned estimate after the discovery phase.
Ready to build DMARC monitoring?
Ask your administrator which DMARC policy is set on your main domain. If the answer is p=none, nobody has ever acted on the reports, and then you know where this project starts. We build this as a standalone application and as part of a broader custom software project.