ESENRODEFRIT
Contact

2026-08-10 · Ibida Black Level S.L.

DMARC explained: why your email is vulnerable and how to fix it in 24h

Why most mid-market companies still have weak DMARC, what a working configuration looks like, and a 24-hour path to p=reject without breaking mail.

DMARC explained: why your email is vulnerable and how to fix it in 24 hours

DMARC is one of the cheapest cybersecurity controls available to a mid-market European company. Implementing it well requires no licence purchase, no new infrastructure, no headcount, and no compliance certificate. Implementing it badly is just as cheap. The difference between the two is a couple of days of operational discipline.

We open every OSINT defensive engagement with a DMARC, SPF, and DKIM check on the client's primary domains. In 2025 and the first half of 2026, the median mid-market European company we looked at had at least one of these three controls misconfigured. Most often it was DMARC sitting at `p=none` since the day it was published, with nobody monitoring the aggregate reports it was supposed to generate.

This article is a working plan to move from "we have DMARC on paper" to "we are protected at the level the directive expects". We assume your company runs Microsoft 365 or Google Workspace as the primary mail platform; the steps are equivalent in either case, with vendor-specific details called out where they differ.

What DMARC does and what it does not do

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It is a policy expressed in a DNS TXT record that tells receiving mail servers what to do with a message that claims to come from your domain but fails the underlying SPF or DKIM checks. The policy can be `none` (monitor only), `quarantine` (route to junk), or `reject` (refuse delivery).

DMARC does not, on its own, encrypt your email, prevent your accounts from being compromised through credential reuse, or protect you from messages sent from lookalike domains. It protects the deliverability and authenticity of mail genuinely sent from your domain, and it makes your domain very hard to spoof at scale.

For business email compromise (BEC), the most expensive email-borne threat to mid-market European companies in recent years, DMARC at `p=reject` cuts off one of the four most common pretexts: a message that claims to come from the CEO's domain itself, not from a lookalike.

Why most mid-market companies are at p=none

The reason is rarely lack of awareness. The reason is fear of breaking mail. Moving from `p=none` to `p=quarantine` or `p=reject` can, if done without diligence, cause legitimate mail to land in junk or be refused outright. Senior leadership tends to remember the day a board notification ended up in spam more vividly than the day a fraudulent invoice did not arrive at all.

The solution to that fear is the aggregate report. DMARC's `rua` tag asks receiving servers to send daily reports summarising who tried to send mail from your domain and whether the SPF and DKIM checks passed. With two weeks of those reports, you can build a complete picture of every legitimate sender you need to authorise, before you tighten the policy.

The 24-hour fix, hour by hour

We assume you have already published a DMARC record at `p=none` with a working `rua` address. If you have not, the first action is to do so and wait two weeks. The plan below applies to the second phase.

Hour 0 to 4 · Inventory of legitimate senders

Pull the last 14 days of aggregate reports. Categorise the source IPs into four buckets:

1. Your primary mail platform (M365 or Google Workspace).

2. Your transactional and marketing platforms (AWS SES, Mailgun, SendGrid, Mailchimp, Acumbamail, your own Auctimail instance if you have one).

3. Your customer support and CRM tools that send mail on your behalf (Zendesk, HubSpot, Intercom, Front).

4. Unknown sources.

The fourth bucket is the work. Every IP in it is either a legitimate sender nobody documented or a spoofing attempt. Trace each one. The most common surprises are: a legacy on-premise application server that still sends invoices via a forgotten relay, a HR tool subscribed last year by one team without coordination with IT, and an external accountant who configured your domain in their own mail client because nobody told them not to.

Hour 4 to 8 · SPF cleanup

Your SPF record is a comma-bounded list of senders you authorise. Edit it so that:

A clean SPF record for a mid-market company on Google Workspace plus AWS SES plus HubSpot reads something like `v=spf1 include:_spf.google.com include:amazonses.com include:_spf.hubspot.com -all`. Anything substantially more complex is a sign of accumulated drift.

Hour 8 to 12 · DKIM verification

For each legitimate sender that supports DKIM signing on your behalf, verify the selector is published and the public key is current. Microsoft 365 uses `selector1` and `selector2`. Google Workspace uses a configurable selector, typically `google`. AWS SES uses three CNAME records pointing to its DKIM signing infrastructure.

The check is simple: send a test message from each platform to a mailbox that exposes the raw headers (`mailtester.com`, `dmarcian.com` test inbox, or a Gmail account with "show original" enabled), and verify both `spf=pass` and `dkim=pass` for the relevant alignment.

If any legitimate sender does not support DKIM on your behalf, you have a strategic decision. You can either accept that those messages will fail DMARC alignment (and ask the sender to upgrade or replace them), or you can leave the policy at `p=quarantine` instead of `p=reject` until that gap closes. We have stopped recommending the latter; vendors that cannot sign with your DKIM in 2026 are vendors you should be moving away from.

Hour 12 to 16 · Move to p=quarantine, pct=100

Update the DMARC record to `p=quarantine; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected]; sp=quarantine; adkim=s; aspf=s`. The strict alignment flags (`adkim=s; aspf=s`) are not always necessary; the relaxed default is acceptable for most mid-market companies. The point is to commit to a real quarantine action and to monitor.

Watch the aggregate reports for the next 24 hours. If a previously unidentified legitimate sender starts failing, add it to the SPF or DKIM configuration before proceeding to the next step.

Hour 16 to 24 · Move to p=reject

Update the DMARC record to `p=reject; pct=100; rua=...; ruf=...; sp=reject; adkim=s; aspf=s`. Communicate to your senior leadership that mail spoofing your domain will now be refused by receiving servers that honour DMARC, which includes essentially the entire major mail provider population.

Set a calendar event 14 days out to review the aggregate reports again, looking for any legitimate sender that the move broke. By that point, the surprises tend to be small and easy to fix.

What about BIMI

BIMI (Brand Indicators for Message Identification) is a complementary control that allows your verified logo to appear next to authenticated messages in supporting mailbox clients. It requires DMARC at `p=quarantine` or `p=reject` with `pct=100`, a verified SVG of your logo, and a Verified Mark Certificate from an authorised authority.

For a mid-market company, BIMI is a nice-to-have, not a security necessity. The honest order of operations is DMARC first, BIMI after, only if your brand exposure justifies the certificate cost and the operational overhead of maintaining the VMC.

Honest pitfalls

> "We have measured the time from a DMARC `p=none` record to a working `p=reject` posture in mid-market companies, when the work is owned by a single engineer with executive cover. The median is 28 hours. The point of the 24-hour plan is to make the second day a polish day, not a panic day." — IBL field engineering note, 2026

What we do at IBL

Our DMARC sprint engagement is a fixed-scope, fixed-duration exercise: two days of work, one day of monitoring, one day of polish. The deliverable is the working DMARC record, the SPF record, the DKIM configuration documentation, an inventory of every authorised sender, and a one-page runbook for the engineer who will own the control going forward.

If you want a conversation about your current DMARC posture, write to [email protected]. We answer within one business day.

---

Ibida Black Level S.L. is a boutique cybersecurity advisory firm headquartered in Málaga, Spain, with an operational team in Romania. We focus on mid-market European companies that prefer technical honesty to vendor packaging. We were founded in 2026; we do not invent a longer history.

Related reading

Tags: dmarc, spf, dkim, email-security, anti-spoofing, bec, compliance