DMARC Untrusted Sources: How to Investigate and Fix Them

DMARC untrusted sources are IP addresses or sending systems that appear in DMARC aggregate reports but have not yet been recognized as legitimate mail streams for your domain. The important task is not to blindly trust or block them: it is to determine whether each source is an authorized sender with a configuration problem, an unknown business tool, forwarding traffic, or actual domain spoofing.

What “DMARC untrusted sources” actually means

“Untrusted source” is usually a reporting-dashboard label, not a formal DMARC result defined by the protocol. DMARC reports contain observations about mail that claimed to be from your domain, including the sending IP address, message volume, SPF and DKIM authentication results, alignment outcomes, and the policy disposition applied by the receiving mailbox provider.

A reporting product may call a source trusted after you identify it as an approved email provider, corporate mail server, help desk, CRM, billing platform, or application. It may call a source untrusted when it cannot confidently associate the IP address or provider with a sender you have approved. That classification is useful for triage, but it is not proof that the mail was malicious.

The DMARC protocol itself evaluates a message based on the visible From: domain, SPF, DKIM, identifier alignment, and your published DMARC policy. A receiver does not receive a universal list of your approved platforms. It sees authentication evidence and applies local policy.

That distinction matters because these two statements are different:

• “This source is unknown in our DMARC dashboard.”
• “This message failed DMARC and should be treated as unauthenticated.”

An unfamiliar source can pass DMARC. For example, a new invoice system might already sign mail with aligned DKIM but not yet be named in your reporting tool. Conversely, a source you recognize can fail DMARC after a DNS change, an expired DKIM configuration, an incorrect return-path, or a migration to a new sending route.

Treat untrusted-source reporting as an inventory and investigation workflow. The goal is to make legitimate mail authenticate reliably while publishing a policy that causes spoofed mail to be quarantined or rejected.

How DMARC decides whether mail is authenticated

DMARC evaluates the domain in the RFC 5322 From: header—the address recipients normally see in their mail client. If a message says:

From: Acme Support <support@example.com>

then example.com is the author domain that DMARC protects. The message passes DMARC when at least one of these conditions is true:

1. SPF passes for the envelope sender domain and that domain aligns with example.com.
2. DKIM passes with a signing domain in the d= tag that aligns with example.com.

It does not need both SPF and DKIM to pass and align. One aligned passing mechanism is enough for DMARC to pass. In practice, however, configuring both is the safer approach because it gives your mail resilience when forwarding, routing, or a provider-specific configuration affects one mechanism.

The three identities that cause confusion

A single email can contain several domain identities. They serve different purposes:

Consider this message:

From: receipts@example.com
Return-Path: bounce@mailer.vendor.example
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2026; ...

SPF may pass for mailer.vendor.example, but that domain does not align with example.com. If DKIM passes for d=example.com, DMARC still passes because the DKIM identity is aligned. If the DKIM signature is missing or fails, DMARC fails even though SPF itself passed.

This is why a report can show spf=pass and dkim=pass while also showing dmarc=fail: neither passing identity may align with the visible From: domain.

Relaxed and strict alignment

DMARC has relaxed alignment by default. Under relaxed alignment, subdomains can align with their organizational domain. For example:

From: alerts@example.com
DKIM d=notify.example.com

With relaxed DKIM alignment (adkim=r), notify.example.com can align with example.com. With strict DKIM alignment (adkim=s), it does not; the domains must match exactly.

The same concept applies to SPF alignment with aspf=r or aspf=s. Strict alignment can be appropriate for tightly controlled domains, but it often exposes overlooked third-party senders and operational variations. Start with relaxed alignment unless you have a tested reason to require strict matching.

Why untrusted sources appear in DMARC reports

Most untrusted-source entries fall into a handful of repeatable categories. The IP address alone is not enough to classify one safely, so use the entire report row and, when possible, a sample message header.

1. A legitimate provider was never added to your inventory

