DMARC Trusted Sources: How to Identify Legitimate Email Senders

DMARC trusted sources are the legitimate email systems that send messages using your domain in the visible From: header and successfully authenticate in a way that aligns with that domain. Finding them is the practical work behind DMARC: before you quarantine or reject unauthenticated mail, you need to know which services, applications, and mail servers are genuinely allowed to send.

A DMARC reporting dashboard may label familiar, authenticated traffic as “trusted sources,” but that label is not a formal DMARC protocol result. DMARC itself evaluates authentication and alignment for each message. Your reporting tool then groups the aggregate data to help you distinguish known, legitimate senders from unknown infrastructure, configuration mistakes, and possible spoofing.

What “DMARC trusted sources” means

A trusted source is not simply an IP address that has sent mail from your domain before. It is a sending system you have intentionally authorized and can validate through configuration, ownership, and message authentication.

In a healthy setup, a trusted source normally has all of the following characteristics:

• It is owned or deliberately used by your organization, such as Google Workspace, Microsoft 365, a support desk, a billing platform, a CRM, an application server, or a transactional email provider.
• It sends messages with an address under a domain or subdomain you control in the visible From: header.
• It passes either SPF alignment or DKIM alignment with that visible From: domain. Passing both is preferable.
• Its sending volume, geography, IP ranges, and message types make sense for your business.
• You can identify an accountable owner, integration, vendor contract, application, or DNS record behind it.

The opposite is an unknown source: a server or service claiming to send as example.com that you cannot account for, cannot authenticate correctly, or both. Unknown does not automatically mean malicious. It may be a forgotten SaaS integration, a legacy scanner, a copier or ticketing system, a contractor’s platform, a forwarded message, or a new provider that has not been configured for alignment. But unknown traffic must be investigated rather than automatically trusted.

DMARC is built around the Author Domain—the domain in the RFC 5322 From: header that recipients see. It checks whether SPF and/or DKIM passed and whether the passing identity aligns with that visible domain. The current core specification is RFC 9989; it replaced the older RFC 7489 specification in 2026. (rfc-editor.org)

DMARC does not maintain a trusted-sender allowlist

It is important to separate three ideas that are often conflated:

1. DMARC authentication determines whether a message passes SPF or DKIM with alignment to the visible From: domain.
2. A DMARC reporting tool’s trusted-source category is an interpretation layer that groups report data into something useful for humans.
3. A recipient’s local allowlist or reputation system is a mailbox-provider decision that may affect delivery but does not change the DMARC standard.

There is no DMARC DNS tag such as trusted_source=, and you cannot make a source DMARC-compliant merely by adding its IP address to a DMARC record. Legitimate systems become trusted through the authentication mechanisms that DMARC consumes:

• SPF authorizes systems to use an envelope sender, also called the MAIL FROM or return-path domain.
• DKIM attaches a cryptographic signature associated with a domain.
• DMARC requires at least one passing identifier to align with the visible From: domain.

This is why an address can show SPF pass, DKIM pass, and still fail DMARC. The passing domain may belong to a vendor rather than to the domain in the visible From: header.

For example, imagine a message with these identities:

From: receipts@example.com
Return-Path: bounce@mailer.vendor.example
DKIM-Signature: d=mailer.vendor.example; s=tx1; ...

If SPF passes for mailer.vendor.example and DKIM passes for mailer.vendor.example, those mechanisms are technically valid. But neither domain aligns with example.com, so DMARC for example.com can fail. The vendor is not automatically an untrusted sender; the configuration simply lacks DMARC alignment.

The authentication signals that establish trust

SPF: authorization for the envelope sender

SPF is evaluated against the envelope sender domain used during SMTP transmission, not necessarily the visible From: address. A receiving server evaluates the connecting IP address against that domain’s SPF TXT record.

A simplified SPF record might look like this:

example.com. TXT "v=spf1 ip4:198.51.100.25 include:_spf.google.com -all"

The record says that 198.51.100.25 and the servers authorized by Google’s published SPF policy may send mail using an envelope sender at example.com. In a real deployment, use only the mechanisms your organization needs. Do not copy an include: value from another provider unless that provider explicitly documents it for your account and sending domain.

For DMARC, SPF must also align. With relaxed alignment, bounce@mail.example.com can align with example.com because both share the same organizational domain. With strict alignment, the SPF domain must exactly match the visible From: domain.

