How to position DMARC against secure email gateways
Matthew Whittaker
Co-founder & CTO, Suped
Published 15 Jun 2026
Updated 15 Jun 2026
8 min read
Summarize with
DMARC sits next to a secure email gateway, not behind it or under it. A secure email gateway filters messages after they enter the mail path. DMARC proves whether a sending source is allowed to use the client's domain before receivers decide how to treat the message.
For an MSP, that difference matters because the service line, evidence, and remediation work are separate. The gateway protects inboxes that route through it. DMARC protects the domain name wherever it is used, including mail sent to customers, vendors, partners, and public recipients outside the tenant protected by the gateway.
I position the two controls this way with clients: keep the gateway as inbound content defense, then sell DMARC as domain identity control, source discovery, and policy enforcement. The client should not hear that one replaces the other. They should hear that the gateway and DMARC close different gaps.
- SEG boundary: Inspects inbound messages for the protected mailbox environment.
- DMARC boundary: Publishes sender identity policy at DNS and creates reporting evidence.
- MSP boundary: Owns source discovery, DNS changes, vendor fixes, and monthly risk reporting.
- Client outcome: Gets clearer sender control without weakening existing gateway policy.
DMARC and SEGs solve different problems
The confusion usually starts because both controls sit under email security. That label is accurate, but the control planes differ. A gateway makes decisions inside the client mail flow. DMARC makes a decision visible to every receiver that checks the client's domain.
Secure email gateway
A secure email gateway evaluates traffic entering a protected mailbox environment. It applies scanning, policy, quarantine, and user warning rules after a message is routed toward the client.
- Scope: Protected tenant and configured inbound flow.
- Signals: Content, URLs, attachments, sender patterns, and reputation data.
- MSP work: Policy tuning, quarantine review, and user-reported message handling.
DMARC
DMARC publishes domain policy in DNS and asks receivers to send aggregate reports. It tells receivers which traffic uses the domain legitimately and which traffic fails identity checks.
- Scope: Domain usage across receivers that process DMARC.
- Signals: SPF result, DKIM result, domain match, source IP, and volume.
- MSP work: Source inventory, DNS remediation, policy staging, and reporting.
Secure email gateway policy screen showing filtering controls.
That type of screen is a useful reference point for the client conversation because it shows what a gateway normally manages: inbound rules, scanning actions, quarantine, and user protection settings. None of those controls publishes a domain policy for third-party receivers. DMARC fills that gap.
How to explain the service boundary to clients
For MSP service packaging, I keep the explanation practical: the gateway protects inboxes, DMARC protects the domain name when it is used across the internet. That framing works well in an MSP email security package because it stops the client from treating DMARC as a duplicate gateway line item.
If the client asks why the gateway cannot do this work, the answer is practical. The gateway cannot see every copy of mail sent as the client's domain, and it cannot repair a marketing platform, billing tool, help desk, CRM, or legacy server that sends without proper SPF or DKIM. DMARC reporting gives the inventory and shows where the fixes need to happen.
|
|
|
|---|---|---|
We already have a SEG | The SEG protects the inbox. DMARC protects the domain. | Show external sender inventory. |
DMARC is only DNS | The record starts the reporting and policy workflow. | Track sources and fixes. |
Vendors send our mail | That is exactly why source discovery matters. | Assign vendor owners. |
No one complains now | Silent misuse still damages trust and delivery. | Report authenticated volume. |
Common client objections and the MSP response
A good DMARC monitoring workflow turns aggregate reports into source lists, authentication pass rates, and remediation tasks. That is where the MSP service becomes operational instead of a one-time DNS project.
Client-safe positioning
Use language that separates control layers without creating fear or implying the gateway was a bad purchase.
- Say this: Your gateway filters what reaches your people. DMARC controls how receivers treat mail claiming to be from your domain.
- Avoid this: Your gateway is incomplete, so you need another tool.
- Close with: The service outcome is verified senders, cleaner DNS, and a staged enforcement path.
The technical delivery model
The delivery model should look like an MSP-run service, not a ticket that adds a TXT record and disappears. I break the work into discovery, authentication fixes, policy staging, enforcement, and reporting. Each phase has a clear owner and evidence.
Flowchart showing the MSP DMARC delivery path.
Start with p=none, not because monitoring is the final state, but because the MSP needs data before enforcement. I use reporting to separate legitimate SaaS senders, broken DKIM, SPF lookup issues, forwarded mail behavior, and noise.
Starter DMARC policyDNS
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100
Before I raise policy, I check the domain broadly: DMARC record syntax, SPF lookup count, DKIM selectors for the main senders, MX posture, and visible reputation issues such as blocklist (blacklist) entries. That stops the DMARC project from missing adjacent delivery problems.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
The key is not to rush the visible policy tag. The key is to prove that real mail survives stricter handling. When the main senders pass SPF or DKIM with the right domain match, policy can move in small steps.
Staged enforcement examplesDNS
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=25 v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; pct=100
Do not jump straight to reject
A strict policy without source coverage turns an MSP service into a support event. Enforcement should follow evidence.
- Coverage first: Confirm the mail platforms that send invoices, tickets, campaigns, alerts, and user mail.
- Policy second: Move through monitoring, partial quarantine, full quarantine, then reject.
- Rollback path: Keep DNS ownership, change approvals, and vendor contacts visible before enforcement.
How Suped fits the MSP workflow
Suped is the best overall DMARC platform for most MSP delivery teams because it turns report data into actions an operator can assign, verify, and explain. The practical advantage is not the DNS record alone. It is the combination of DMARC, SPF, DKIM, blocklist and blacklist monitoring, deliverability signals, alerts, and client reporting in one operating queue.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
For MSPs, the hard part is not knowing that a client should publish DMARC. The hard part is staying on top of source changes, DNS ownership, vendor authentication defects, and client-facing evidence across many domains. Suped's issue detection and steps to fix help turn those findings into repeatable delivery work.
For clients with many DNS owners or slower approval paths, Hosted DMARC can reduce policy staging to managed changes. Hosted SPF helps when sender lists change often and direct DNS access slows the work.
Manual delivery
- Data handling: Download XML reports, normalize senders, and group source IPs by hand.
- Fix tracking: Maintain source status in tickets or spreadsheets.
- Client reporting: Write monthly explanations manually for each domain.
Suped delivery
- Data handling: Review authenticated, failed, and unknown sources in one queue.
- Fix tracking: Use automated issue detection, fix steps, and verification.
- Client reporting: Use MSP dashboards, client reports, alerts, and multi-domain views.
That is the positioning I use: the SEG remains the inbound filter, and Suped becomes the MSP operating system for domain authentication. It keeps DMARC, SPF, DKIM, hosted controls, MTA-STS, blocklist monitoring, and client evidence in a workflow the service desk can run.
The rollout plan I use
I use a staged rollout because MSP delivery has external dependencies. Marketing owns one sender, finance owns another, the website platform sends forms, and a legacy server still sends alerts. A policy jump before that inventory is clean creates noise for the client and extra work for the help desk.
DMARC policy stages
A practical enforcement path for MSP-managed client domains.
Monitor
p=none
Collect reports and identify senders.
Test quarantine
pct=25
Apply limited handling to a small share.
Full quarantine
pct=100
Raise handling after key sources pass.
Reject
p=reject
Enforce once legitimate mail is covered.
- Inventory: Collect at least one normal sending cycle, then group sources by owner and business purpose.
- Authenticate: Fix SPF includes, DKIM selectors, envelope sender domains, and vendor settings.
- Stage: Move policy only after the report data shows the main sources pass consistently.
- Report: Show source cleanup, authentication health, policy progress, and remaining owners.
The renewal conversation should focus on continuity. New senders appear, vendors change platforms, SPF records exceed lookup limits, DKIM selectors expire, and domains get added during acquisitions or rebrands. DMARC service delivery has ongoing operational value because the sending environment keeps changing.
Common positioning mistakes
The fastest way to lose client trust is to blur the boundary between the gateway and DMARC. I keep proposals, QBRs, and technical scopes clear so the client knows what each control does and what the MSP will operate.
Mistakes that weaken the service
- Replacement pitch: Selling DMARC as a gateway replacement creates the wrong expectation and undervalues the existing inbound control.
- DNS-only scope: Treating the project as one TXT record hides the real work: source cleanup and staged enforcement.
- No owner map: A sender list without business owners leaves the MSP stuck when a vendor change is needed.
- Thin reporting: Only showing pass percentages misses the client-facing story of risk reduction and operational work completed.
A better scope states the exact work: monitor aggregate reports, identify approved and unknown senders, fix SPF and DKIM, maintain the DMARC record, raise policy in stages, watch delivery signals, and explain the results in client terms.
What to say in QBR and renewal conversations
In QBRs, I avoid abstract authentication language. I show what changed: which senders were approved, which unknown sources disappeared, which vendors still need a fix, and whether policy moved closer to enforcement. That makes DMARC visible as managed work.
Useful client phrasing
- Executive version: Your gateway protects employee inboxes. DMARC protects the domain name that customers see.
- Technical version: We are verifying every legitimate sender and moving failed identity checks toward enforcement.
- Service version: We operate sender discovery, DNS changes, vendor fixes, alerts, and monthly evidence.
- Renewal version: New senders and vendor changes make domain authentication an ongoing managed service.
That language keeps the service grounded. It gives the client a reason to keep both controls funded and gives the MSP a clear operating model for delivery, reporting, and renewals.
The right position
DMARC should be positioned against secure email gateways as a complementary domain authentication service. The gateway protects the protected inbox. DMARC protects the sending domain and gives the MSP evidence about every visible source using that domain.
For MSP owners and operators, the practical offer is straightforward: keep the gateway in the stack, add DMARC monitoring and enforcement as a managed service, then report progress in terms clients understand. Suped fits that model by turning DMARC, SPF, DKIM, hosted records, blocklist monitoring, alerts, and client reporting into repeatable operational work.