Organizations often discover more systems than expected when they begin receiving aggregate reports. Common examples include:

• Customer-support platforms sending ticket updates.
• Product tools sending invitations, alerts, and password resets.
• Accounting systems sending invoices and payment reminders.
• Recruiting, survey, event, and scheduling services.
• CMS plugins or ecommerce extensions sending order notifications.
• An older SMTP relay embedded in an application or office workflow.
• A separate business unit using its own marketing or CRM platform.

A system can be fully legitimate but invisible to the person managing DNS. This is especially common when a team has entered @example.com as a sender address in a SaaS product without involving email, security, or platform engineering.

2. A legitimate source is misconfigured

This is the most actionable class of DMARC untrusted sources. The platform may be authorized to send for you, but it is using a provider-owned return-path, signing with the provider’s domain, or sending before domain authentication was completed.

Typical report pattern:

header_from=example.com
spf=pass, smtp.mailfrom=provider-bounces.example
spf_aligned=false
dkim=pass, header.d=provider.example
dkim_aligned=false
dmarc=fail

Nothing in that result proves abuse. It says the provider authenticated itself, not your visible From: domain. The usual fix is to configure custom-domain DKIM, and where offered, a custom bounce or return-path domain. This allows the provider to authenticate mail in a way that aligns with the domain your recipient sees.

3. A forwarding path changed the message’s SPF result

SPF validates whether the connecting IP address is authorized to send for the envelope sender domain. Traditional forwarding can cause SPF to fail because the forwarding server becomes the connecting IP at the final mailbox provider, but is not listed in the original sender’s SPF record.

DKIM is frequently the mechanism that preserves DMARC passing across forwarding because a valid signature can survive a simple forward. That depends on the forwarder not making a change that breaks the signature, such as altering signed content or certain signed headers.

Forwarded messages are therefore worth investigating before you classify them as spoofing. Look for report rows with low volume, unexpected source IPs, and a passing aligned DKIM result. That often indicates mail originally sent by an authorized platform and then forwarded by a recipient’s server or mailing arrangement.

4. A mailing list modified a message

Mailing lists commonly add subject prefixes, footer text, list headers, or other content. Those modifications can invalidate DKIM signatures. They can also relay mail through an IP that fails the original sender’s SPF policy.

The result may be a legitimate message that fails both SPF alignment and DKIM validation after the list changes it. ARC, or Authenticated Received Chain, can give receiving systems additional context about authentication before intermediaries changed the message, but ARC is not a substitute for correctly configuring your own authorized sending sources.

5. Someone is spoofing your domain

This is the outcome DMARC is designed to expose and reduce. A threat actor can put your domain in the visible From: header without control of your DNS, SPF authorization, or DKIM private keys.

Spoofing patterns often include:

• An IP address or network you cannot associate with any vendor or internal system.
• SPF failure, neutral, softfail, permerror, or an unrelated envelope domain.
• DKIM failure, no DKIM signature, or a signature with an unrelated d= domain.
• A high volume of messages claiming to be from a domain that does not normally send that type of mail.
• Sudden spikes from a country, ASN, or cloud range unrelated to your infrastructure.

Do not assume every failing source is hostile. But if the source has no legitimate owner and cannot produce aligned authentication, it should remain untrusted. A p=quarantine or p=reject DMARC policy is what tells participating receivers how to handle such failures.

Read the report row before changing DNS

DMARC aggregate reports are generally compressed XML files sent to the address in your rua tag. Reporting platforms parse them into tables and charts, but you should understand the fields behind the visualization.

A simplified record might look like this:

<record>
  <row>
    <source_ip>198.51.100.24</source_ip>
    <count>42</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <spf>
      <domain>bounce.provider.example</domain>
      <result>pass</result>
    </spf>
    <dkim>
      <domain>provider.example</domain>
      <result>pass</result>
    </dkim>
  </auth_results>
</record>

