DMARC for government domains: step-by-step enabling of SPF, DKIM and reporting

The task in plain words: how to protect a government domain from spoofing

"Emails sent on our behalf" are not only messages your mail system actually sends. They include any messages that have your domain in the From field (for example, @gov.kz), even if attackers sent them from their own servers. To a recipient this looks convincing: a familiar domain, an “official” tone, sometimes even a manager's signature.

For government domains the risks are especially serious. Phishing pretending to be official notices, document requests or “urgent” orders affects citizens and contractors and damages the agency's reputation. That often leads to complaints, the domain being flagged by spam filters, blocks by major providers, and delivery problems for legitimate notifications.

Protection is built on three mechanisms:

• SPF shows which servers are allowed to send mail for the domain.
• DKIM adds a cryptographic signature so a message can't be modified unnoticed.
• DMARC ties the checks together and tells recipients what to do with "suspicious" messages.

It's important to proceed step by step. Government organizations almost always have "hidden" senders: a citizen portal, HR systems, a mailing service, contractors, MFPs/scanners, medical or educational platforms. Enabling a strict policy at once will cause some legitimate mail to be rejected and you'll learn about it from users.

Success is measured by simple results: you know all sending sources, legitimate mail is delivered reliably, forgeries are flagged or blocked, and reports reveal new sources and anomalies without unpleasant surprises. The ideal goal is that only verified sources can send on behalf of the domain and everything else is automatically dropped.

A short primer on SPF, DKIM and DMARC without extra theory

Keep a simple picture in mind: SPF says which servers may send, DKIM proves the message wasn't altered in transit, and DMARC defines rules for messages that fail checks.

SPF checks the sending server's IP against a list published in DNS. But SPF doesn't protect the visible From field and often breaks on forwarding and with some mailing services where mail doesn't originate directly from your server.

DKIM attaches a cryptographic signature to a message. The recipient verifies the signature against the public key in DNS and sees that the content and key headers weren't changed after sending. Plan key rotation in advance: using the same key for years is an unnecessary risk and a headache during incidents.

DMARC is useful because it links SPF and DKIM into a single rule and introduces alignment. It checks not only whether SPF/DKIM passed, but whether the domains checked match the domain in the visible From. This reduces spoofing risk.

DMARC has three policy modes: none (monitoring only), quarantine (treat as spam) and reject (block). Usually you start with none to collect data and avoid breaking legitimate deliveries.

At the DNS level you'll typically need:

• SPF: a TXT record at the root (or sending subdomain).
• DKIM: TXT records for selectors like selector._domainkey.
• DMARC: a TXT record _dmarc with policy and report addresses.

In practice at least three roles are involved: mail admin (sender settings and DKIM), DNS zone owner (publishing records) and InfoSec (policies, risk control and report analysis).

Preparation: inventorying “who actually sends” on behalf of the domain

Before enabling SPF, DKIM and DMARC you must answer a simple question: how many different systems actually send mail using your domain and who is responsible for them. Without that you'll quickly face complaints that "emails stopped sending" and you'll start troubleshooting blindly.

Compile a list of legitimate sending sources. In government bodies the list is almost always larger than "our mail server": mail may go out from different departments, contractors and old devices that no one remembers until they fail.

Common entries are corporate mail and gateways, mailing and notification services (websites, portals, call center, ECM), MFPs/scanners with "scan to email", external contractors, plus test environments and subsystems that send externally.

Give each source a "passport": owner (department), technical contact, who can change settings and how fast they respond. When you tighten DMARC you'll ask for changes not only from mail admins but from system owners.

Also review DNS management: who has access, who approves changes and what process is used. Agree on maintenance windows (night, weekend) and prepare a rollback plan in case a critical service suddenly stops sending.

Create a separate mailbox for aggregated DMARC reports (RUA). It should not be a personal inbox and should have a clear owner: reports arrive regularly and need to be processed.

Step 1: configure SPF carefully and without surprises

SPF is a list of senders you allow to send on behalf of the domain. If SPF is assembled randomly, reports and policy tightening will raise false alarms.

First choose a model. If all outgoing mail is controlled by one mail platform, a single SPF record on the primary domain is often sufficient. If mail comes from many systems (HR notifications, service desk, mailings, portals), it's simpler to separate flows: move some sending to dedicated subdomains and configure SPF there. That reduces the risk of accidentally breaking critical mail.

Then collect a full list of allowed sources: your mail servers, gateways, cloud mail providers and contractors sending on your behalf. This is usually a mix of IP addresses (ip4/ip6) and include entries for services.

Check the SPF DNS lookup limit. A common cause of failures is reaching the limit (10 DNS lookups) so receivers stop evaluating SPF. If you have many includes, shorten chains or split sending across subdomains.

Roll out the record gradually: start with ~all (soft mode) to see sources not covered by the list. After fixes move to -all (strict).

Keep simple documentation: what was added, who owns the source, which messages it sends and who approved it. If a contractor changes platforms, these notes save time.

Step 2: enable DKIM and organize key management