SPF is useful, but it has limitations. Forwarding often changes the connecting IP address and can cause SPF to fail. SPF also has a hard evaluation limit of 10 DNS-querying terms across the complete policy evaluation tree. A long chain of nested include: mechanisms can therefore return permerror, removing SPF as a reliable DMARC path. (datatracker.ietf.org)

DKIM: a domain signature that can survive forwarding

DKIM signs selected headers and the body using a private key. The receiving server looks up the matching public key in DNS and verifies the signature. A typical DKIM DNS record name has this structure:

s2026._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

The selector, s2026 in this example, identifies a key. The public key is published at selector._domainkey.domain. The email itself then contains a header similar to:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s2026; ...

For DMARC, the critical value is d=example.com. If the signature passes and d=example.com aligns with the visible From: receipts@example.com, DKIM provides a passing DMARC path even if SPF fails during forwarding.

DKIM is usually the most durable way to establish a trusted source for transactional email, especially when a provider supports signing with your domain or a subdomain you control. RFC 6376 defines the underlying DKIM signature mechanism; current DKIM deployment guidance also emphasizes cryptographic and operational hygiene around signing domains and keys. (rfc-editor.org)

DMARC alignment: the missing link

Alignment answers a question SPF and DKIM alone do not: “Is the authenticated domain meaningfully connected to the domain the recipient sees in From:?”

Consider these outcomes:

A source should generally be considered trusted only after you verify this full chain, not after seeing a simple SPF or DKIM pass in isolation.

Read aggregate reports before changing policy

DMARC aggregate reports, often called RUA reports, are XML documents sent by participating mailbox providers. They summarize messages claiming to use your domain, typically grouped by source IP address, date range, authentication results, and visible header domain.

A reporting service can turn the raw XML into charts and labels such as trusted, untrusted, compliant, failing, or unknown. Those labels are helpful, but your investigation should return to the report fields underneath the label.

The most useful fields are usually:

• source_ip: the IP address observed by the reporting receiver.
• count: number of messages represented by the row.
• header_from: the visible From: domain assessed by DMARC.
• envelope_from: the SPF identity domain, when supplied.
• dkim results: domain and pass/fail result for evaluated DKIM signatures.
• spf results: domain and pass/fail result for SPF evaluation.
• disposition: the receiver’s applied handling decision, such as none, quarantine, or reject.

The aggregate-report format is defined separately in RFC 9990. Reports are useful because they show what receivers actually observed, rather than only what you believe your infrastructure sends. (rfc-editor.org)

Start with a monitoring policy

A practical initial record uses monitoring mode:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-aggregate@example.com; adkim=r; aspf=r; pct=100"

What each tag means:

• v=DMARC1 identifies the record as DMARC.
• p=none asks receivers to monitor failures without requesting quarantine or rejection.
• rua=mailto:... requests aggregate reports at the specified mailbox.
• adkim=r uses relaxed DKIM alignment.
• aspf=r uses relaxed SPF alignment.
• pct=100 applies the requested policy to all qualifying mail. With p=none, this does not ask for enforcement.

Use a dedicated reporting mailbox or a reporting service that can process compressed XML attachments. Reports can be numerous, may arrive from many receivers, and are not a substitute for checking actual sent-message headers.

Avoid publishing multiple DMARC TXT records at _dmarc.example.com. DMARC expects a single valid policy record. Multiple records can cause receivers to treat the DMARC lookup as invalid or unusable.

Build an inventory rather than trusting a dashboard label

As reports arrive, create a sender inventory. A simple working table is enough:

The goal is not to classify a source by name alone. A recognizable vendor may still be sending from the wrong domain, using an old account, or operating a forgotten integration. Conversely, an unfamiliar source may be legitimate after investigation.

How to verify a suspected trusted source

A reliable verification process combines report data, DNS inspection, message headers, and organizational ownership. Do not rely on just one signal.

1. Identify the business purpose

Ask what messages the source sends and why. Common legitimate categories include:

• Corporate mailbox traffic from Google Workspace or Microsoft 365.
• Password resets, login alerts, account verification, receipts, and product notifications.
• Customer-support replies and ticket updates.
• Billing, invoicing, subscription, and payment notifications.
• Marketing automation, product announcements, and newsletters.
• Form notifications, monitoring alerts, CI/CD systems, and application logs.
• Devices and services such as scanners, printers, HR systems, and ERP platforms.