The apparent contradiction is intentional: the source may have passed SPF and DKIM for provider domains while failing DMARC alignment for example.com. The policy_evaluated results describe DMARC’s aligned outcome, while auth_results show the underlying authentication results the receiver observed.

A practical investigation checklist

For every unfamiliar row, capture these details before changing a record:

1. Source IP and message count. One message per day may be a forward or isolated test; tens of thousands of messages can indicate a production sender or active abuse.
2. Header-from domain. Confirm exactly which of your domains or subdomains the message claimed to use.
3. SPF result and SPF domain. Note whether SPF failed outright or passed for a non-aligned provider domain.
4. DKIM result, selector, and d= domain. A passing signature from your domain is strong evidence of an authorized configuration.
5. DMARC disposition. none, quarantine, and reject indicate the policy action reported by the receiver, but receivers retain local discretion.
6. Reverse DNS, ASN, and provider clues. These can suggest a known cloud or email service, but are not enough to authorize a sender by themselves.
7. Internal ownership. Ask product, support, finance, marketing, IT, and security teams whether they operate the source.
8. A message sample. When available, inspect full headers from a mailbox you control rather than relying only on a dashboard’s summary.

The operational rule is simple: authorize systems because you have verified business ownership and technical configuration—not because their IP address looks familiar.

Inspect message headers to find the real failure

DMARC aggregate reports are excellent for scope and volume. A raw message header is better for diagnosing one concrete delivery path.

Send a test message to a mailbox you control, then view the original source or full headers. Gmail exposes this through “Show original”; many other mail clients have a similar option. Look for Authentication-Results, Return-Path, DKIM-Signature, and the From: header.

Here is a representative result:

Authentication-Results: mx.recipient.example;
       spf=pass smtp.mailfrom=bounce.mail.example;
       dkim=pass header.d=example.com header.s=tx2026;
       dmarc=pass header.from=example.com
From: Example App <notifications@example.com>
Return-Path: <bounce@bounce.mail.example>
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=tx2026; ...

In this example, SPF may or may not align depending on the organizational domain of bounce.mail.example. DMARC passes because DKIM passes with d=example.com, which aligns exactly with the visible author domain.

Now compare a configuration that does not align:

Authentication-Results: mx.recipient.example;
       spf=pass smtp.mailfrom=mail.provider.example;
       dkim=pass header.d=provider.example;
       dmarc=fail header.from=example.com
From: Example App <notifications@example.com>
Return-Path: <bounce@mail.provider.example>
DKIM-Signature: v=1; a=rsa-sha256; d=provider.example; s=s1; ...

The provider authenticated the message successfully, but neither authenticated domain aligns with example.com. This is a configuration issue, not a reason to add the provider’s IP address blindly to your SPF record.

Do not confuse delivery acceptance with inbox placement

A transactional email API or SMTP relay may respond with an HTTP 202 Accepted, a successful API response, or an SMTP 250 response after accepting your message for processing. That only means the service accepted the submission. It does not mean the receiving mailbox accepted the message, and it definitely does not guarantee inbox placement.

At the receiving end, a DMARC enforcement failure may produce a permanent SMTP rejection such as 550 5.7.26, commonly seen in messages rejected because the sender is unauthenticated under the domain’s DMARC policy. A 5xx response is permanent for that attempted delivery; a 4xx response is temporary and should be retried according to the sending system’s retry policy.

When troubleshooting, follow the chain in order: application submission, provider acceptance, provider delivery attempt, recipient SMTP response, recipient authentication evaluation, and final mailbox placement. Skipping steps leads to incorrect conclusions about what “sent successfully” means.

Fix legitimate sources with SPF, DKIM, and aligned domains

The correct remediation depends on the sender’s architecture. Avoid a one-size-fits-all response such as adding every platform to SPF. DKIM alignment is often the more durable path for application and third-party email because it can survive forwarding better than SPF and does not consume SPF’s limited DNS lookup budget.

Configure DKIM for every sending platform

DKIM signs email with a private key. Receivers retrieve the matching public key from DNS, usually at this hostname pattern:

<selector>._domainkey.<your-domain>

A typical DNS TXT record looks like:

Host: tx2026._domainkey.example.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

The selector (tx2026 in this example) and public-key value must come from the actual sending system. Do not copy a placeholder key or substitute a selector from another vendor. Many providers use CNAME records that delegate selector lookups to provider-managed DNS instead of publishing the public key directly as a TXT record. Use the exact record type, hostname, and target supplied by that provider.

For DMARC, check the d= value in the resulting DKIM-Signature header. The signature must use your domain or an aligned subdomain. A valid DKIM signature with d=provider.example is still not aligned with From: sender@example.com.

Keep SPF accurate, but do not overuse it

SPF is a TXT record at the root of the envelope sender domain. A syntactically valid example is:

Host: example.com
Type: TXT
Value: v=spf1 ip4:198.51.100.24 include:spf.mail-provider.example -all

The IP address and included domain above are illustrative. In production, use only IP ranges and include: mechanisms explicitly documented by systems you control or have authorized.

Important SPF rules:

• Publish one SPF TXT record for a domain. Multiple independent records beginning with v=spf1 can cause SPF permerror.
• include: delegates evaluation to another domain’s SPF policy; it is not merely a text include.
• -all is a hard fail mechanism and is appropriate only after you have listed every legitimate sender for that envelope domain.
• ~all is softfail, which is less definitive and does not make an unknown sender legitimate.
• SPF evaluation has a limit of 10 DNS-querying terms and mechanisms. Nested includes can reach the limit faster than expected.

If many SaaS tools send mail for you, do not pile every provider into a single root-domain SPF record. Where possible, use provider-specific bounce domains or dedicated sending subdomains. That separates reputation, simplifies ownership, and reduces the chance that an unrelated application breaks SPF for the rest of the organization.

Use custom return-path domains where they are supported

The SMTP envelope sender controls where bounces are routed and is frequently exposed after delivery as Return-Path:. Many email providers can use a custom subdomain for bounces, such as:

bounce.example.com

A provider may ask you to publish an MX record, CNAME record, SPF record, or a combination of records for that subdomain. Follow its supplied values exactly. The DNS hostname, record type, and target are provider-specific.

A custom return-path can make SPF align under relaxed alignment when the visible sender is also under example.com. But do not treat it as a replacement for DKIM. Configure both when the sending system supports both.

Separate traffic by subdomain

A subdomain strategy makes untrusted-source investigations less ambiguous. For example:

From: billing@billing.example.com
From: updates@notify.example.com
From: support@support.example.com
From: marketing@news.example.com

You can assign one owner and one approved sending platform to each stream. A problem in a marketing platform then does not require an urgent change to transactional receipts. Subdomain separation also makes report rows easier to interpret because the header_from domain provides context about the intended mail stream.

For a REST API or SMTP relay, choose a clearly owned transactional subdomain such as notify.example.com, authenticate it with the provider’s supplied DKIM and return-path records, and send production mail only after a header test confirms aligned DMARC passing. The same principle applies whether your application submits through HTTPS or SMTP: the authentication identity is determined by the final outbound message, not by the submission protocol.

For implementation patterns and authentication setup guidance, consult the email API reference and setup guides.

Publish a DMARC record that supports investigation

DMARC is published as a DNS TXT record at _dmarc.<domain>. A useful initial monitoring record is:

Host: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

This tells participating receivers to send aggregate reports to dmarc-reports@example.com while requesting no specific enforcement action for messages that fail DMARC. It is a monitoring mode, not protection against spoofing.

Before using that mailbox, make sure it can receive compressed report attachments and that someone or a reporting tool processes them. Aggregate reports can be numerous, often come from many mailbox providers, and are not designed for convenient manual reading.

A cautious enforcement sequence

A reliable rollout is a process rather than a one-time DNS change:

1. Publish p=none with an rua destination.
2. Gather enough reports to cover recurring billing cycles, application schedules, and low-volume operational mail.
3. Classify every meaningful source as authorized, forwarded, misconfigured, unknown, or spoofed.
4. Fix alignment for legitimate senders and verify with live message headers.
5. Confirm that high-volume legitimate traffic consistently passes aligned SPF or DKIM.
6. Move to p=quarantine when you can tolerate suspicious failures being treated more cautiously by receivers.
7. Move to p=reject after you have confidence that remaining DMARC failures are unauthorized or intentionally unsupported flows.
8. Continue monitoring. New SaaS tools, mergers, routing changes, and application releases can create new sources later.

An enforcement record might look like:

Host: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

Do not copy an enforcement record into production merely because it is syntactically valid. The risk is operational: a valid but overlooked sender—such as a payroll system, appointment reminder service, or disaster-recovery mail relay—can begin failing at recipients once enforcement is active.

When an untrusted source should remain untrusted

Do not “fix” every report row. Some sources are spoofing attempts, and some are not under your control. There is no safe DNS setting that turns an attacker’s server into an authorized sender without also weakening your domain’s security.

Leave a source untrusted when all of the following apply:

• No internal owner can identify the system or business purpose.
• The source does not have a contractually or operationally approved relationship with your organization.
• SPF and DKIM do not authenticate an aligned domain.
• Header samples suggest impersonation, phishing, or unrelated content.
• The message volume or location is inconsistent with your legitimate mail patterns.

Do not add unknown IP addresses to SPF. SPF records should define authorized infrastructure, not serve as a response to every IP that has claimed to send for your domain. Adding an attacker’s address would authorize it for the envelope sender domain and increase the risk of successful impersonation.

Similarly, do not change your visible From: domain to a provider-owned domain just to make a report turn green. That can damage brand consistency, reply handling, and user trust. The better solution is usually to authenticate the domain you actually want recipients to see.

Tools that make investigation faster

You can diagnose many cases with standard DNS and email tools. Use more than one source of evidence, especially before authorizing a new sender.

Command-line DNS checks

On systems with dig, query the records directly:

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT tx2026._domainkey.example.com
dig +short MX bounce.example.com

The output helps answer basic questions: Is the record published? Is the host name correct? Does DNS return the expected record type? Are multiple SPF records present?

Remember that DNS provider interfaces handle relative names differently. Some expect _dmarc because they automatically append your zone name; others expect _dmarc.example.com. Verify the final public DNS result rather than trusting only the form field in the control panel.

Browser-based validators and inbox tests

MXToolbox can inspect published DMARC, SPF, DKIM, and MX records and flag common structural problems. It is useful for quick public-DNS checks, though it cannot confirm that your application is using the intended sender configuration.

mail-tester.com can provide a practical test inbox and report on a message you send to it, including visible authentication results and content-related deliverability signals. Use it as a diagnostic aid, not as a guarantee that all mailbox providers will make the same delivery decision.

A mailbox at a major provider is also valuable for checking the actual Authentication-Results header produced by a recipient environment. Send a controlled test from every configured platform and record the results in your sender inventory.

Address quality is separate from DMARC

DMARC confirms domain-level authentication; it does not prove that the recipient address exists, accepts mail, or belongs to the intended person. Before sending high-value transactional or campaign traffic, consider using an email address verification tool to reduce avoidable bounces and preserve sending reputation.

Common mistakes that create false confidence

DMARC projects often fail because teams verify one layer and assume the rest is correct. The following mistakes are particularly common.

“SPF passes, so we are done”

SPF passing for a provider-owned envelope domain does not satisfy DMARC for your visible From: domain unless it aligns. Check smtp.mailfrom or Return-Path, not just the word “pass.”

“Our provider says DKIM is enabled”

A provider can sign every message with its own domain and truthfully say DKIM is enabled. For DMARC, inspect the signing domain in DKIM-Signature: d=. It must align with the domain in From:.

“We added a DMARC record, so spoofing is blocked”

