Email impersonation creates a specific security problem for small and midsize businesses: an attacker does not necessarily need access to an employee's Microsoft 365 account to send a message that appears to come from the company's domain. Because internet email was not designed to validate that senders are who they claim to be, a forged From address can make a fraudulent message look more credible. Microsoft identifies SPF, DKIM, and DMARC as interdependent email authentication standards used to address sender spoofing.
DMARC email security addresses this problem by helping receiving mail systems determine whether messages using your domain are authorized. DMARC, which stands for Domain-based Message Authentication, Reporting, and Conformance, uses SPF and DKIM results, verifies alignment with the domain visible to the recipient, provides reporting, and defines how receiving systems should handle messages that fail authentication. Microsoft explains that SPF, DKIM, and DMARC work together to authenticate email senders and protect against spoofing and phishing.
For SMBs using Microsoft 365, the objective should not simply be to publish another DNS record. A well-managed DMARC program gives IT greater visibility into who is sending email using company domains, helps reduce opportunities for direct domain spoofing, and establishes a repeatable governance process for legitimate email services.
DMARC is easier to understand when SPF, DKIM, and DMARC are treated as connected controls rather than three independent settings.
Sender Policy Framework, or SPF, identifies which mail sources are authorized to send email for a domain through a DNS TXT record. However, SPF alone does not verify that the domain used in the underlying MAIL FROM address matches the From address the recipient sees. SPF can also fail after server-based forwarding because forwarding changes the source server. Microsoft documents these limitations in its email authentication guidance.
That distinction matters for SMBs because Microsoft 365 may be only one of many systems sending email. CRM platforms, marketing applications, billing tools, support platforms, payroll systems, and other services may also send messages associated with the company.
Your SPF configuration needs to account for approved sending infrastructure without becoming a catch-all authorization mechanism.
DomainKeys Identified Mail, or DKIM, digitally signs important elements of an email. The receiving mail server validates the signature to determine whether those signed elements were altered during transit.
DKIM also addresses some scenarios where SPF is less reliable. For example, Microsoft notes that DKIM can continue validating certain messages affected by email forwarding because the DKIM signature is generally not changed simply because the message passed through a forwarding server. Microsoft provides additional details on the relationship between SPF and DKIM in its email authentication documentation.
DKIM by itself, however, does not require the signing domain to match the From domain displayed to the recipient. That is where DMARC becomes important.
DMARC evaluates SPF and DKIM in relation to the visible From domain.
Microsoft explains that a message passes DMARC when at least one qualifying SPF or DKIM check passes with the required domain alignment. If both fail to produce an aligned authentication result, DMARC fails. The domain owner can then publish a policy instructing the receiving system how to handle those failures. Microsoft's DMARC configuration guidance explains the alignment process in detail.
The three primary DMARC policies are:
DMARC can also specify where authentication reports should be sent, giving organizations visibility into systems sending email using their domains. [learn.microsoft.com]
For business leaders, this turns email authentication from a collection of technical records into a manageable digital identity control.
Microsoft 365 already performs extensive inbound email authentication and filtering. Microsoft says its cloud email services combine conventional SPF, DKIM, and DMARC checks with other signals through implicit and composite authentication. [learn.microsoft.com]
That does not make DMARC unnecessary.
DMARC serves a different purpose when configured for domains your business owns. It establishes how messages claiming to originate from those domains should authenticate, including messages sent to recipients outside your organization.
This distinction makes DMARC part of a broader Microsoft 365 email security strategy rather than a substitute for it.
Microsoft 365 environments should combine email authentication with appropriate anti-phishing controls. Microsoft states that its anti-phishing policies can detect spoofed senders and other deceptive email techniques. Defender for Office 365 adds capabilities including user and domain impersonation protection and configurable phishing thresholds. Microsoft documents these capabilities in its anti-phishing policy guidance.
The security model is therefore layered:
Changing one DNS record should not be treated as the complete email security strategy.
The safest DMARC implementation is a controlled rollout driven by visibility rather than an immediate move to enforcement.
Microsoft specifically recommends a gradual approach for active custom domains, with the goal of ultimately reaching p=reject after testing and verification. [learn.microsoft.com]
Before changing DMARC policy, identify the systems authorized to send email using each business domain.
Microsoft 365 is an obvious source, but the inventory should extend across the business. Review systems used by:
A marketing automation system or invoice platform may be sending essential messages even though nobody on the IT team manages it directly.
Assign a business owner to each approved sending service and record the domain or subdomain it uses. This creates an approval process for future services instead of forcing IT to rediscover the environment each time authentication failures appear.
For custom Microsoft 365 domains used to send email, Microsoft advises organizations to configure SPF and DKIM before implementing DMARC. [learn.microsoft.com]
Review each legitimate sender to determine how it authenticates. Do not assume that a service is correctly configured simply because its messages currently arrive.
This is also an opportunity to address unnecessary complexity. Microsoft recommends using a subdomain for email services that are not under your direct control, such as bulk email services, rather than exposing the reputation of the primary email domain to problems associated with those services. [learn.microsoft.com]
A common starting point is:
p=none
This policy allows the organization to observe DMARC results before requesting quarantine or rejection of failures. Microsoft recommends beginning with p=none, reviewing results, and troubleshooting legitimate mail that is not properly authenticated.
DMARC aggregate reports can reveal the IP addresses of services sending mail using your domain, whether the sources pass or fail DMARC authentication, and what actions are being applied based on your policy. Microsoft recommends regularly reviewing these reports to identify sending sources and unintended authentication failures. [learn.microsoft.com]
The goal during monitoring is straightforward: distinguish approved business email from systems that should not be using the domain.
A DMARC failure should trigger investigation, not an automatic conclusion that the message is malicious.
Legitimate failures can occur when messages are forwarded or modified in transit. Microsoft specifically documents forwarding as a scenario that can break SPF and potentially DMARC alignment. [learn.microsoft.com]
When an approved sender fails authentication, determine why.
Depending on the cause, remediation may require correcting SPF authorization, configuring DKIM properly, changing how a vendor handles the From domain, or separating a service onto an appropriate subdomain.
Document the resulting configuration and business owner. The process should leave the email environment more understandable than it was before the issue appeared.
Once legitimate sending sources have been validated, increase enforcement gradually.
Microsoft's recommended rollout progresses from p=none to p=quarantine and ultimately p=reject, while monitoring the results at each stage. Microsoft's guidance also describes using the DMARC pct value to apply enforcement incrementally during testing and tuning. [learn.microsoft.com]
This progression matters because an immediate move to rejection can expose configuration problems only after legitimate messages stop reaching their recipients.
The decision to increase enforcement should instead be based on evidence. IT should understand its sending systems, remaining failures should have identifiable causes, and the organization should have a defined process for addressing exceptions.
DMARC should produce observable security and operational outcomes.
Rather than treating the existence of a DMARC record as the success metric, IT leaders should monitor indicators such as:
These measurements help determine whether email authentication is actually becoming more controlled.
For example, moving to p=reject is less meaningful if IT continues discovering business-critical services that nobody knew were using the domain. A healthier environment is one in which approved senders are documented, authentication failures are explainable, and new platforms cannot begin sending company-branded email without an ownership and configuration review.
That is the behavior change SMB leaders should expect from a mature DMARC program.
DMARC protects a domain's email identity. It does not secure every part of the email ecosystem.
A convincing phishing email can originate from a legitimate external account. An attacker who compromises a real Microsoft 365 identity introduces a different problem than direct domain spoofing. Social engineering can also succeed even when every technical authentication check works correctly.
For that reason, organizations should connect DMARC with Microsoft 365 identity and email protections instead of evaluating it on its own.
Microsoft's anti-phishing capabilities include spoof detection, unauthenticated sender indicators, and first-contact safety tips for cloud mailboxes. Defender for Office 365 provides additional impersonation protections. [learn.microsoft.com]
At the business-process level, employees still need a clear method for reporting suspicious messages. Finance teams should maintain separate verification procedures for sensitive payment or account changes. Administrators should also review the organization's Microsoft 365 identity controls alongside its mail security configuration.
The combination reduces reliance on any single control.
DMARC is not finished when a domain reaches an enforcement policy.
Email environments change. Organizations adopt new SaaS platforms, replace marketing tools, add business applications, register domains, and retire old infrastructure. Each change can affect email authentication.
Make DMARC review part of normal technology governance. Revisit sending sources when the business:
Unused domains deserve attention as well. Microsoft recommends configuring DMARC for registered domains that are not used for email so they indicate that email should not originate from those domains. [learn.microsoft.com]
For resource-constrained SMB IT teams, this is also where managed security support can be useful. The value is not simply outsourcing a DNS change. It is maintaining an accurate inventory of sending systems, monitoring authentication results, investigating anomalies, coordinating third-party configurations, and keeping email security aligned with changes across Microsoft 365 and the broader application environment.
The long-term objective is a controlled email identity: legitimate senders are known, authentication is measurable, exceptions have owners, and unauthorized use of company domains faces progressively stronger enforcement.
DMARC, or Domain-based Message Authentication, Reporting, and Conformance, is an email authentication standard that uses SPF and DKIM results to determine whether the sending domain aligns with the From domain displayed to the recipient. It also allows domain owners to publish a policy for handling authentication failures and identify where DMARC reports should be sent. Microsoft explains the underlying DMARC authentication and alignment process here.
SPF identifies authorized mail sources for a domain. DKIM digitally signs important elements of a message so the receiving system can validate them. DMARC uses SPF and DKIM results and checks domain alignment with the visible From address. Microsoft describes these technologies as interdependent components of email authentication. [learn.microsoft.com]
Yes. Microsoft documents DMARC configuration for both Microsoft Online Email Routing Address domains and custom domains used with Microsoft 365. For custom domains, DMARC TXT records are managed through the domain's DNS hosting provider rather than through a Microsoft 365 PowerShell cmdlet or portal control. [learn.microsoft.com]
For active custom domains, Microsoft recommends a gradual rollout beginning with p=none for monitoring, progressing to p=quarantine, and ultimately moving to p=reject after testing and verification. This approach helps organizations identify legitimate authentication problems before stronger enforcement affects mail delivery. [learn.microsoft.com]
DMARC addresses a specific part of the phishing problem by helping prevent unauthorized sources from successfully spoofing domains protected by appropriate authentication and policy. It does not prevent every phishing technique. Microsoft 365 organizations should use email authentication alongside anti-phishing controls and other security measures. [learn.microsoft.com], [learn.microsoft.com]
No. DMARC and Microsoft Defender for Office 365 address different aspects of email security. DMARC provides standards-based email authentication and domain alignment, while Defender for Office 365 includes additional capabilities such as user and domain impersonation protection and configurable phishing thresholds. [learn.microsoft.com], [learn.microsoft.com]
Review DMARC aggregate reports and track whether approved email sources authenticate correctly. Microsoft states that aggregate reports can identify sending IP addresses, indicate whether sources passed or failed DMARC authentication, and show actions applied according to the DMARC policy. Microsoft recommends regularly reviewing these reports for sending activity and unintended authentication failures. [learn.microsoft.com]
Yes. Microsoft's Microsoft 365 DMARC guidance recommends configuring DMARC records for registered domains that are not used for email to specify that mail should not originate from those domains. [learn.microsoft.com]