DKIM adds a cryptographic signature to each outgoing message. The recipient verifies it against a public key in DNS and knows the message passed through your domain and wasn't noticeably altered. Without DKIM it's harder to safely move to a strict DMARC policy.

Where to sign

Sign where the message leaves to the Internet and where you can best control settings. It's important that all major flows are signed.

Typically signing is enabled on the mail server, on the mail gateway (the last hop before the Internet), at cloud mail providers, at mailing services or within application systems that send directly (if there's no other option).

If there are several sources, it's useful to centralize outbound mail through a single gateway. That reduces the number of places where a signature can be forgotten.

Choose key length (usually 2048 bits) and use clear selectors (for example by year or system). Keep the private key only where signing occurs. Restrict access, assign owners and set up change control.

Rotation and control

Rotation must be scheduled, not ad hoc. Practical minimums:

• assign a key owner and a backup;
• rotate keys on a schedule (for example every 6–12 months);
• publish the new key in DNS before switching the signing selector;
• keep the old key for some time while messages propagate to recipients.

Check that intermediate processing doesn't break signatures: disclaimers, antivirus gateways or forwarding through ECM systems often modify messages. Usually signing closer to the last outbound hop and choosing relaxed/relaxed canonicalization helps. After enabling, send test messages from all systems and confirm recipients report DKIM = pass.

Step 3: enable DMARC in monitoring mode and start collecting data

When SPF and DKIM are configured for primary senders you can enable DMARC in a way that doesn't break mail. The goal is to see who really sends mail for your domain and which flows fail checks.

Start with a monitoring policy: p=none. This means mail won't be blocked by DMARC but you'll begin receiving reports.

Example basic DMARC record (adapt for your domain and report mailbox):

_dmarc.example.gov.kz TXT "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=s; aspf=s; pct=100"

Practical meaning in this record:

• rua: address for aggregated DMARC reports (RUA), sufficient to start;
• ruf: forensic report address, if your policy allows receiving such data;
• adkim and aspf: alignment modes. For a government domain it's often reasonable to begin with strict alignment to more quickly reveal unauthorized flows.

Aggregated reports (RUA) usually arrive daily as XML archives. Decide where they are stored and who can access them. A practical option: a dedicated mailbox for reports, automatic extraction into secure storage, and a simple parsing tool to filter by source (IP/provider), service and SPF/DKIM results.

Keep monitoring for 2–4 weeks. During that time you'll discover irregular mail sources: HR notifications, old printers, recording services, temporary contractors.

At this stage do not punish failing messages. Classify reasons: wrong SPF, no DKIM, DKIM present but not aligned, or sender not belonging to you.

Consider subdomains separately. For addresses like service.department.gov.kz set sp (policy for subdomains) or leave it equal to p to avoid unexpected blocking later. In large organizations it's often easier to set sp=none initially and create separate rules for critical subdomains.

If you lack an internal team to parse reports and bring senders into compliance, a systems integrator usually helps. For example, GSE.kz can handle organizational tasks from RUA collection to regular source analysis and coordinating changes with departments.

Analyzing DMARC reports: how to tell “who is sending on our behalf”

Aggregated DMARC reports (RUA) summarize who sent mail with your domain in the From field, from which IPs, and whether SPF and DKIM (including alignment) passed. This is the main source of truth: it shows the actual picture, not what "should be" according to regulations.

What is most useful in a report

Reports contain many fields, but for operational work you usually need a few:

• sending source: IP address and sometimes provider name;
• volume: how many messages came from that source;
• result: pass/fail for SPF and DKIM;
• alignment: whether DMARC passed for the From domain;
• time range: the day the statistics cover.

Start with volume: 1–2 sources often account for 80% of traffic. Then look at violation types: only SPF, only DKIM or alignment failures. For instance, SPF may fail on a legitimate system due to forwarding, while DKIM fails because the message body was modified.

To distinguish real mailings from spoofing look for signs: sudden new IPs, small "tails" of 1–5 messages per day, providers not matching your contractors, and combinations like "From is yours but neither SPF nor DKIM pass."

Maintain a registry of sources and update it from report analysis:

• source (IP or service) and purpose (what it sends);
• owner: department or contractor;
• status: confirmed, under review, blocked;
• remediation: add to SPF, enable DKIM, fix From;
• deadline and responsible person.

Enable forensic reports (RUF) selectively and briefly: they can contain message fragments and are often limited by recipient privacy policies. For routine work RUA is usually sufficient.

Example scenario for a government agency: from chaos to control

Imagine the ministry domain example.gov.kz. Mail is sent from several legitimate sources: corporate mail, a citizen portal, a contractor for mass mailings, plus several MFPs and scanners that send "scan to email."

In the first days of DMARC monitoring (p=none) extra sources almost always surface: an old service, a test server, a contractor sending with wrong settings or a device sending SMTP without authentication.

What reports show in the first days

Reports reveal who sends, from which IPs, whether SPF and DKIM pass, and whether alignment is achieved.

A typical pattern: corporate mail passes and aligns, the citizen portal passes SPF but doesn't sign DKIM, the contractor signs DKIM but uses a signing domain that doesn't align, and MFPs pass nothing.

How to decide without stopping work

Bring each branch to order with clear actions:

• Fix settings at the source: add the service to SPF, enable DKIM, set the correct signing domain.
• Move sending to a subdomain (for example notice.example.gov.kz) and configure SPF, DKIM and DMARC separately for it.
• Block a source if it's unnecessary or unmanageable (especially devices and bespoke senders).
• Ask contractors to send via an approved gateway or sign mail with your domain.

To avoid endless coordination, predefine owners: IT handles DNS and mail, the relevant department owns the portal and processes, procurement or contract managers handle contractors. Implement changes one at a time with a 2–3 day observation window after each step.

Measure progress in reports: the share of pass for SPF and DKIM grows, and alignment improves. When the noise subsides you can move from none to quarantine and then to reject.

Moving to strict policy: quarantine and reject without losses

A strict DMARC policy reduces phishing and spoofing risk, but should be enabled only after you know which sending sources are legitimate. For government agencies this is critical: losing delivery of citizen notifications or interagency messages is unacceptable.

How to move to quarantine and choose pct

After a period on p=none you'll have reports and a list of real senders. Next, it's safer to move to p=quarantine with a percentage.

Often organizations start with pct=10–25 and increase it every 1–2 weeks if no incidents occur. Increase pct after fixes: added missing SPF entries, enabled DKIM on a service, corrected alignment.

Don't look only at global percentages. Check which systems land in quarantine: MFPs, legacy notifiers, contractors, regional units.

When to enable reject

Switch to p=reject when gray areas are almost gone. Simple checkpoints:

• No new unknown senders in reports for at least 2–4 weeks.
• All important services consistently pass DMARC (SPF or DKIM with alignment).
• There's a clear process for adding new senders and applying changes.
• Separate rules are set for subdomains: mailings, tests, contractors.

Forwarding and mailing lists often break SPF while DKIM may be re-signed. Practically, three approaches help: rely on DKIM from the original sender, avoid breaking signatures on gateways, and use a separate domain/subdomain for mailing lists with a more flexible policy.

To keep the policy stable over time, document roles (domain owner, InfoSec, mail, contractors), response times for new sources and review settings quarterly.

Common mistakes and traps when rolling out SPF, DKIM and DMARC

Even with SPF, DKIM and DMARC enabled mail can still go to spam or be blocked. The root cause is usually mismatches between sending flows, domains and how messages change in transit.

Typical issues:

• SPF grows unwieldy and hits the DNS lookup limit (10). Receivers then treat SPF as permerror and DMARC fails. Fix by reducing includes, removing unused sources and splitting sending across subdomains.
• DKIM doesn't sign all outgoing flows: core mail is signed but portal notifications or other systems send unsigned mail or sign with another domain.
• DKIM signatures are broken in transit: a gateway adds a banner, changes line breaks or repackages MIME. Find where the message is altered and sign closer to the last outbound hop.
• DMARC is enabled but there's no alignment: the From domain is yours but the Return-Path (MAIL FROM) is different so SPF doesn't align. Or DKIM signs d=subdomain while you expect alignment with the primary domain.
• Forgotten third‑party services: ticketing, contractors, mailings, scanners, MFPs and web forms send as your domain but aren't technically ready for your policy.

A particular trap is enabling reject too quickly. Without a monitoring period you can cut off critical notifications and only learn about it days later.

Operational practice: start with monitoring, collect data, assign owners and keep a rollback plan (temporarily lower pct or revert to p=none). If no single owner for mail flows exists, involve an integrator to map senders and bring settings to a consistent standard.

A short checklist and next steps

SPF, DKIM and DMARC stop being a "scary mail topic" when turned into a clear control process.

Check basic readiness:

• Sending sources listed and confirmed (mail servers, service desk, mailings, HR systems, contractors). Each source has an owner.
• SPF configured carefully: no extra entries, all needed sources included, DNS lookup limits respected, and a clear change procedure for new services.
• DKIM enabled where possible: signatures reliably pass, keys controlled, a rotation plan (e.g., every 6–12 months) and a procedure for compromise.
• DMARC reports collected and analyzed: regular review, a sources registry and records of what is fixed and what is in progress.
• The move to quarantine/reject agreed: readiness criteria and maintenance windows are set to avoid disrupting mail, notifications and interagency communication.

Readiness criteria for tightening are simple: reports show most legitimate traffic passes SPF and/or DKIM with alignment, and unknown sources are disabled or brought into proper signing. The usual path is: p=none -> p=quarantine (with a small pct) -> raise pct -> p=reject.

Next, assign a process owner (often mail/InfoSec) and formalize a regimen: who adds new services, who reviews reports and who accepts risks. If internal capacity is limited, engage a systems integrator. For example, GSE.kz (gse.kz) operates as a vendor and integrator in Kazakhstan and can help build mail infrastructure, organize DMARC report analysis and support operations.