A p=none record produces reporting but requests no enforcement. It is valuable during discovery, but it is not equivalent to quarantine or rejection.

“We can authorize every tool through SPF”

SPF has one-record and DNS lookup constraints, and forwarding can break it. Use SPF deliberately, but prioritize aligned DKIM for third-party sending systems where available.

“A provider accepted our API call, so DMARC is fine”

An HTTP acceptance response or SMTP 250 from your relay is not recipient delivery confirmation. Inspect recipient-side headers and delivery events to verify the final authentication result.

“The DMARC policy guarantees every receiver will behave identically”

DMARC publishes the domain owner’s requested handling. Mail receivers apply the protocol alongside their own local policies, reputation systems, anti-abuse controls, and handling for special cases. Treat p=reject as strong protection against direct spoofing, not as a promise of identical outcomes everywhere.

A repeatable operating model for DMARC sources

The healthiest long-term approach is to make sender authorization part of change management. Every time a team adds an email platform, changes a domain, launches a subdomain, or routes mail through a new service, authentication should be an explicit implementation requirement.

Maintain a sender register with these fields:

• Product or service name.
• Business owner and technical owner.
• Purpose: transactional, support, billing, marketing, internal, or other.
• Visible From: domain and address patterns.
• Envelope sender or custom return-path domain.
• DKIM signing domain and selector.
• Required DNS records and the person responsible for them.
• Expected monthly volume and sending regions.
• Header-test date and latest aligned DMARC result.
• Retirement date when a tool is removed.

This inventory turns an “untrusted source” alert from a mystery into a comparison exercise. If the source should be in the register, authenticate and document it. If it should not be there, investigate it as potential spoofing. If you cannot determine which is true, do not authorize it until an accountable owner can.

The second-order benefit is deliverability resilience. A team that knows exactly which systems send for each domain can isolate traffic, rotate DKIM keys, remove old SPF includes, retire compromised credentials, and respond to recipient-side failures without guessing which application is affected.

Conclusion

DMARC untrusted sources are evidence, not verdicts. They reveal every place where your domain appears in mail, including approved vendors, forgotten applications, forwarding paths, misconfigured platforms, and spoofing attempts.

Start by reading the underlying SPF, DKIM, alignment, and volume data. Authenticate legitimate platforms with aligned DKIM and, where appropriate, aligned SPF through a custom return-path. Keep unknown sources unauthorized, monitor reports continuously, and move from p=none to enforcement only after you have accounted for real mail streams.

The result is more than a cleaner dashboard: it is a controlled, documented email-sending estate that is harder to spoof and easier to operate.

FAQ

Are DMARC untrusted sources always malicious?

No. They may be legitimate platforms that have not been identified, systems with broken SPF or DKIM alignment, forwarded messages, mailing-list traffic, or spoofing attempts. Investigate the source, authentication results, volume, and internal ownership before deciding.

Can a message pass SPF and DKIM but fail DMARC?

Yes. DMARC requires SPF or DKIM to pass and align with the visible From: domain. SPF can pass for a provider-owned return-path and DKIM can pass for a provider-owned signing domain while DMARC still fails because neither domain aligns.

Should I add every email provider to my SPF record?

No. Add only verified, authorized senders, and remember that SPF has a 10-DNS-lookup evaluation limit. For most third-party platforms, configure aligned DKIM as well; it is often more resilient and avoids making SPF unnecessarily complex.

What does p=none do in a DMARC record?

p=none asks receivers to monitor and report DMARC failures without requesting quarantine or rejection. It is appropriate for discovery and troubleshooting, but it does not provide meaningful enforcement against direct spoofing.

Why did a legitimate email receive a 550 5.7.26 response?

That permanent SMTP rejection is commonly associated with a recipient refusing unauthenticated mail under a domain’s DMARC policy. Check the sender’s visible From: domain, envelope sender, DKIM d= domain, DNS records, and alignment results to find the configuration gap.