A customer notices that an invoice now lists a different bank account. The finance team says nothing has changed. There are no obvious signs of an account break-in, but the email came from the usual address: billing@example.com.
That address alone does not prove that someone signed in to the company's account. A different server can send a message with the company's address in the From field. Changing a password cannot, by itself, prevent that external use of the domain.
DMARC gives receiving servers a way to check the connection between a visible sender domain and a passing SPF or DKIM result. It also lets the domain owner publish a handling policy and request reports. We will follow a fictional company, Gaon Trading, to see how that works for employee email, newsletters, and impersonation attempts. All example addresses and figures are illustrative.
Why SPF and DKIM still need DMARC
Gaon Trading uses one provider for employee mail and another for its newsletter. Both show an @example.com sender address to customers, although the services use different systems behind the scenes.
Three domain identities help explain the distinction. From is the address the reader sees. MAIL FROM is the address used during server-to-server transfer and for delivery failure notices. The DKIM d= value identifies the domain signing the message.
news@example.combounce@mailer.example.netmailer.example.netAn SPF pass for this message means the connecting server is authorized to send for mailer.example.net. A DKIM pass means that domain's signature is valid. Neither result, on its own, establishes permission to use Gaon's example.com address. SPF's MAIL FROM check ↗ The DKIM signing domain ↗
An attacker can also set up SPF and DKIM correctly for a domain they control. DMARC addresses the missing connection: does a successfully authenticated domain align with the company domain shown in From?
The company publishes a policy; the recipient's server checks it
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. The company publishes its policy in DNS, where information about the domain can be looked up. Receiving servers use that information when assessing mail. Those that provide reports can send their observations back to the domain owner.
- 01Publish
The company configures its senders and publishes a DMARC policy and reporting address in DNS.
- 02Evaluate
The receiver checks authentication and alignment, then applies its own handling rules.
- 03Review
The company examines reports for missing services, broken authentication, and suspicious use.
Publishing DMARC for your company therefore helps protect customers and partners receiving messages that claim to come from your domain. Protecting your own employees from incoming fraud also requires the receiving service's authentication checks, impersonation detection, and content analysis.
Read the domain next to PASS
DMARC starts with the part after @ in From. It does not establish which individual controls the billing or news mailbox. The relationship between that From domain and the domain that passed authentication is called alignment.
The two ways to pass DMARC
SPF passes+ MAIL FROM aligns with From
ORDKIM passes+ DKIM d= aligns with From
Both conditions must be satisfied within at least one path.
You cannot combine an SPF pass with an aligned but failing DKIM signature. Each path must supply its own passing result and aligned domain. A matching domain name on a failed signature is insufficient. DMARC alignment requirements ↗
Scroll sideways to read the full table.
| Message | Authentication results | DMARC |
|---|---|---|
| Employee invoice | SPF and DKIM pass for example.com. | Pass: authentication connects to the company domain. |
| Newsletter before domain setup | SPF and DKIM pass for mailer.example.net. | Fail: the provider is authenticated, but the company domain is not aligned. |
| Outside sender using the company address | SPF and DKIM pass for sender.example.org. | Fail: authentication for an unrelated domain does not establish authority to use example.com. |
Notice that the legitimate newsletter and the impersonation attempt both fail. DMARC does not know about Gaon's contract with its newsletter provider. That relationship must be reflected in the configuration. A failure needs investigation; it is not conclusive evidence of fraud.
What would make the newsletter pass?
Gaon completes the provider's domain authentication process, publishes the issued DNS records, and enables signing with its company domain. A new message now has a valid d=example.com signature. DMARC can pass through that DKIM path even though the SPF domain remains unchanged.
From: news@example.com — unchanged
Before
SPF PASS mailer.example.net
DKIM PASS mailer.example.net
DMARC FAIL — no aligned passing result
After enabling company-domain DKIM
SPF PASS mailer.example.net
DKIM PASS example.com
DMARC PASS — DKIM passes and alignsAnother option, where supported, is to configure a custom MAIL FROM domain under the company's domain and authorize the service there. Merely adding an include to example.com's SPF does not fix alignment while the actual MAIL FROM remains mailer.example.net. The provider's sending configuration must use the intended identity. Microsoft: diagnosing alignment failures ↗
How closely do the domains need to match?
The default relaxed mode (r) compares organizational domains. In an ordinary company-domain setup, mail.example.com can align with example.com. Strict mode (s) requires the complete domain names to match.
Scroll sideways to read the full table.
| Authenticated domain | Relaxed: r | Strict: s |
|---|---|---|
example.com | Aligned | Aligned |
mail.example.com | Aligned when in the same organizational domain | Not aligned |
example.com.example.net | Not aligned | Not aligned |
The last address belongs under example.net, even though it contains the company's name. Relaxed alignment does not accept similar-looking strings. The aspf and adkim tags control SPF and DKIM alignment respectively. Start with their default r unless there is a specific reason to enforce exact domain boundaries and your legitimate senders can meet that requirement.
Keep the result, policy, and report separate
Once a message fails DMARC, what should happen? The domain owner uses p= to request handling. Since Gaon still has an unconfigured newsletter, it starts by monitoring and correcting legitimate mail.
p=noneMonitor
Request no quarantine or rejection because of DMARC failure. Failed messages still fail the check.
p=quarantineTreat as suspicious
Ask receivers to treat failures as suspicious, potentially sending them to spam.
p=rejectReject
Ask receivers to reject messages whose use of the domain cannot be authenticated and aligned.
p=none does not turn a failure into a pass. p=reject does not change how SPF or DKIM is calculated. It changes the requested response to the same failed authentication outcome.
The receiving service makes the final decision. A message can be rejected under a separate spam rule while the domain uses none, and a DMARC pass does not guarantee inbox placement. Forwarding exceptions and other local judgments can also affect handling. Receiver policy considerations ↗
The current standard also requires receivers to use more than the published reject policy as the basis for rejecting a message. Without other knowledge and analysis, they must treat the failure as quarantine instead. Receiver obligations for rejection ↗
A first monitoring record, explained
DNS name: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=rv=DMARC1 identifies the record. p=none requests monitoring rather than enforcement. rua= supplies the aggregate reporting destination. adkim=r and aspf=r explicitly state the default relaxed alignment modes; omitting them keeps those defaults.
This is an example for a domain without an existing policy. Do not overwrite an established quarantine or reject policy with it, or add a second DMARC record at the same name. Create a working reporting mailbox or use your analysis provider's issued address. An external reporting destination may also need authorization in the receiving organization's DNS. Google: setting up DMARC ↗
Use reports to find what your inventory missed
Receivers that report DMARC results group observed messages by information such as source IP and authentication outcome. Reports usually arrive as structured XML files, which are easier to review through an analysis tool than as individual email attachments.
Scroll sideways to read the full table.
| Identified source | Observed result | Owner's next action |
|---|---|---|
| Employee mail | 1,200 messages passed | Verify that the source matches the approved employee mail provider. |
| Newsletter | 240 messages failed | Enable company-domain signing and check newly sent messages. |
| Unidentified source | 18 messages failed | Investigate other departments' tools, forwarding, or unauthorized use. |
Calling this “258 spoofed emails” would misclassify the legitimate newsletter. Equally, fixing those 240 failures would not explain the remaining 18. The inventory turns report counts into work someone can investigate and resolve.
Reports cover participating receivers' observations. They are not complete sending logs, message copies, real-time warnings, or inbox placement receipts. A lack of reports does not prove a lack of spoofing attempts. What aggregate reports contain ↗
Which kinds of impersonation can DMARC address?
Consider a domain reserved for a controlled sending purpose, whose owner has justified a p=reject policy after checking legitimate authentication. An unauthorized server claims that exact domain in From without an aligned passing result. DMARC fails, giving the receiver both a failed result and the owner's rejection request.
This is not a blanket recommendation for employee email domains. RFC 9989 recommends against p=reject for general-purpose email because legitimate mailing lists, forwarding, and other indirect paths can break authentication. Choose a policy for the domain's actual use; a few successful forwarding tests do not change that use. DMARC interoperability considerations ↗
A domain that does publish rejection must apply valid DKIM signatures to its messages and must not rely on SPF alone for a DMARC pass. Even controlled transactional mail can be sent to an address that forwards elsewhere.
That is one form of impersonation. Other attacks use a similar domain, a misleading display name, or a compromised account. They need different checks.
Scroll sideways to read the full table.
| What the reader sees | What DMARC can establish | Additional controls |
|---|---|---|
| The exact company domain used by an outside sender | Whether a valid authentication result aligns with that domain | Configure legitimate senders, enforce a policy, and review results. |
| A separate domain with a similar spelling | That other domain may pass its own authentication | Inspect the address and use receiver-side impersonation detection. |
| The display name says Gaon Trading Finance | DMARC does not verify the display name | Expand the address and verify important requests independently. |
| A compromised employee account or sending tool | Mail through an authorized path may pass | Use MFA, access controls, and login and sending-log review. |
DMARC does not identify the individual who wrote billing@example.com's message. A fraudulent invoice or malicious link sent from an authorized account can pass. DMARC's protection limits ↗
For the bank-account change at the start of this article, authentication supplies useful evidence about the domain. Payment approval still needs an independent check. Call the supplier using a number from an existing contract or another trusted record, rather than a new number in the questionable email. FBI: preventing business email compromise ↗
Begin with the services that use your address
You do not need to send large volumes for domain authentication to matter. A handful of invoices or password resets may be more important to the business than thousands of newsletters. A successful employee test message also tells you little about an untested billing tool.
Gaon's administrator asks marketing about newsletters, sales about the CRM, and engineering about order and account notifications. The DNS administrator is unlikely to know every tool that a department has adopted.
- List domains, services, and owners
Include employee mail, newsletters, CRM, support, invoices, and automated notifications. Record each From address and any subdomains.
- Test mail from each actual service
Inspect newly received messages for authentication and alignment. A saved DNS record is only part of the evidence.
- Compare reports with business records
Assign report review to someone who can contact service owners. Arrange separate checks for infrequent mail such as month-end invoices.
- Choose a policy for the domain's actual use
Resolve missing senders and assess indirect-mail needs. Rejection is not a universal end state for general-purpose email. After a policy change, review reports, bounces, and customer complaints together.
Readiness depends on the individual sending paths you have verified, not just a high overall pass rate or a fixed number of days. Keep the inventory and test evidence so a new service or a change of administrator does not undo that work.
Use the current standard alongside your providers' documentation. The 2026 DMARC update retired some settings found in older examples, while support for newer settings can vary between receivers. The setup and policy guides cover the practical choices in more detail. Current DMARC tag registry ↗
Genharden DMARC · Updated 2026-09-22. Based on the SPF, DKIM and DMARC standards and the official documentation linked above. Companies, domains, IP addresses and report figures are illustrative unless stated otherwise.