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:
- attackers can attempt domain spoofing or impersonation
- misconfigured systems can damage domain reputation
- SPF records can exceed the 10 lookup limit
- legitimate email may start failing authentication checks
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.
Step 1: Add Your Domain to DMARCS
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:
- SPF records that authorise sending IP addresses
- DKIM signatures used to sign messages
- the DMARC policy that instructs receiving mail servers how to handle authentication failures
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.
Step 2: Use the Sending Sources View to See All Email Senders
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:
- the sending IP address
- the organisation associated with that IP
- SPF authentication results
- DKIM authentication results
- DMARC alignment status
- email message volume
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:
- marketing automation platforms
- CRM notification systems
- transactional email infrastructure used by applications
- support platforms sending ticket updates
- developer testing environments
Over time the Sending Sources view becomes a clear inventory of every service sending email using your domain.
Step 3: Investigate Unknown Sending Sources
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
Risk Explorer highlights sending sources that show unusual behaviour or authentication problems.
Examples include:
- high DMARC failure rates
- missing SPF authorisation
- DKIM signature failures
These patterns often reveal misconfigured services or potential spoofing attempts.
Investigating high-risk sources first helps security teams quickly identify problems.
Forensic Reports
Forensic reports provide detailed information about individual messages that failed authentication.
These reports include:
- full message headers
- the sending IP address
- authentication failure reasons
- alignment results
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.
Header Analyzer
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:
- SPF validation
- DKIM signature status
- DMARC alignment
- infrastructure involved in delivering the message
Email headers can be retrieved directly from your mail client.
For example:
- In Gmail, open the message and select Show original
- In Outlook, open the message and choose View message source
Analysing headers often reveals which service generated the email.
Step 4: Analyse Your Email Authentication Configuration
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
Domain Health Check performs a comprehensive scan of your domain’s email configuration.
The scan evaluates:
- SPF syntax and DNS lookup limits
- DKIM key validity
- DMARC policy configuration
- MX and TLS settings
This provides a clear overview of how well your domain’s email authentication is configured.
SPF Surveyor
SPF Surveyor focuses specifically on analysing the SPF record.
It identifies issues such as:
- syntax errors
- excessive DNS lookups
- unnecessary include statements
- security weaknesses
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
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.
Step 5: Organise Your Sending Sources
After identifying all sending sources, the next step is categorising them.
In most environments these sources fall into three groups.
Legitimate Services
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.
Misconfigured Services
Some legitimate platforms appear in reports with authentication failures.
Common causes include:
- the service is not authorised in the SPF record
- DKIM signing has not been enabled
- the sending domain does not align with the visible From address
These issues are usually resolved by updating DNS records or adjusting platform configuration.
Legacy Services
Many organisations discover systems that are no longer in use.
These may include:
- old marketing tools
- temporary development systems
- platforms used for past projects
Leaving these services authorised increases the domain’s attack surface and complicates authentication records.
Removing them simplifies the sending environment.
Step 6: Move From Monitoring to DMARC Enforcement
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:
- p=none – monitoring mode
- p=quarantine – suspicious messages sent to spam
- p=reject – unauthenticated messages rejected
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.
Maintaining Visibility Over Your Email Ecosystem
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:
- detection of new senders
- high authentication failure rates
- DNS policy changes
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.
Leave a Reply