Every production source should have an owner. “We think marketing used it years ago” is not an ownership model. If no team can identify the integration, the source should remain untrusted until proven otherwise.

2. Match source IPs carefully

A DMARC report’s source_ip is useful evidence, but a source IP is not a permanent identity. Cloud providers rotate infrastructure, shared sending platforms use broad ranges, and some vendors publish different IP ranges by region or product.

Use the provider’s official documentation to determine whether the IP range is expected. Then compare message count, sending dates, mail category, and authentication results. A known IP range with unexpected volume or a failing DKIM domain still deserves investigation.

Reverse DNS can provide context, but it is not proof of authorization. A hostname that appears to name a vendor is weaker evidence than a valid, aligned DKIM signature from your domain.

3. Inspect a real received message

Send a controlled test email to a mailbox you can inspect, then view the full headers. Gmail’s “Show original” view is one convenient option; other mailbox clients expose raw headers through message details or source views.

Look for authentication summary headers such as:

Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=bounce.example.com;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

The exact formatting varies by receiver, but the important checks are stable:

• Does SPF pass, and is smtp.mailfrom aligned with the visible From: domain?
• Does DKIM pass, and is header.d aligned with the visible From: domain?
• Does the receiver report dmarc=pass for the intended header.from domain?

A test tool such as mail-tester.com can help reveal authentication results, headers, spam-related issues, and obvious configuration errors. MXToolbox is also useful for checking published DMARC, SPF, DKIM, and DNS records. Treat third-party test results as diagnostics, not as a replacement for recipient-side aggregate reports.

4. Check DNS from the domain owner’s perspective

Use command-line tools to verify the record actually visible in public DNS:

dig +short TXT _dmarc.example.com
dig +short TXT example.com
dig +short TXT s2026._domainkey.example.com

For the DMARC query, confirm there is one intended v=DMARC1 record. For SPF, confirm there is one SPF TXT policy beginning with v=spf1; SPF records must not be split into multiple independent policies. For DKIM, confirm the selector in the message header matches the selector published in DNS.

DNS providers may display a hostname differently from how it is queried. If your DNS dashboard automatically appends example.com, entering _dmarc.example.com in a field that expects only _dmarc can accidentally create _dmarc.example.com.example.com. Verify with dig, not just with the dashboard’s visual preview.

5. Confirm the sending application configuration

For a REST email API or SMTP relay, confirm the sending application uses an approved From: address and that the provider is configured to sign with an aligned DKIM domain. Also confirm the return-path or envelope sender domain if you intend to rely on SPF alignment.

A successful API response means the provider accepted the request; it does not prove that the message will authenticate or reach the inbox. For example, an HTTP 202 Accepted response commonly means asynchronous acceptance for processing, while 400 Bad Request, 401 Unauthorized, 403 Forbidden, 422 Unprocessable Content, and 429 Too Many Requests indicate different request, authorization, validation, or rate-limit problems. Delivery, bounces, recipient filtering, and DMARC outcomes happen after acceptance.

On SMTP, a server may accept a message with a 250 response during the transaction and a recipient can still later classify it as spam or reject it during downstream processing. Conversely, SMTP 550 class failures are generally permanent for that transaction, and enhanced status codes in the 5.7.x family often indicate a policy or authentication-related problem. The precise text and code combination are receiver-specific, so preserve the full bounce message when troubleshooting.

For implementation guidance specific to sending through an API or SMTP relay, consult the provider’s email API setup documentation alongside its domain-authentication instructions.

Common reasons legitimate sources fail DMARC

A legitimate source can be operationally trusted but technically noncompliant. That distinction is exactly why a monitoring period matters.

Vendor DKIM passes, but the domain is not aligned

This is one of the most common cases. A platform signs mail with d=vendor.example while the message says From: notifications@example.com. The signature may be cryptographically valid, but DMARC cannot use it for example.com.

The preferred fix is normally to configure a custom DKIM signing domain such as mail.example.com or notify.example.com, subject to the provider’s documented DNS process. If the provider cannot sign with your domain, consider whether it is appropriate to use that provider for mail that visibly claims to be from your domain under an enforced DMARC policy.

SPF passes, but the return-path is vendor-owned

A provider may use a vendor-owned bounce address such as bounce@mailer.vendor.example. SPF passes for that domain, but it does not align with example.com.

