About this case. It describes a common situation and a sensible approach, written without naming any customer. It reports no measured results, so set your own baseline and targets and measure your own outcomes.
The situation
Consider a digital lending and payments company. Its customers receive transaction alerts, one-time verification codes, monthly statements, payment reminders and account-change notices. These are not marketing emails. A late alert can mean a customer does not notice a fraudulent transaction. A spoofed "statement" email can lead a customer to a phishing page. For a business like this, email is part of the security perimeter.
The engineering team inherited a setup that had grown piece by piece. Alerts came from the main company domain. Statements were sent by a batch job through a separate tool. Marketing used a third system, also sending as the company domain. The DMARC record existed but sat at p=none, and nobody read the reports. A security review flagged two problems: anyone could send mail that appeared to come from the company, and the team could not say how long alerts took to arrive.
Goals
- Make it hard for anyone else to send email as the company, by moving to an enforcing DMARC policy without breaking legitimate mail.
- Know, measure and alert on how quickly time-sensitive messages are delivered.
- Separate alert, statement and marketing traffic so one cannot harm another.
- Keep an auditable record of what was sent, to whom and what happened to it.
Step 1: discover every sender
Enforcement fails when a legitimate sender is forgotten. The team therefore began with discovery, not DNS changes. They added a reporting address to the DMARC record and let aggregate reports accumulate for several weeks.
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
The reports listed every source of mail claiming to be the domain. Most were expected. Three were not: a support helpdesk tool, a survey platform used by one team, and an old server that still sent a nightly report. Each was either brought under control or retired. This step took longer than any technical change, which is typical. Our guide to reading aggregate reports describes the process, and our DMARC adoption analysis shows how common it is for domains to stall at this stage.
Step 2: split streams by purpose
| Stream | Messages | What matters most |
|---|---|---|
| Security and alerts | One-time codes, transaction alerts, login notices | Speed and reliability; no promotional content |
| Statements and documents | Monthly statements, receipts, tax documents | Authentication and trust; stable sender identity |
| Reminders | Payment due dates, mandate notices | Timeliness and clear unsubscribe or preference options where applicable |
| Marketing | Offers, product news | Consent, complaint control |
Each stream was given its own subdomain with its own SPF, DKIM and DMARC records, and the marketing stream was moved fully away from the alert domain. The reasoning is the same as in our analysis of bulk-sender rules: complaints on a marketing stream should never touch the reputation of the domain that carries security alerts.
Step 3: align and sign everything
For every stream, the team checked that the domain in the visible From address matched the domain used for DKIM signing (alignment), because DMARC passes only when SPF or DKIM aligns with the From domain. Statements, which were generated by a batch job, needed a code change so the job sent through the authenticated relay instead of direct from an application server. They also published a Brand Indicators record only after enforcement was in place, as BIMI requires it (see our BIMI guide).
Step 4: tighten the policy gradually
- Quarantine at low percentage. Apply the policy to a small share of failing mail and watch the reports.
- Raise the percentage. Increase in steps as the reports show only unauthorised mail failing.
- Move to reject. Once legitimate mail passes consistently, move to reject, and keep reporting on.
- Re-check on every change. Any new vendor that sends as the domain must be authenticated first; this became part of the vendor onboarding checklist.
The team scheduled each step for a week without a major billing run, so that an unexpected failure would be easy to attribute.
Step 5: measure delivery time, not just delivery
For alerts, "delivered" is not good enough; the question is how fast. The team used delivery events sent by webhook to record three timestamps for each alert: when the application requested it, when the sending platform accepted it, and when the receiving server confirmed delivery. The difference between the first and last is the time a customer waits. Dashboards showed this distribution by mailbox provider, and an alert fired if the slow tail grew beyond an internal threshold.
One-time codes were treated separately, with a short validity period and a "resend" path that did not simply repeat the same message to the same slow path. We also discuss why authentication mail needs extra care in our piece on passkeys and transactional email.
Step 6: keep the evidence
Finance and compliance teams need to answer "was this statement sent, and did it arrive?" The company stored the delivery events alongside the message identifier and customer reference so that an agent could look up the status of any message without involving engineering. Retention periods were set with the compliance team, and access to the logs was limited by role.
If something breaks: the rollback plan
Any change to an enforcing policy needs a way back. Before each tightening step, The team wrote down who would watch the reports, what signal would trigger a rollback and how to reverse the change. DNS changes can take time to propagate, so a low TTL on the DMARC record during the rollout meant a rollback would take effect in minutes, not hours. If a legitimate system began to fail, the team's first action was to return the policy to the previous step, then fix the sender, then try again. They also kept a list of "known good" sources and their authentication status, reviewed monthly, so that a new failure stood out immediately instead of hiding in the noise.
The team also agreed a communication rule: the security team owns the policy, the engineering team owns the senders, and any change to either is announced to the support team in advance, so that an unexpected customer complaint can be connected to a change within minutes.
How the team would measure success
| Measure | Why it matters |
|---|---|
| Share of mail claiming the domain that passes DMARC | Shows whether enforcement is clean and spoofing fails |
| Alert delivery time, median and slow tail | A late alert can defeat its purpose |
| Complaint and bounce rate by stream | Protects the alert domain from marketing problems |
| Number of unauthorised sources seen in reports | Should fall to zero and stay there |
| Support lookups resolved without engineering | Shows whether the audit trail is usable |
We deliberately give no numeric results; any real programme should set its own targets before starting and report against them.
What the team learned
- Discovery is the project. The technical change to reject is a single line; finding every legitimate sender is the work.
- Different messages deserve different promises. An alert and a newsletter should not share a domain, an IP pool or a failure mode.
- Time is part of delivery. For transactional mail, measure the wait, not just the outcome.
- Vendor onboarding is a security control. A new tool that sends as your domain should not go live until it is authenticated.
Adapting this to your business
- Publish DMARC with reporting and gather several weeks of reports.
- Resolve every unknown sender and document owners for the rest.
- Split alerts, statements, reminders and marketing onto separate authenticated subdomains.
- Move through quarantine to reject in steps, outside of peak billing periods.
- Record delivery timestamps and alert on the slow tail.
- Agree log retention and access with compliance, and add authentication to your vendor checklist.
Sending alerts, statements or verification codes? Talk to us about stream separation and DMARC enforcement.
Related reading
Frequently asked questions
Does this case name a customer?
No. It describes a common situation and approach without naming any customer, and it reports no measured results.
Why measure delivery time and not only delivery?
For alerts and one-time codes a late message can defeat its purpose, so track the time from request to inbox and alert on the slow tail.
How do I avoid breaking legitimate mail when enforcing DMARC?
Collect aggregate reports first, identify and authenticate every legitimate sender, then move through quarantine at low percentages to reject, with a rollback plan.
Why separate alerts from marketing?
So complaints on marketing mail never affect the reputation of the domain that carries security alerts.