How to position DMARC against secure email gateways
Published 15 Jun 2026
Updated 22 Oct 2026
13 min read
Summarize with
Updated on 22 Oct 2026: We clarified DMARC and gateway responsibilities, reporting limits, and the checks needed before enforcement.
DMARC and a secure email gateway are complementary email security controls. An inbound secure email gateway filters messages as they enter the protected mail path. DMARC checks whether a message using the client's visible From domain has a matching SPF-authenticated or DKIM-authenticated identity, then exposes the domain owner's requested handling policy to participating receivers.
For an MSP, that difference matters because the service scope and remediation evidence are separate. The gateway protects inboxes that route through it. DMARC helps participating receivers detect unauthorized use of the client's visible From domain, including mail sent to customers, vendors, partners, and public recipients outside the tenant protected by the gateway.
In client conversations, keep the gateway as inbound content defense and position DMARC as domain identity control, source discovery, policy enforcement, and reporting. 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 a requested handling policy in DNS and requests authentication reports.
- 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 inbound SEGs solve different problems
The confusion usually starts because both controls sit under email security. That label is accurate, but the control planes differ. An inbound gateway makes decisions inside the client mail flow. DMARC makes a domain owner's requested policy visible to receivers that check mail claiming to use the client's domain.
Inbound secure email gateway
An inbound 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. Many gateways also check incoming SPF, DKIM, and DMARC, then use the sender's policy alongside local filtering rules.
- 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 requests aggregate reports. Those reports summarize sources observed by reporting receivers, whether SPF or DKIM passes with the required domain match, and the reported DMARC disposition.
- Scope: Domain usage observed by participating reporting receivers.
- Signals: SPF result, DKIM result, domain match, source IP, and volume.
- MSP work: Source inventory, DNS remediation, policy staging, and reporting.
A DMARC pass confirms the required domain match. It does not prove that the message is harmless or that the sending account is uncompromised. The gateway or integrated cloud email security (ICES) layer still needs content and behavior controls for authenticated abuse.
Email security policy screen with inbound filtering and quarantine controls.
Email security policy screens show settings such as scanning rules and quarantine actions. Some API-connected ICES deployments also detect and remediate messages after delivery. These inbox controls operate separately from publishing a DMARC policy in DNS, even when one provider supplies both services.
When an inline gateway sits before the mailbox platform, configure the downstream authentication checks to recover the original sender IP through the platform's trusted connector settings. Verify the MX route and restrict direct delivery to prevent a gateway bypass.
Where DMARC protection and reporting stop
DMARC enforcement reduces direct domain spoofing when receivers apply the published policy. It does not stop display-name impersonation, lookalike domains, or business email compromise (BEC) through an authenticated account. Retain gateway content checks and account protections for those threats.
Aggregate reports summarize authentication at reporting receivers. They usually arrive daily, do not cover every receiver, and do not prove inbox placement. RFC 9990 defines the aggregate reporting format; use the reported disposition alongside gateway logs and external delivery tests.
- A monitoring policy requests no DMARC-based quarantine or rejection. Receivers still apply their own spam and security filters.
- A reported disposition of 'none' is not proof that a message reached the inbox or passed every gateway check.
- Unknown sources need investigation. Separate forwarding and configuration faults from confirmed unauthorized sending before reporting blocked attacks.
- Report client-domain authentication separately from gateway threat detections, and state which receivers and reporting periods the evidence covers.
Where outbound gateways affect DMARC
Some secure email gateways also process outbound mail, relay application messages, modify content, or add DKIM signatures. In that role, gateway configuration becomes part of DMARC remediation. DMARC still remains the domain owner's internet-facing policy and reporting layer.
- SPF path: Authorize the gateway's external sending addresses in the SPF record for the envelope sender (Return-Path) domain, and configure that domain to meet DMARC's match requirement with the visible From domain.
- DKIM preservation: A footer or other content change can invalidate an earlier signature. Sign after the content-changing hop using a DKIM d= domain that meets DMARC's match requirement, or preserve an existing valid signature before external delivery.
- DMARC result: A receiver records a pass when at least one passing SPF or DKIM identity has the required domain match. A pass shown before the gateway is not final proof.
- ICES boundary: API-based mailbox controls can act after delivery. Managing SPF or DKIM for outbound mail remains a separate task unless the service also handles sending or DNS configuration.
Verify the full outbound route
Send a controlled message through the complete production route to an outside mailbox, then inspect the receiver's Authentication-Results header. Use that receiver-side result as the evidence for source approval.
How to explain the service boundary to clients
For MSP service packaging, keep the explanation practical: the gateway filters inbox traffic, while DMARC adds domain authentication at participating receivers outside that inbox. 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 does not cover this work, explain that an inbound gateway sees traffic routed through it. External senders such as billing tools and marketing platforms still need their own SPF and DKIM configuration. DMARC reporting helps build the sender inventory; confirm it against the client's application list and vendor owners.
|
|
|
|---|---|---|
We already have a SEG | The SEG filters inbox traffic. DMARC adds domain authentication at outside receivers. | 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 | A lack of complaints does not verify sender authentication. | Review source ownership and authentication failures. |
Common client objections and the MSP response
Suped's DMARC monitoring workflow turns aggregate reports into source lists, authentication pass rates, report history, and alerts. Use those findings to assign business owners and remediation tasks in the MSP's ticketing process.
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 tells participating receivers your preferred handling for mail that fails authentication for your domain.
- Avoid this: Your gateway is incomplete, so you need another tool.
- Close with: The service outcome is verified senders, cleaner DNS, a staged enforcement path, and monthly evidence.
How MSPs deploy DMARC alongside a gateway
The delivery model needs ongoing MSP ownership. Break the work into discovery, authentication fixes, policy staging, enforcement, and reporting. Each phase needs a clear owner and evidence.
MSP DMARC rollout flowchart covering report collection, sender authentication, policy staging, and reporting.
For a domain without verified enforcement, start with p=none, because the MSP needs data before enforcement. Preserve an existing working enforcement policy while reviewing its coverage. Use reporting to separate legitimate SaaS senders, broken DKIM, SPF lookup issues, forwarded mail behavior, and noise.
Starter DMARC TXT value at _dmarc.example.comDNS
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Publish a single DMARC policy at _dmarc.example.com, replacing example.com and the report mailbox with the client's actual values. If reports go to a different organization's domain, confirm that the destination's DNS owner has authorized reporting. Google's setup guidance also covers report destinations and DNS publication.
RFC 9989 defines DMARC; RFC 9990 defines aggregate reports and RFC 9991 defines failure reports. The pct tag is historic. On supporting receivers, t=y requests handling one level below the published policy: p=quarantine; t=y requests no DMARC enforcement, while p=reject; t=y requests quarantine. Receivers that do not recognize t=y ignore it and use the published policy, so test mode is not a safeguard for unprepared senders.
Before raising policy, 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.
Do not rush the visible policy tag. Prove that legitimate mail survives stricter handling. Before reject, require valid DKIM signatures with the right domain match for every active legitimate sender, and test forwarding and mailing-list paths. SPF alone is insufficient for reject because forwarding changes the connecting IP.
Successive policy examples, publish one at a timeDNS
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; t=y v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com
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, quarantine, then reject after receiver-side verification. Use optional test mode only after confirming receiver behavior.
- Rollback path: Keep DNS ownership, change approvals, and vendor contacts visible before enforcement.
How Suped fits the MSP workflow
Suped is our DMARC and email authentication platform for MSP delivery teams. Use its source classification and issue detection to prioritize vendor authentication fixes across client domains.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
For MSPs, publishing DMARC starts the work. Ongoing delivery covers source changes, DNS ownership, vendor authentication defects, and client-facing evidence across many domains.
For clients with many DNS owners or slower approval paths, Hosted DMARC lets the MSP manage policy after an initial DNS delegation. 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.
The service boundary remains clear: the SEG handles inbound filtering, while Suped organizes MSP domain-authentication work. Keep gateway incidents and sender remediation in separate ticket categories so each team has clear ownership.
A practical DMARC rollout plan
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 staged path for MSP-managed client domains; test mode requires verified receiver support.
Monitor
p=none
Collect reports and identify senders.
Optional test mode
p=quarantine; t=y
Supporting receivers use no enforcement for quarantine plus t=y, or quarantine for reject plus t=y.
Quarantine
p=quarantine
Request quarantine after legitimate senders are verified.
Reject
p=reject
Request rejection after every active legitimate sender has verified DKIM and indirect paths are tested.
- Inventory: Collect a full normal sending cycle, including monthly or low-volume mail, then group sources by owner and business purpose. Review sending subdomains and unused domains separately.
- Authenticate: Fix SPF includes, DKIM selectors, envelope sender domains, and vendor settings.
- Stage: Move policy only after report data and external tests cover all active legitimate senders. Verify each subdomain's effective policy and explicit overrides before enforcement.
- 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 keys rotate or DNS records disappear, 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. Keep proposals and quarterly business reviews (QBRs) 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, avoid abstract authentication language. Show what changed: which senders were approved, which previously unknown sources were classified, which vendors still need a fix, and whether policy moved closer to enforcement. Report the legitimate-sender pass rate separately from all observed traffic, since spoofed volume distorts a combined percentage.
Useful client phrasing
- Executive version: Your gateway protects employee inboxes. DMARC helps outside receivers identify unauthorized mail using your domain.
- 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, support, and renewals.
Position DMARC as a complementary control
DMARC should be positioned alongside secure email gateways as a complementary domain authentication service. The inbound gateway protects the configured inbox. DMARC reduces direct domain spoofing at participating receivers and gives the MSP evidence about reported sources using that domain.
Frequently asked questions
No. A secure email gateway filters inbound mail for the protected environment. DMARC publishes the domain owner's requested handling for messages that fail the required authentication and domain-match checks. Outside receivers decide how to apply that request.
Yes. A gateway can check the sender domain's DMARC policy and use the result alongside local filtering rules. Publishing and managing the client's own DMARC record is a separate responsibility, even when one provider supplies both services. If the gateway also relays outbound mail, include its sending addresses and content changes in the SPF and DKIM design.
For a domain without established enforcement, start with p=none to discover sources before tightening policy. Keep an existing working enforcement policy while checking coverage. Test quarantine before reject, require valid DKIM for active legitimate senders, and verify forwarding paths. Treat t=y as optional testing with receiver-dependent support, rather than protection against delivery failures.
SPF cleanup happens during source remediation. The MSP should remove stale senders, fix includes, watch lookup limits, and configure the envelope sender domain correctly. Enable DKIM for each active legitimate sender before reject because SPF is fragile through forwarding.
Show approved senders, resolved source investigations, legitimate-sender authentication pass rates, policy progress, and open vendor fixes. Use gateway logs for inbound threat detections and separate delivery evidence for inbox placement; aggregate reports alone do not prove either outcome.