The fix is often a custom return-path, MAIL FROM, or bounce domain under your domain, such as bounce.example.com. Do not assume this is necessary if aligned DKIM already passes; DKIM may be sufficient for DMARC. However, having both aligned SPF and aligned DKIM improves resilience and diagnostic clarity.

A new SaaS integration was never authenticated

Marketing, finance, support, and operations teams can add tools that send email without involving the team that manages DNS. Typical examples include survey platforms, invoicing tools, recruiting systems, product analytics services, and calendar tools.

The fix is procedural as well as technical: require a domain-authentication review before any new sender uses an organizational From: domain. Record the owner, service, domains, selectors, SPF dependencies, expected traffic, and sunset plan.

Forwarding breaks SPF

When a message is forwarded, the forwarding server becomes the connecting IP seen by the recipient. That IP is usually not authorized by the original sender’s SPF record, so SPF can fail.

A valid, aligned DKIM signature can preserve DMARC success if the message content and signed headers remain intact. Authentication-Results Chain (ARC) can help receivers understand prior authentication outcomes in some forwarding scenarios, but it is not a replacement for signing mail correctly at the source.

Mailing lists modify the message

Mailing lists may add a footer, alter the subject, change recipient-related headers, or rewrite the visible From: address. Those changes can break DKIM signatures or change the DMARC domain under evaluation.

If your legitimate outbound mail passes through a list, test the full route. If you run a list, use list software and policies designed to handle DMARC-aware delivery rather than assuming your original sender configuration will survive every modification.

Choosing relaxed versus strict alignment

DMARC has two alignment modes for both SPF and DKIM:

• Relaxed alignment is set with aspf=r and adkim=r, or used by default when the tags are omitted.
• Strict alignment is set with aspf=s and adkim=s.

With relaxed alignment, a subdomain can align with its organizational domain. For example, news.example.com can align with example.com in the common case. With strict alignment, the domains must be identical.

Relaxed alignment is usually the better operational starting point because it supports sensible domain separation. You can send receipts from mail.example.com, support mail from support.example.com, and employee mail from example.com without requiring every message’s identities to be character-for-character identical.

Strict alignment is useful when you deliberately want exact-domain control and have a small, tightly managed sending environment. It can also expose hidden dependencies quickly. But strict mode raises the chance that a legitimate service will fail after a subdomain, return-path, or DKIM-domain change.

A sensible progression is to establish complete coverage under relaxed alignment first. Move to strict alignment only after you understand the effect on every trusted source and have a concrete security reason to require it.

A safe path from monitoring to enforcement

Do not move from p=none to p=reject based on a few days of clean reports. Email infrastructure often has low-frequency sources: monthly invoices, quarterly HR notices, disaster-recovery alerts, seasonal campaigns, or rarely used support workflows.

Use a staged process:

1. Publish p=none with aggregate reporting. Collect enough data to cover normal business cycles.
2. Inventory every meaningful source. Assign a team owner and message purpose to each one.
3. Fix alignment. Prioritize sources that use your primary domain in the visible From: address but fail DMARC.
4. Retire or isolate unknown sources. Remove forgotten integrations, rotate credentials, or move experimental traffic to a separate subdomain.
5. Test real flows. Test password resets, receipts, support replies, invoices, campaigns, and employee mail—not only a single developer test.
6. Move to p=quarantine. Start with a low percentage if your risk tolerance requires a gradual rollout.
7. Review failures continuously. Monitor reports, bounce data, support tickets, and mailbox-provider feedback.
8. Move to p=reject. Use full enforcement when legitimate senders are consistently aligned and unknown traffic has been resolved.

An enforcement-oriented record could look like this:

_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-aggregate@example.com; adkim=r; aspf=r; pct=100"

You may also use sp= to define a policy for subdomains when necessary. For example:

_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc-aggregate@example.com; adkim=r; aspf=r"

Use sp= deliberately. A separate DMARC record at _dmarc.mail.example.com or another subdomain takes precedence for that subdomain and is often clearer when different teams operate different mail streams.

Major mailbox providers have made authentication a practical delivery requirement, not merely an anti-spoofing improvement. Gmail requires SPF or DKIM for all senders and SPF, DKIM, and DMARC for senders transmitting more than 5,000 messages per day to Gmail accounts; Gmail’s published requirements also call for valid forward and reverse DNS and TLS. (support.google.com)

