If your SOC lives in FortiSIEM, DMARCS has probably been the one console your analysts have to leave it for. A DMARC policy gets quietly downgraded, a lookalike domain starts sending mail, a sender IP shows up on a malware feed, and none of it reaches the SIEM unless someone remembers to check DMARCS separately.
That gap is closed. The DMARCS FortiSIEM integration streams DMARCS activity straight into FortiSIEM as native events, so email authentication and brand protection sit inside the same detection and response workflow as everything else you monitor.
DMARCS sends 24 distinct event types into FortiSIEM, grouped into four tiers:
Every event carries a severity score and a MITRE ATT&CK mapping, so it lands in FortiSIEM’s existing views the same way any other vendor’s events do. Your analysts aren’t learning a new taxonomy. A DMARC failure spike shows up next to a firewall alert with the same fields your rules and dashboards already expect.
This is a real DMARC SIEM feed, not a summary or a digest. Individual events, in near real time, with the detail an analyst needs to actually triage rather than just get notified.
Once the events are in FortiSIEM, correlation does the rest. We’ve built and validated 24 correlation rules against this event set, and they catch the patterns that matter:
p=reject back to p=none or p=quarantineEach of these fires as a FortiSIEM incident, not a DMARCS notification you have to go check for. That’s the actual point of this integration: DMARC and email authentication events become part of the same correlation logic your SIEM already runs against the rest of your environment.
One pane of glass, genuinely. Without this, an analyst working an incident has to remember DMARCS exists, log into a second console, and manually cross-reference timestamps against what FortiSIEM already showed them. With the DMARCS FortiSIEM integration, that step disappears. Email authentication failures, brand impersonation attempts, and DNS-level policy changes get investigated the same way as any other alert in the queue, in the same tool, by the same people, without the swivel-chair.
For MSSPs and internal SOC teams running FortiSIEM as their primary detection platform, this is what email security SIEM integration should look like: no separate login, no separate escalation path. No gap where an attacker banks on nobody checking a second dashboard.
The integration is live and running in production today. Right now it’s enabled per customer through a lightweight connector deployed on your FortiSIEM collector, pulling your org’s DMARCS events on a short interval and forwarding them into the parser we’ve built and validated. Setup takes about five minutes once your DMARCS API key is scoped for it.
We’re also working with Fortinet directly on an official native connector so this ships as a built-in integration rather than a collector-side add-on. That’s in progress; the current connector already gives you the full event set and rule set today.
If you’re running FortiSIEM and want your DMARCS activity in it, reach out and we’ll get it enabled on your account.
A decade ago, publishing a DMARC record at p=reject gave you uneven protection. Major providers checked it, but enforcement across the wider mail ecosystem was inconsistent: some receivers honoured the policy as written, plenty didn’t check it at all, and a corporate mail server buried somewhere in a regional provider’s infrastructure might do something completely different from the one next to it. An attacker spoofing your domain still had somewhere to land.
That’s changed, and not because DMARC got better. The mail world got smaller instead.
But infrastructure and visibility are two different problems, and they’re moving at two different speeds. The receiving side of email has consolidated. What a security team can actually see happening on that infrastructure hasn’t kept pace.
How much smaller depends on who’s counting. Internet Society’s Pulse blog, drawing on OpenINTEL’s daily DNS scan of the Tranco top-million domains, put Google Workspace at 21.8% and Microsoft 365 at 16.8%, for a combined 38.6% of measured mailbox infrastructure in 2026. ReplyLead’s 2026 analysis of 9,058,780 domains with a usable MX record put the combined figure at 54.32%, with 6.45% sitting behind a secure email gateway and 14.8% still self-hosted.
The gap is largely a measurement problem. The two studies use different domain populations and methodologies, so neither number should be treated as a definitive share of global business email.
What they do agree on is the direction: email hosting has consolidated significantly, while self-hosted mail has declined. Internet Society’s longer view has self-hosting falling from 44.6% of domains a decade ago to 22.4% today, and the domains that left didn’t all land in the same place. Some went to Google Workspace or Microsoft 365. Others went to a different hosted provider, a secure gateway, or another cloud platform entirely.
Real consolidation, then. Just not the “virtually everyone” story the marketing decks tell.
Here’s the piece that gets lost in any version of the domain-count story: for the recipients an attacker actually wants to reach, a third system often makes the first call, and it’s a system whose behaviour doesn’t show up in a domain-share table at all.
Allegrow’s 2026 census of every Fortune 500 domain found 55% sitting behind a secure email gateway before the message ever reaches the underlying mailbox, with Proofpoint alone accounting for 80% of those gateways. Microsoft 365 was the mailbox platform behind 82% of the Fortune 500 domains in the study. It just wasn’t the system doing the filtering on most of them.
So “two companies decide what happens to your mail” is accurate for a lot of the addressable world: small and mid-size businesses running natively on Google Workspace or Microsoft 365, and the personal Gmail and Outlook.com inboxes both companies’ bulk sender rules explicitly target. It’s less accurate for your highest-value enterprise recipients, where the gateway in front of the mailbox is often the one setting the terms, and often the one deciding what you get to see afterwards.
That first layer, the one without a gateway in front of it, is still where the enforcement teeth are, and it’s where both companies have put real deadlines behind their policies.
Google began enforcing its sender requirements in February 2024. For bulk senders, that means SPF, DKIM, and DMARC, along with additional requirements around DNS, TLS, spam rates, and unsubscribe handling.
Microsoft followed on 2 April 2025, introducing similar authentication requirements for domains sending 5,000 or more messages a day to Outlook.com and related consumer services. Non-compliant high-volume mail can be rejected with 550 5.7.515. Not a spam-folder placement. A hard rejection, generated by one of the two platforms actually receiving the mail that never passes through a gateway first.
A secure email gateway sitting in front of a mailbox isn’t a reason to skip authentication. It adds another layer of filtering, while authentication still plays its part in how the receiving infrastructure evaluates the message either way. An unauthenticated domain that might have slipped past a lenient corporate mail server a decade ago now has two separate systems checking it: whatever the gateway does with the message, and the DMARC policy the domain owner did or didn’t publish.
None of that makes the visibility any cleaner. This is where the two halves of the story actually meet.
Microsoft’s own documentation confirms that DMARC aggregate reports are sent only when a domain’s MX record points directly to Microsoft 365, rather than when a gateway or hybrid routing sits in front. Microsoft doesn’t send forensic reports. Google and Yahoo both provide DMARC aggregate reporting, but no receiver is obligated to send reports, and plenty of the long tail never will.
So what lands in your inbox never reflects every message to every recipient. It reflects whichever receivers, out of an increasingly consolidated but still incomplete set, chose to tell you what happened.
The receiving infrastructure is becoming concentrated. The visibility into that infrastructure isn’t.
That incomplete picture is still better than the alternative: waiting for a complete one before doing anything. It’ll never arrive. Some receivers will always skip reporting, gateways will keep suppressing what Microsoft would otherwise send, and the long tail of smaller providers was never built to standardise.
None of that changes what p=none actually does: it gives you visibility, not enforcement. The protection against unauthorised use of your domain starts when you move to p=quarantine or p=reject, and that’s where most teams stall, because nobody wants to be the one who breaks a legitimate sender nobody remembered still existed.
DMARCS helps you identify the systems sending from your domain, see where SPF, DKIM and DMARC are failing, and move from p=none to p=reject with the visibility to do it safely.
Somewhere in your organisation there are 40 domains nobody remembers registering. A regional office bought one for a campaign in 2019. Marketing parked another for a product that never shipped. Someone in procurement grabbed a lookalike of your own brand just to keep it out of a squatter’s hands. Every one of them can send email. Every one of them needs a DMARC record, or it is a gap an attacker can walk through.
Now multiply that by the domains you actually use on purpose: regional TLDs, subsidiary brands, acquisitions still running their own mail, dozens of subdomains for marketing tools, ticketing systems, and transactional email. Enterprises and the MSPs who manage them routinely land in the hundreds. At that scale, “check the DMARC record” stops being a task you do and becomes a program you run.
DMARC for one domain is a weekend project. Pull the mail flow, publish p=none , watch the aggregate reports for a few weeks, tighten to quarantine , then reject . Painful in places, but linear.
At 200 domains, three things happen at once:
The report volume becomes unreadable by hand. Each domain with a rua= tag generates its own aggregate XML report from every major receiver, daily. Two hundred domains means thousands of files a week, and the useful signal, an unauthorised source spoofing one specific subsidiary, is buried in noise from domains that barely send mail at all.
Domains drift out of sync silently. One team rotates a mail vendor and forgets to update SPF. Another lets a domain’s DKIM key expire. A marketing subdomain gets provisioned for a campaign and never gets a DMARC record at all, because nobody owns “new subdomain checklist” across 15 business units. Six months later you find out not from a dashboard but from a phishing report.
Nobody agrees on who is responsible for what. Central security owns the policy standard. Regional IT owns the DNS. Marketing owns the campaign tools sending the mail. When SPF breaks a legitimate newsletter, the ticket bounces between three teams before anyone touches the actual TXT record.
Manual tracking, usually a spreadsheet someone maintains part-time, cannot keep up with any of this. By the time an entry is updated, the DNS has already changed again.
Most inventories used for DMARC rollout are built from the domain registrar list and the corporate DNS zone. That misses shadow domains bought outside procurement, subsidiaries from acquisitions still on their own registrar, and subdomains created by SaaS tools that get their own MX or SPF include without anyone in IT knowing.
Before setting policy anywhere, you need three things confirmed per domain: who owns it, what currently sends mail from it (including SaaS tools), and whether it sends mail at all. A domain with zero legitimate mail traffic should go straight to p=reject immediately. There is no rollout risk in blocking mail from a domain nobody uses to send.
DMARCS keeps this at the domain and subdomain level in one place, which matters once “check the DNS” stops being a single query and becomes 200 of them. Domain Health gives each one a posture score instead of making you open the zone file to guess.
A spreadsheet sorted by domain name tells you nothing about what to do next. Group by what actually determines the plan:
Policy Manager is built for exactly this: one view of every domain’s current policy stage, so a security lead can see at a glance which of 200 domains are still sitting at p=none for no good reason, and which are genuinely blocked on a vendor fix.
SPF allows 10 DNS lookups per record. One domain with Microsoft 365, one CRM, and a support tool stays under that easily. A domain shared across regional marketing, a global CRM, three transactional email providers, and a helpdesk blows past it fast, and once it does, SPF returns a PermError and the receiver can treat the entire domain as unauthenticated, including your legitimate mail.
Across hundreds of domains this is not a one-time fix, it is a recurring failure mode every time a business unit adds a new sender. Smart SPF flattens the record automatically as senders get added, so the limit stops being something someone has to track by hand across every domain in the portfolio.
Manually opening RUA files for 200 domains does not scale, and forensic (RUF) data on top of that is worse. What you actually need is a single answer to two questions across the whole portfolio: which sources are sending as any of my domains right now, and which of those are failing authentication.
Reports Hub consolidates aggregate reports across every domain into one readable view, so a source spoofing a rarely-used subsidiary domain surfaces the same way a source hitting your main brand domain would, instead of sitting unread in a report nobody opened.
At scale, most of the domains sending mail on your behalf are not sending it directly. They’re going through a CRM, a marketing platform, a helpdesk, an HR system, a dozen SaaS tools each business unit picked independently. Every one of those is a third party authorised, deliberately or by accident, to send as your domain.
The question that matters is not “is our DMARC record correct” but “do we actually know every vendor sending as us, and is each one properly aligned.” Vendor Risk surfaces exactly that: the third parties sending on the organisation’s behalf, and which ones are doing it with weak or missing authentication. For an MSP managing client portfolios, this is often the single most useful view, because clients rarely know the full list of tools sending as their own domain.
A parent domain at p=reject looks solid on paper. But DMARC’s subdomain policy ( sp= ) inherits from the parent unless explicitly overridden, and a huge share of real-world spoofing happens through unmonitored subdomains: a marketing subdomain spun up for one campaign, a dormant staging subdomain from a project that shipped two years ago, a subdomain nobody remembers exists at all. Attackers know this and target exactly those gaps.
Subdomain Monitor and SubdoMailing Guard track this across the whole domain tree, catching the subdomain that got created without anyone adding it to the DMARC rollout plan, rather than relying on someone remembering to check.
Not a spreadsheet, and not 200 separate manual reviews. One dashboard showing every domain’s policy stage, every subdomain under it, every third-party sender authorised across the whole portfolio, and an ongoing feed of new sources so nothing drifts unnoticed between reviews. New domains get triaged into the risk groups above the day they’re registered, not six months later when a report happens to surface them. Enforcement moves domain by domain on its own schedule, driven by actual RUA data for that domain, not a blanket policy applied to everything at once regardless of readiness.
That is the difference between DMARC as a checkbox on one domain and DMARC as an actual security control across an entire portfolio. Run your primary domain through the free DMARC Analyzer first if you haven’t already, then start a trial and bring in the rest of the list, all of it, including the domains you’d forgotten you owned.
The question comes up constantly in IT forums, sysadmin Slack channels, and support tickets: “We’ve been on p=quarantine for months. Is it safe to move to p=reject yet?”
The honest answer is: it depends on what your aggregate reports are telling you. And most organisations are not reading them closely enough to know.
This is not a knock on IT teams. DMARC reports are dense XML files that were designed for machines, not humans. But the consequence of ignoring them is staying parked at quarantine indefinitely, under the assumption that something might break if you move forward. What organisations do not always consider is what continues to break while they wait: spoofed emails hitting their customers’ inboxes, brand impersonation going unchecked, and an increasingly thin justification as mailbox providers tighten enforcement.
As of Q2 2025, only around 4% of the world’s ten million most-visited domains have a fully enforced reject policy. More than half of all domains that have DMARC records at all are sitting at p=none. That is a significant gap between awareness and actual protection, and it matters more now than it did two years ago.
When DMARC was designed, the policy progression was intentional: start at none to gather data, move to quarantine to test enforcement with some safety margin, then advance to reject once you are confident in your mail flows. Quarantine was a proving ground, not a permanent home.
The reason organisations stall there is understandable. Reject is unforgiving. A message that fails DMARC under a reject policy is gone; it does not land in spam, it does not get reviewed by an admin, it simply does not arrive. That consequence feels heavy when you are not entirely sure every legitimate sender has been accounted for. A missed Salesforce subdomain, a payroll platform that was set up quietly by HR, an external agency sending campaign emails under your brand domain. Any of these can become a false positive under strict enforcement if they were never properly aligned.
So teams stay at quarantine. Months pass. The reports pile up in an inbox somewhere.
What is often not appreciated is that quarantine has its own failure mode. A failed message under quarantine does not disappear; it lands in spam, which means your customers might still read it, your recipients might still click it, and your domain still gets associated with junk. The impact on legitimate but non-compliant email can go unnoticed for long periods because the source never gets a hard bounce. Deliverability quietly degrades while no one is looking.
There is also a compliance dimension that did not exist a few years ago. As of 2025, DMARC is mandatory under PCI DSS v4.0 for organisations processing payment card data, and CISA BOD 18-01 requires p=reject for US federal domains. Microsoft began rejecting non-compliant email from high-volume senders in May 2025, joining Google and Yahoo who enforced the same requirements in 2024. Cyber insurance underwriters are now asking about DMARC policy levels during renewals. Staying at quarantine is a defensible starting point; staying there for two years is harder to justify.
The decision to move from quarantine to reject should be driven by data, not confidence. Confidence can be wrong. Data tells you where the gaps are.
Before making the switch, your aggregate reports need to show a clear picture across three dimensions.
Source coverage: Every IP address that sends email as your domain needs to be identified and either authorised or flagged as illegitimate. Look for sources that appear inconsistently: once a month, quarterly, during campaign periods only. These are the senders that get missed during initial audits because they are not active when you are looking. A minimum of 90 days of monitoring data is generally recommended before enforcing, specifically to catch monthly senders like invoicing systems, quarterly report distributions, and seasonal campaigns.
Alignment rate: Your aggregate reports will show you what percentage of mail from each identified source is passing SPF or DKIM alignment. Any legitimate source consistently failing alignment needs to be fixed before you flip to reject, not after. The fix is usually straightforward: adding the sending service’s domain to your SPF record, enabling custom DKIM signing in the platform, or updating the From header configuration. But it must happen first.
Subdomain behaviour: This is where many organisations make their most expensive mistake. If you set p=reject on your parent domain but leave subdomains unaddressed, attackers can continue spoofing subdomains instead. The sp tag controls subdomain policy separately and needs to be considered explicitly. A common and sensible configuration is to run p=reject on your primary domain while keeping sp=quarantine on subdomains during a transition period, especially if different teams manage different subdomains with different sending patterns.
Most organisations treat the jump from quarantine to reject as a binary switch. It does not have to be.
The pct tag in a DMARC record lets you apply your enforcement policy to a specified percentage of failing messages. At pct=20 with p=reject, only 20% of messages that fail DMARC will be rejected; the rest fall back to quarantine. This gives you a controlled ramp-up where the consequences of any misconfiguration are limited.
The practical sequence looks like this: move to p=reject with pct=10, watch your reports for a week, increase to pct=25, watch again, then 50, then 100. Most well-prepared domains will see nothing alarming across that progression. The ones that do catch something will catch it at pct=10 rather than at pct=100, which is a considerably better place to find a problem.
This approach is particularly useful in large organisations with multiple business units, inherited domains from acquisitions, or complex third-party sender relationships. The pct ramp costs you almost nothing in complexity and buys you real insurance against the blind spots in your source inventory.
Even with thorough preparation, some organisations will see legitimate mail fail under p=reject. The question is what to do about it.
The most common culprits are email forwarding and mailing lists. When email is forwarded, SPF alignment often breaks because the forwarding server is not in your SPF record. DKIM can also be invalidated if the forwarding host modifies the message body or certain headers. This is a known limitation of the current authentication infrastructure, and it is one of the problems that ARC (Authenticated Received Chain) was designed to address. If your organisation has significant inbound forwarding flows, particularly from partner organisations, distribution lists, or government recipients, this is worth investigating before you move to reject.
Mailing list behaviour is related. Many list management systems rewrite the From address or add footers that break DKIM signatures. The standard guidance is to ensure your outbound mail to these systems uses a domain that either supports DKIM re-signing or routes through an ARC-aware infrastructure.
None of these are reasons to stay at quarantine permanently. They are reasons to be specific about what you are fixing before you proceed. A broken forwarding path is a solvable problem. An unsolved forwarding path at p=reject is a deliverability incident.
There is a broader shift happening in how DMARC policy levels are being treated by the industry. What was once a recommendation from security practitioners has become a hard requirement from infrastructure providers and regulators.
In May 2025, Microsoft began rejecting emails from high-volume senders that fail authentication, returning error 550 5.7.515 to non-compliant domains. Google and Yahoo implemented equivalent enforcement in February 2024. The three largest mailbox providers now all require authentication for bulk senders. If your domain is still at p=none, you are already behind. If you are at quarantine, you are compliant with the baseline, but you are not protected.
The data on enforcement outcomes makes this concrete. In the US, where government DMARC mandates exist, the percentage of phishing emails successfully reaching inboxes dropped from 68.8% in 2023 to 14.2% in 2025. In Qatar, where enforcement guidance is minimal, phishing exposure remained essentially unchanged over the same period. The difference is not the quality of the threat actors. It is the enforcement policy.
For organisations in the UAE and broader GCC, this context carries particular weight. The DESC (Dubai Electronic Security Centre) and national cybersecurity frameworks increasingly align with international best practices on email authentication. Financial institutions, government contractors, and enterprises handling sensitive customer data face a narrowing window before these requirements become mandatory rather than recommended.
If you are trying to decide whether your domain is ready to move from quarantine to reject, the following questions will help you make a defensible case either way.
Have you been actively reading your aggregate reports for at least 90 days? If the honest answer is no, that is your first task, not your policy setting.
Are all sources sending above a meaningful volume threshold identified and documented? Shadow senders are the most common cause of false positives under reject. If you have not used a reporting platform to build a complete sender inventory, do that before you change your policy.
Is the alignment pass rate for your known legitimate senders consistently above 95%? If any legitimate source is failing regularly, fix the source. Do not move to reject with known alignment failures outstanding.
Have you considered the sp tag and made an explicit decision about subdomain policy? If you have not touched sp, moving the parent domain to reject may leave your subdomains exposed to continued spoofing.
If you can answer yes to all of these, your domain is ready. Use pct to ramp gradually, monitor your reports through the ramp, and move to pct=100 once you have confirmed there are no surprises.
There are two failure modes here, and they do not get equal attention. Most teams worry about the consequences of moving to reject too quickly and blocking legitimate mail. That is a real risk and a valid concern. But the consequences of staying at quarantine too long are just as real, and they are less visible.
Business Email Compromise losses reached $3.05 billion in 2025 according to the FBI’s IC3, making it the most financially damaging enterprise-targeted cybercrime for yet another consecutive year. The majority of BEC attacks exploit the trust that recipients place in sender identity. A domain at p=quarantine cannot stop an attacker from spoofing that domain. The message will reach the recipient’s spam folder. In a business context where people are under pressure and scanning quickly, that distinction matters less than it should.
A phishing email that lands in junk is not a phishing email that was stopped. It is a phishing email that arrived.
DMARCS gives you the aggregate report visibility you need to make this decision with confidence rather than instinct. Our dashboard translates raw XML data into a clear sender inventory, alignment scores by source, and a readiness assessment that shows you exactly what needs to be resolved before moving to enforce. If you are managing a domain in the UAE or GCC and want a clear view of where you stand before making a policy change, the dmarc analyser is a reasonable starting point.
Most organisations believe they understand their email infrastructure. They know their main mail provider, the platform used for newsletters, and the systems responsible for internal alerts. But email environments rarely stay simple.
Over time different teams introduce software that sends messages using the organisation’s domain. Marketing launches campaign platforms. HR uses recruitment software that sends interview invitations. Support teams deploy helpdesk systems that email ticket updates. Developers integrate applications that generate password resets, alerts, and verification codes.
Each of these services is configured to send email using the company’s domain so messages appear legitimate to recipients.
In most cases the setup requires only a few DNS changes. A platform might ask for an SPF include entry or request DKIM signing for the domain. Because these changes are easy to implement, new sending services are often added without central review.
After a few years the number of systems sending email can grow far beyond what anyone expected. This is what we call the shadow email problem , a collection of services that send messages using your domain without central tracking or visibility.
Shadow email creates several real risks:
Before these issues can be fixed, the first step is identifying every service sending email from your domain . DMARCS was built specifically to give organisations this visibility.
The process begins by adding your domain inside DMARCS.
Navigate to:
Settings → Domains → Add Domain
When a domain is added, DMARCS provides a verification TXT record that must be placed in your DNS configuration. This confirms that you control the domain.
After the DNS record is added, click Verify in the dashboard.
Once the domain is verified, DMARCS begins analysing your email authentication configuration. This includes:
As soon as your DMARC record is active, receiving mail providers begin sending DMARC reports. These reports contain detailed information about messages that claim to originate from your domain.
Within a short time DMARCS starts building a complete picture of your domain’s sending activity.
The easiest way to see who is sending email from your domain is the Sending Sources view inside the Intelligence Hub.
This view aggregates DMARC report data and groups it into identifiable sending sources.
Instead of raw XML reports, you see structured information about every server sending messages as your domain.
For each source DMARCS shows:
Because this information comes from receiving mail servers across the internet, it reflects actual email traffic , not just DNS configuration.
Many organisations are surprised by what appears here.
It is common to discover sending sources such as:
Over time the Sending Sources view becomes a clear inventory of every service sending email using your domain.
Some sending sources will be immediately recognisable. Others may appear only as IP addresses or infrastructure providers.
When that happens, DMARCS provides several ways to investigate further.
Risk Explorer highlights sending sources that show unusual behaviour or authentication problems.
Examples include:
These patterns often reveal misconfigured services or potential spoofing attempts.
Investigating high-risk sources first helps security teams quickly identify problems.
Forensic reports provide detailed information about individual messages that failed authentication.
These reports include:
This makes it easier to determine whether a sender is a legitimate service that needs configuration fixes or an unauthorised source attempting to impersonate your domain.
Sometimes the easiest way to identify a sender is by analysing the header of a specific email.
DMARCS includes a Header Analyzer tool where you can paste an email header and see how the message was authenticated.
The tool evaluates:
Email headers can be retrieved directly from your mail client.
For example:
Analysing headers often reveals which service generated the email.
Once sending sources are identified, the next step is evaluating the health of your authentication setup.
DMARCS includes several analysis tools that help identify configuration problems.
Domain Health Check performs a comprehensive scan of your domain’s email configuration.
The scan evaluates:
This provides a clear overview of how well your domain’s email authentication is configured.
SPF Surveyor focuses specifically on analysing the SPF record.
It identifies issues such as:
Many organisations accumulate complex SPF records over time as additional services are added. SPF Surveyor helps reveal how complicated the configuration has become.
DNS History tracks changes to authentication records over time.
By comparing previous and current DNS configurations you can see when new sending services were introduced and how authentication policies have evolved.
After identifying all sending sources, the next step is categorising them.
In most environments these sources fall into three groups.
These are systems actively used by the organisation.
Examples include marketing platforms, CRM systems, support tools, and application notification services.
These services should remain authorised but must pass SPF or DKIM authentication and maintain proper domain alignment.
Some legitimate platforms appear in reports with authentication failures.
Common causes include:
These issues are usually resolved by updating DNS records or adjusting platform configuration.
Many organisations discover systems that are no longer in use.
These may include:
Leaving these services authorised increases the domain’s attack surface and complicates authentication records.
Removing them simplifies the sending environment.
Most domains begin with a monitoring policy.
This allows DMARCS to collect authentication data while email continues to flow normally.
Once legitimate sending sources are identified and properly configured, you can begin enforcing your DMARC policy.
DMARCS provides the Smart DMARC tool to manage your policy settings.
Most organisations follow a gradual progression:
Some organisations also apply enforcement gradually by setting a percentage of messages affected by the policy.
Moving to enforcement protects your domain from spoofing and impersonation attacks.
Finding every service sending email from your domain is not a one-time exercise.
Organisations constantly adopt new software. Marketing teams test new engagement platforms. Developers introduce applications that send automated notifications. Business units deploy specialised systems that communicate with customers through email.
Without continuous monitoring these services slowly recreate the shadow email problem.
DMARCS continuously analyses DMARC reports to detect new sending sources as they appear. You can also configure alerts for events such as:
Regularly reviewing these signals keeps your email infrastructure visible, secure, and manageable.
When you know exactly which services are sending email from your domain, you regain control over one of the most critical communication channels your organisation relies on every day.
Most organizations deploy firewalls, antivirus, and endpoint controls. Yet they leave their email domains unprotected. Without DMARC enforcement, your domain can be spoofed by anyone, at any time, with no alert, no audit trail, and no consequence. Except to your reputation, your customers, and your bottom line.
DMARC (Domain-based Message Authentication, Reporting and Conformance) prevents attackers from sending emails that appear to come from your domain. Without it, your brand becomes a free resource for phishing campaigns, business email compromise (BEC), and invoice fraud.
Spoofing does not require access to your infrastructure. It exploits trust in your domain name. When DMARC is missing or misconfigured, threat actors use it to deliver emails that look like they came from your CEO, finance team, or support desk. These messages bypass traditional email filters because they appear to come from a legitimate domain.
BEC losses are well documented. According to the FBI IC3, global BEC-related fraud exceeded 50 billion dollars across reported cases. In nearly all of them, domain spoofing was the first step.
One spoofed invoice to the wrong customer can result in six or seven figure losses. In regulated sectors like finance and healthcare, this also brings audit failures and compliance violations.
*When your domain is used to phish third parties, such as partners, suppliers, or the public, you may not face immediate legal action. But you will face brand erosion. Trust lost in email is hard to recover.*
It is not just your customers at risk. Internal users are common targets. Executives receive spoofed emails impersonating board members. Finance teams get urgent wire requests. HR teams are tricked into sending sensitive employee data.
Data protection laws in the UAE (PDPL), Europe (GDPR), and elsewhere are increasingly clear. Organizations are expected to implement appropriate technical controls to protect communication channels. DMARC is now considered one of those basic controls.
Insurance providers are also tightening their requirements. Cyber liability policies increasingly require evidence of email authentication. Inadequate DMARC posture can result in higher premiums or denied claims after an incident.
Auditors and regulators will not accept ignorance. If your domain was used in a phishing attack and you had no DMARC enforcement or monitoring in place, the liability shifts.
Beyond security, DMARC protects your brand identity in the inbox. Major email providers use DMARC enforcement to determine whether your logo is displayed through BIMI, whether your emails are trusted, and whether they land in the inbox or the spam folder.
Without enforcement, legitimate marketing and customer support emails are more likely to be flagged, delayed, or blocked. Your deliverability suffers, and so does customer experience.
Organizations that delay DMARC often cite complexity, resource constraints, or fear of disrupting email flow. These are solvable problems. The longer you wait, the more exposed you are.
Spoofing attacks rarely make headlines. But they quietly drain trust, money, and operational resources. The clean-up cost, both financial and reputational, is always higher than prevention.
Post Tags :
Tell us where your domains stand today and we will take it from there.