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.
DMARCS streams 24 event types into FortiSIEM as native events, with severity scores and MITRE ATT&CK mappings, so email authentication and brand protection sit inside the same detection…
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…
Tell us where your domains stand today and we will take it from there.