Operational habits that keep trusted sources trustworthy

DMARC is not a one-time DNS project. Your trusted-source list changes whenever your organization adds a vendor, changes email providers, acquires a company, launches a new product, or modifies an application’s sending behavior.

Adopt these ongoing practices:

• Maintain a documented sender registry with domain, subdomain, purpose, owner, provider, DKIM selector, return-path domain, and expected volume.
• Review aggregate reports at least monthly, and more frequently during major migrations or enforcement changes.
• Require domain-authentication validation in procurement and security reviews for every email-capable SaaS product.
• Use separate subdomains for distinct mail streams, such as tx.example.com for transactional mail and news.example.com for marketing, when that separation fits your architecture.
• Rotate DKIM keys according to your provider’s supported process and avoid deleting an old selector until mail signed with it has aged out.
• Keep SPF intentionally small. Remove inactive includes and count DNS-querying mechanisms before adding another provider.
• Protect API keys and SMTP credentials. An authenticated provider account can become a real source of harmful mail if credentials are exposed.
• Re-test after DNS, provider, template, and routing changes.

Separate subdomains can make incident response easier. If a marketing platform is compromised or misconfigured, its traffic can be isolated from authentication and reputation work for password resets or account-security messages. This does not eliminate the need for alignment, but it reduces the blast radius of an error.

When an unknown source is probably malicious

An unknown source is more suspicious when it has no identifiable internal owner, sends at unexpected volume, uses countries or networks unrelated to your operations, consistently fails SPF and DKIM, or appears only after you move toward DMARC enforcement.

DMARC reports do not always reveal message content, and aggregate reports cannot by themselves prove intent. Still, a row such as the following is a strong warning sign:

source_ip: 203.0.113.44
header_from: example.com
count: 18,400
spf: fail for suspicious.example
DKIM: fail
DMARC disposition: reject

If the IP is not associated with your business and no legitimate service can explain the traffic, do not add it to SPF and do not attempt to “fix” its DKIM. A p=reject policy is designed to instruct participating receivers to reject this kind of unauthenticated impersonation.

If the source is sending through one of your legitimate providers, treat it as a possible account-security incident. Review provider logs, revoke or rotate API tokens and SMTP credentials, review authorized users and webhooks, and determine whether messages originated from a compromised application or account.

Conclusion

DMARC trusted sources are not a special DNS feature or a permanent vendor label. They are the systems you can account for and verify through aligned SPF, aligned DKIM, or ideally both. A reporting dashboard can speed up the work, but the durable answer comes from inspecting report data, validating DNS, checking real message headers, and assigning ownership to every sender.

Start with monitoring, build a complete sender inventory, repair alignment for every legitimate mail stream, and remove or investigate anything you cannot explain. Once that work is complete, DMARC enforcement becomes a controlled security improvement rather than a risky switch that could interrupt password resets, receipts, support replies, or other important mail.

FAQ

What does “trusted source” mean in a DMARC report?

Usually, it means the reporting tool recognizes a sender as legitimate or sees it consistently passing DMARC-related checks. It is a dashboard classification, not a DMARC protocol tag. Verify the underlying source IP, SPF domain, DKIM domain, alignment result, volume, and internal business owner before relying on the label.

Can a sender be trusted if SPF fails?

Yes. A message can pass DMARC when SPF fails if it has a valid DKIM signature whose d= domain aligns with the visible From: domain. This commonly happens with legitimate forwarded mail, where SPF is less reliable.

Why does SPF pass but DMARC fail?

SPF may pass for a vendor-owned envelope sender such as bounce@vendor.example, while the visible From: address uses example.com. DMARC requires the SPF domain to align with the visible From: domain, or it needs aligned DKIM to pass instead.

Should every trusted source be added to my SPF record?

No. Add an SPF authorization only when a service actually sends using an envelope sender under your domain and the provider documents the required mechanism. Prefer aligned DKIM where available, and avoid adding unnecessary SPF includes because SPF has a 10-DNS-lookup evaluation limit.

How long should I stay at p=none before using p=reject?

Stay in monitoring mode until reports cover your normal mail cycles and every meaningful source has an owner and passes DMARC consistently. The right duration depends on your business, but it should include infrequent mail such as monthly billing, seasonal campaigns, and emergency notifications—not only daily transactional traffic.